AI Was A Waste of Time, Until It Wasn't with Megan Boshuyzen

"You should be layering AI on top of what you're already doing to make you more efficient. It should not be doing the bulk of the work. It should just be making you faster." — Megan

Email development has long been the graveyard of good design intentions where beautiful mockups meet the harsh reality of Outlook's rendering engine, dark mode disasters, and code that would make any web developer weep. But while most of the industry gets swept up in AI hype promising magical solutions, actual email developers are quietly discovering what works, what doesn't, and what's dangerously oversold.

Megan Boshuyzen, development lead at Inbox Army, brings a rare combination of technical depth and real-world perspective to the AI conversation. A graphic designer turned email developer, she's witnessed the evolution from Vertical Response in 2010 to today's complex email design systems. Her journey through MailGun, Email on Acid, and now agency-side development gives her insights few possess about where AI genuinely helps and where it spectacularly fails.

This is not a hype episode. It's a field report from someone doing the work and telling the truth about it.

Timestamps

04:35 — AI Saved a Complex Liquid Build: When a client prohibited storing product data in a CRM, Megan used AI to work through intensive if-else Liquid logic, dynamically matching product data loaded into the email with conditional display in the ESP.

06:10 — ESPs Must Own Accessibility: Email service providers and drag-and-drop editors bear the primary responsibility for making their code accessible, not individual marketers who can't edit it — and many of the required fixes are not significant engineering lifts.

13:45 — The Photographer Analogy for Email Developers: AI democratizes email creation the way smartphones democratized photography, but just as professionals still get hired for what matters, skilled email developers will remain essential at the enterprise level.

19:07 — Building an Email Design System at an Agency: Megan breaks down the real complexity of building a multi-client email design system at Inbox Army, why e-com layouts demand more than she anticipated, and how Claude Code is helping her manage the JavaScript as it scales.

26:21 — From "AI Is Useless" to Cautiously Bought In: Megan traces her own two-year shift from dismissing AI entirely to finding genuine, specific use cases and explains why she still refuses to call it a magic bullet.

36:25 — AI Creates Mediocre Code: AI accelerates the creation of mediocre email code through a lowest-common-denominator approach, similar to how engineers encounter inefficient AI-generated code solutions.

44:35 — Build the Foundation Before AI: Developers who master coding fundamentals first and then layer AI on top will outlast those who build AI-dependent workflows because when something breaks, you need a foundation you actually understand.

46:55 — Quietly Terrified of Code: A large, silent portion of the email and martech industry is anxious about AI and code. This episode is designed to help them feel grounded and less alone, not more panicked.

Sponsor

Brought to you by Hightouch, the leading composable CDP and decisioning platform trusted by brands like Domino's, Chime, and Aritzia. 90% of customers have a real use case live within their first week, delivering world-class personalization at scale. Learn more at hightouch.com/msom.

Connect & Subscribe

Subscribe to Making Sense of Martech wherever you get your podcasts. Follow us on TikTok, LinkedIn, and don't forget to like and subscribe on YouTube.

Creators and Guests

Host

Jacqueline Freedman

Founder of Monarch + Making Sense of Martech

Guest

Megan Boshuyzen

What is Making Sense of Martech?

Unfiltered takes on the biggest shifts in marketing technology. We spotlight what matters, who's leading (or lagging), and what's next. In Martech, clarity is power — and we're here to deliver it.

Email development has a reputation for being a place where good design goes to die buried under

client rendering, quirks, dark mode, disasters, outlook, period and code that would make a web

developer weep. My guest today has not only survived that world, but she's thriving in it and

she's using AI to do it smarter. Welcome to the hot seat. I'm Jacqueline Friedman, founder of

monarch, and we're about to get into the real, unfiltered truth about what AI actually does and

absolutely does not do for email developers right now. But a little bit about her first Megan Bush.

Howson is the development lead at Inbox Army and one of the most respected voices in email

development today. A graphic designer by training, she made the pivot into code and she never looked

back, overseeing email development at gmail, jet and email on acid before landing her current role.

She's also a founder of a publishing house, a youth soccer coach, and a politician. Talk about

the ultimate multi-hyphenate right here. She spent years proving that email done right is not a

relic. It's a competitive advantage. And at the moment, when every marketer is just being told to

use AI, it will solve everything. Megan is one of the few that's actually doing it, stress testing

it, and also telling the truth about what she's finding out. So welcome, Megan. Thank you for being

here. Thank you for having me on. All right. To dive in. Let's start with a couple of rapid fire

questions. What was your first martech tool? The first tool I used was an ESP called

Vertical Response back in 2010. I don't know that one. My first emails

that I designed, my first email in 2008. I sent my first email designed and sent out myself

in 2010. I had no idea what I was doing. Wow. And that's what the company I worked for used.

Amazing. Okay. All right. Here's a myth I want you to bust or defend. If you can write a good prompt,

you can build a good email without knowing how to code. True, false or dangerously oversimplified? I

would say it's dangerously oversimplified because it's getting better,

but unless you write that prompt correctly and you're extremely prescriptive, it's not going to

give you what you need. That sounds right, but also sounds applicable to pretty much any and all

prompts after a couple rounds, basically. Yep. Okay, so you started up as a graphic designer

and now you're an email developer. What broke first your patience or the outlook rendering

engine? Definitely my patience because of the outlook rendering engine.

Touche. I mean yeah outlook. It's a lot of a lot in this episode. Oh, well. Oh,

wow. Um, okay. Dark mode. Gift curse or just an ordinary Wednesday? Just an ordinary

Wednesday. Something we just deal with. And we keep moving. Yeah. If only everyone thought that way. I

know you didn't try to force it. You got to follow where the users at, so should be dealing with it

if you're not. Exactly. So if you could magically delete one thing from email development forever, a

practice tool, bad habit, you name it, what would you get rid of? Outlooks. Word rendering engine.

Fair I'm glad I hit that fixes so much. It's coming soon. Soon, but

not soon enough. Not exactly. Nothing is soon enough. Well, I want to set the stage and really

just establish where we actually are. There is so much noise right now about AI transforming

every creative and technical discipline overnight. I mean, I've got horror stories for days about

good, bad, ugly. And because you work in email development, it's notoriously stubborn, like table

based, client dependent. It's stuck in the 90s and it's very, very unforgiving. I mean, I've coded

emails. I would never call myself an email developer, but I'm pretty capable. And it's a

thankless job. So to set the stage when you started using AI tools

like Cloud Code or others in your workflow, what specific problem were you hoping to solve and

actually did it solve it? Yeah. So when I first started using it, it was to actually help me with

liquid. I am not using it with email code at all. I find that you have to be so prescriptive

with the prompts to use it for email code, that I might as well just code it myself, because I just

have things already created that I can throw together. But I came up against a really unique

situation where I needed some robust liquid to be written, and I like knew 90% of

the way there what I needed to do, but I needed that extra 10% of help. So this was I started with

Gemini before moving to Cloud Code, and I went back and forth with Gemini to get what I needed

for it to work, because in this situation I had to dynamically display products, but the products

were not being housed in a CRM, and the instruction from the client was that we could not

house it in the SP or CRM. So I had to take a lot of information and have it loaded

like via liquid in the email, all the information in the email, and then match it

up to a code that was in the SP and do some really intense, like if else type

stuff I think we used when with liquid in the end to display certain products. That was really

intense. Yeah, I would not have been able to do that without the help of AI. That makes sense. And

I guess, as a slight aside, do you consider liquid harder than handlebars? So I think once you kind

of know how it works, it's just looking at documentation. And each SP is a little bit

different in how they implement anyway, and maddening. Can we please have some standards in

general? That'd be nice. What is your hottest take? It is the hot seat after all. My hot take is that

ISPs and email builders of the drag and drop variety need

to take a larger responsibility in making sure that their code itself

is accessible. When we see a lot of emails fail basic

accessibility checks, a lot of times they're out of drag and drop templates. And email marketers

who do not code cannot access that code. And even if they could, if they wouldn't know what to do, it

has to be on the companies to implement those changes and educate their users on how to

utilize those features. It's not enough for us, the users, to keep telling

the companies that we want these to happen. We've been asking for this for years, and it feels like

all that feedback goes into a black box, and it feels like it feels like an abyss, right?

Yes. So we really need product managers to step up, go to the engineers and say,

hey, this is important. Please, let's make this happen. And in my opinion, in a lot of cases, it's

not a big lift. I agree, like some of the really basic stuff is because sometimes you think

something's simple and you go to engineer it and it's actually really hard. But some of these fixes

are they're so easy. They are not big engineering lifts. So I really encourage email

service providers and the email editors that they're mostly white labeling to

talk and look at their product seriously and see how we can make that code more accessible so that

users can have the best experience possible from building the emails and then from reading and

interacting with the emails. 1,000%? Yes. And to your point, it's

very similar to me not to go off topic, but to sustainability and environmental practices. Like

right now the onus is on individuals, but actually it's the corporations, the companies that are sort

of the largest. So why are we shifting blame or shifting responsibility more than anything? And so

yes, I agree. Yes, even the basic contrast ratios, you can do that. It's easy. I end

up having to do it elsewhere. But it is not a difficult task. And it can be chipped by chip, you

know, starting with contrast ratios, then going into alt text, then going to X, Y and Z. I really

just want to see I want to see ESPs add in the ability. And I think some do this, but not all. We

need to be able to add the ability to set your language attribute. Yeah. And you need the ability

to set your direction attribute, which is one that I think a lot of people don't think about, because

that so much of us are working in English or a language that runs left to right. What happens if

you're in in something like Arabic or Hebrew? I've been there. You have to custom code all of it.

A Japanese can be vertical, but also like and like Japanese and Chinese can both be, you know, written

in several different ways. What happens when we're going up against those types of languages? The ESP

needs to know if if the sentence is written in the other direction, or I should say the inboxes

do for screen readers and whatnot, so that that stuff can be read in the correct direction. Um, so

those are two very easy ones that I actually called out specifically at on spam when I

was there back in April, asking the ISPs to start taking a more serious look at this. I don't blame

you. It's not just accessibility, but it's also inclusivity, Right. I have been that person who's

coded those templates for other languages that are right to left, not left to right. And

I was only able to do that because I know how to code. Right. But other than that, there was no

opportunity regardless of the email editor or Wysiwyg options. Right. Like, one really quick

example is like if you're using Hebrew and the SP thinks you're doing a left to right language,

it'll put the letters in the completely wrong order and the word will be written backwards.

Correct. I've seen that happen, and that's happened while I was making the email where if I'm doing

something in English, I have to throw some Hebrew in there, because I worked for a nonprofit way

back when. That was where it was required to do things like that for our audience. You would just

see weird things like that happen. Yep. That tracks and it's like, hey, please structure it so we can

have different sections that are related so that we can have an alignment all across. It's not hard.

Just modularized it. Please. Yeah. Yeah. All right. We're already kind of jumping ahead to getting

nerdy, but before we go back in. So when you look at how AI is being positioned as a solution for

email development, what's the gap between the marketing pitch and the actual workbench reality?

I think I guess I will start with that. I think it's so important for designers and developers

nowadays to have a little bit of cross training, or at least high level knowledge of each other

disciplines, because I think what can often happen is that a designer who

may or may not have experience in email design, because a lot of times it can just get added on

to a designer's plate as like an extra piece of responsibility, which is the way I got into email.

I was the graphic designer and I also had to design graphics for email. Um, they can sometimes

put together layouts that may not be Easy to code in email or not

work how they intend an email. I see this a lot with Figma files where like a custom font is

being used and the fallback isn't taken into consideration necessarily. Or there are lots

of rounded corners, and people need to know that rounded corners are a progressive enhancement.

Therefore, it's not going to be rounded in outlook. And yeah, it's just knowing those little things I

think is so important when designing for email. And you only know that if you've studied both

disciplines. All right. So here is a tension I really want to name. We've got on one side,

marketers who are terrified of code and hoping AI is finally the escape hatch. The the the answer to

all the things. And then on the other hand, you have developers who are worried about getting cut

out and being replaced. Where do you land in this matrix? Is AI democratizing email development,

or is it creating a false sense of confidence in people who don't know yet what they don't know? In

a way, emails are democratized, right? Like, people don't need to know how to code to

create an email. And there are pros and cons to that. And I think what

we are going to see is people who

only code, email and don't know how to do anything else. They might be the ones who get pushed out.

Hmm. That makes sense. What I think people or developers are going to need to do is broaden

their knowledge a bit more. Maybe start learning some JavaScript. Start learning

systems thinking the push is really going to be towards, I think, email design

systems in enabling people to rapidly create emails and to be able to make those systems as

robust as possible using other programing languages. I think that email

developers won't be needed for those smaller companies that mostly are already not needed for

smaller, like small businesses, they can get away with drag and drop. Even medium sized businesses

can get away with drag and drop. And I think the more technical folks are going to really show

their strength at a larger enterprise level, where we have Salesforce and Marketing Cloud and

Braze and customer IO and how powerful all those systems are, you're going to need someone

technical to be able to connect all the pieces in a way that makes sense, and

I just think that's where things are heading. But I always also say that we all can take a picture

with our phones, but you still hire the professional photographer for the things that

matter. So for the things that matter, email developers will still be needed

without a doubt, and their technical knowledge will be so important. Now that makes total sense

and I'm in full agreement. Yeah. It's interesting. I think this also kind of delves into this new. It's

an interesting narrative that's happening where folks are hesitant with all the different and

rightfully for some engineer title getting added to everything. However, marketing engineer in my

eyes, is actually a real thing, and it has been for a very long time. And it's it's a perfect medium.

To your point, it's either the engineers or the the developer. Excuse me, gets to learn a little

bit more about the marketing side to be more helpful and more cross referential and

collaborative. And also it's an opportunity on the marketing side where it's a little bit more

creative or strategic to start learning a little bit more. And so it's almost like martech and maps

are the future of everything. Just kind of say I'm bullish on that, clearly, but that's how I think

about it. Yeah, I think email developers need to look at becoming a strategic partner instead

of just, oh, I'm the email developer I just missed in the code, right? I truly believe

understanding the strategy behind things and the design and the why allows you to

strategically help make a better email and a better product. Like it's important to have a

holistic view of whatever you're doing. Totally brought to you by our sponsors. If there's one

theme that's followed me at every stop in my martech career, it's trying to get good data into

the hands of marketers. That's why I'm so excited to tell you about our sponsor, High Touch, the

leading composable CDP and AI decisioning platform companies like Domino's, chime, Erica, and

PetSmart trust High touch to power their data. And here's the kicker 90% of customers have a real

use case live in production within their first week. That means you can implement a world class

CDP in months rather than the usual years long headache. That's why top brands choose high touch

to personalize every customer interaction at scale. See what high touch can do for you at high

touch. And now back to the hot seat. Okay, we've already been getting nerdy, but let's get extra

nerdy. Walk me through a real use case. Specific, not hypothetical. I'm sick of hearing everyone's.

I'm doing things, and I want to know where Claud or Gemini genuinely made your development

process faster or better. We've talked about the liquid example. I want another one. What were you

building? What was the prompt and what came back that actually worked? Yeah. So I've been using, uh.

Well, first of all, I've been using Claude code, just released routines, and they just change it so

that you don't have to hook it up to a repository, a GitHub repository to use it, which is helpful. I

actually started using that to kind of start turning Claude code into a sort of pseudo

executive assistant to me. So like I have it. So like because I'm at an agency, I have to track all

my time. So like I have to do things like track my meetings, which means a task has to go into my

project management system to track that time. But like, I don't want to spend the time to look at

every single meeting that I have and create a task to put it in there. So now Claude checks my

calendar a couple of times a day, sees if any new meetings have shown up, and if they have, it

creates the task for me in my project management system. I also have it giving me daily

debriefs to tell me everything that's going on that day. That is something I've been dreaming

about having in my life. It's something that can just tell me everything that's going on at the

beginning of the day. What's going on with my entire day? Work, personal, everything. Just tell me

so it tells me literally everything I do. A shutdown at the end of the day that tells me

what's coming up, which is nice. And then I've been using it a lot for JavaScript help.

So I know enough JavaScript to be dangerous, and I can usually get myself 90% of the way there,

but then like miss something really small and critical to make the whole thing work. So Claude

Code's been helpful as kind of like a second quote unquote developer to be like, look at this

file or look at this code snippet. It's not working for me. Why? And then it'll explain to me

why it's not working. And a lot of times it's like, oh, you're referencing the wrong object or oh, you

forgot you need curly brackets here or something like that. Yeah. Something so minute. But right.

That's easy to miss. Um, because I've been working on this really big email design system that's

just getting more complex by the day. I want to know more. Oh, man.

Yeah, it's it's getting by. Yeah, by the day. It's getting more complex. It's cool. It's a it's.

I thought I was just going to be kind of taking things I've built in the past and knew what how

to do and just implementing it at a new job. So I guess for background, for anyone who doesn't know,

I'm new to the agency world. I started in Inbox Army in September 2025. My goal being to

make my first big project goal was to make an email design system that makes us faster. So I was

like, oh, this is easy. I've already done an email design system that supports three brands off the

off, a singular code base. Like we should be able to knock this out, like not that slowly. Like

should be quick, should be quick. And then the more I look at the different layouts that we have and

it's a lot of e-com where before my email design system wasn't, SaaS was a SaaS company. So very

different approach, very different from a different approach. Highly templated, mostly text.

Now I'm dealing with all these different layouts and images and whatnot. It just keeps getting more

and more robust. So right now I'm in the stages that I have the I have a lot of the structure for

the body, so I'm just going into client files and building emails to see where it fails. And I'm

like, oh, I think I need a variant for this, or oh, I need a trigger for that. So it's just. And a lot of

it needs JavaScript for it to work, so I can keep it all on the same code base. Makes sense. Oh, you

keep all the clients on the same code base and everything's QAd ahead of time. Then it just

speeds you up that much more once it's in production. Claude Code's been helping me with

making all that work for the all the dynamic stuff. Yeah. That's awesome. Cool. Yeah. For sure.

It reminds me I was catching up with an industry friend who hired a designer developer that built

out their modular email design and system for their entire company. I asked, like,

how is it working like it is? Is it looking good? Is it working well? And it was the most

interesting response. He's like, yeah, it's great, but we don't use it. I was like, what do you mean?

And he's like, we use it as the reference. We use it as the what good looks like and then let our

team play try things out, but they have to QA it with AI based on

the source. Oh, interesting I know. I was like, I get it. I hadn't thought of being able to

do it that way. And so it's an interesting way of like, okay, you can still get the expertise from a

developer, but there are more parameters. There's ways to play around with it. Um, but

yeah, it's also an interesting one. But of course you have to keep your primary source code up to

date. We've been talking about all these different systems. Now, I'm curious if we get more granular

within anthropic skill set. Literally. Are you using skills, artifacts,

coworker or only cloud code? I was using some skills, but now with routines out, a lot of

those skills can actually be routines. Mostly been using cloud code in my IDE, so I've been

in Visual Studio Code, and I have Claude in there, so I can just hit a button for it. It opens

it up and I tell it what I'm trying to do and just write in there and it can make the edits for

me. So like, if I need to make a change in one component I'm working on, but like I need to make

the same exact change in another component, I can tell it to go do that for me so I don't have to

spend the time doing it. So that's what I've been mostly using it for. Yeah, yeah, I'm a big artifacts

user, which because I just have all these custom one off things, I'm like, I

need you to get me to the 70% and I'll do the rest. All right. Now let's go to the

error file or failure file. What is I categorically bad at right now? An

email development. And I want your granular answer and not it just doesn't understand context. You

know the prompt wasn't great is it. Dark mode logic, conditional CSS, MSO code for outlook like

preferences for divs over tables. Like, give me one thing that makes you say nope, doing it myself. I

mean, for me it's really it does come down to the prompting where I'm like, if I wanted to hit all

the accessibility stuff properly, if I want it to code the way I want it to code, it's just you have

to be so prescriptive with it that I'm like, why am I wasting the time being this prescriptive

when I can do it myself? But it is getting better. Like when I first started testing email

development with AI, it would give me JavaScript to do hover state. Oh no, it would do everything

in divs. But now it's not doing that anymore. So people say, well, it's like clearly it's learning

from other people doing the work and it is calling out when something is not

universally supported. Hmm. It makes sense though, which I find interesting. Yeah. There have been a

couple of times where I'm like, I was going back and forth with Claude because I was trying to see

how the inline are. That's part of my system work. So I'm using Masal to develop my email design

system, which is an open source, nice like tailwind framework thing that I can use to make components.

And then so once you're done building with your components, then you essentially build the email

in it. Um, outsources all your HTML and I some people don't like using in liners. There are some

email developers out there who are very good friends of mine who hate using in liners. I love

it in liners because I don't like looking at the giant blocks of it's so unlike CSS. I like it all

in the head when I'm developing because it's easier, but I was trying to see how advanced I

could get using the CSS if I could get it to inline the way I wrote the CSS and get to inline

as I intend. I just started playing with that, so it answers out on whether I can do it or not

because like, I would love to be able to use modern CSS in my email design system with like

just to do like child selectors to be like on the last paragraph, make your margin bottom margin

zero so that we don't have extra space. It's like those sorts of things. Or like if you have a

header and an image adjacent to each other, we need some extra margin between the two, like

those sorts of things. Um, so I'm seeing how I can make that work, but like I asked if it can make it

happen, it's like, nope, the inline or can't do that, it's too advanced. So it's been interesting to see

where it succeeds and where it fails. I mean, it is getting better bit by bit. When was the time

frame or what is the time frame you first started using AI to help. And yeah, how quickly do you

think it's evolved for the better? I mean, if you do a Google search of webinars I've done, there's

a webinar from me maybe two years ago saying AI is useless. Like, I was very much like, nope.

This is really bad. Um, and in the last two ish years, it's come a really long way.

Um, and I've been one I've been slower on the uptake than some other people. I do not believe AI

is a magic bullet. But I have gotten more curious to see, like, okay, where is

this helpful? Where is this not helpful? Like it's here. Let's take an honest look at it. I mean, to be

fair, you're definitely ahead of most curves. If we look at the industry at

large. And that's why I wanted to have this conversation. Just because it's hard. It's super

hard. Email clients are a fragmented mess, as we all know. R.I.P. litmus. R.I.P. all of the

things we're in full mayhem descendants at the moment, whether it's Gmail clipping The

Apple male privacy changes that happened a few years ago. Outlook. Just fucking outlook. How much

does the AI actually know about client specific rendering? You've kind of mentioned it, but how do

you know when to trust it versus know when it's very confidently incorrect? Kind of like a

mediocre white man, I love that. That's a good question. I haven't like I actually haven't pushed

it in that way so much yet. I think just just because I already have all my snippets. So

like my thing with trying to code with AI is that when I've been testing it, I'm like, use

my code, do not write it yourself. So that's kind of like the direction I've been going in is that

my end game is that I have all these components, and I've tested this out a little bit already and

it works pretty well. So once everything's done, I think it's going to be really cool is you feed it

a figma link to a design. You say, use my components, create this email. That's awesome. And

it does it. So that's my name. So like, I wouldn't expect it to know all the nuances of outlook

because there are like a lot of outlook related CSS that like we can use to do things that like

that, you won't know unless you're an experienced email developer. And they're kind of also it's

like just like trade secrets in some respects, like you either know or you don't know right in

there. And a lot of times they're just creative solutions to try to accomplish something. So I

wouldn't expect I wouldn't expect the AI to know about, you know, really obscure things

like that or like if you're trying to control, uh, text

color and Gmail dark mode to some level, which you can do sometimes and times not, there are ways to

do it using blending modes. I wouldn't expect the AI to necessarily know how to do that. The AI

would probably tell you it's not safe to use for email. Yeah, and I guess to that point it's the eye

because it's trained on so much. It knows the rules, but it doesn't know the accommodations,

right? AI doesn't know nuance. AI knows patterns. It's a exactly pattern recognition. So it does

not know the nuance of what you are trying to do. Speaking of nuance, we're talking about all these

different components and we're like, you got to put it in the prompt no matter what. Are you using

anything stored to memory? Is that actually being helpful or you just got to do it fresh every

single time? I haven't been doing anything like that. Okay. Not yet. I was just curious because

I commit to memory a number of things, and it still doesn't always work the way I want it to.

All right, I want to. We've been talking super nerdy in the best possible way. Language energizes

me so much. I want to take a little bit of a step back to the broader industry. And so you in

particular have just such a unique experience, having worked on at Mill Gun Mill, Jen, email and

asset. So you've seen the infrastructure side which few have seen the creative side being a

designer and also, of course, the QA side of the industry. And so where you sit is actually is AI

accelerating what you see as email's evolution, or is it just giving faster ways to make the same

old mistakes? For those who are not perhaps developers, designers and have the multi-hyphenate

you have? Yeah, I think I do think it's a I think it could, at least at

first, accelerate the creation of mediocre code, for sure. Lowest common denominator.

Um, I think I think engineers are likely running into this issue too, with code,

um, where I bet somebody could send me code that they wrote using AI, and I'd

take a look at it and I'd be like, what are we doing here? Like, there are so many other efficient

ways to code this. Um, so I definitely there's more than one way to do almost anything, and I think I

forget that. Right? It's like. I mean, it's like if you look at the way I code and you look at the

way my friend Anne Tomlin codes, like we actually we did a whole talk about this, actually, um, about

the fact that we code in two totally different ways and they're both valid, but then they're I'm

assuming you're the CSS forward and she is the HTML forward. Uh, we actually we

disagree. This is a I guess you could call this a different hot take. And I went do it. Yeah. Me and

her talked about this at UN spam because in Cyril Gross's, uh, accessibility

talk, he was using, uh, ghost tables and divs to code emails, which, when I

work on an email design system, that's how I code. So, like, I usually will flip between two different

ways of coding that I'll if it's going to be in a component, I'll do it with divs and ghost tables.

If I'm doing a bespoke email where I'm looking at all the HTML. Use a table because it's I'll use

only tables because I find it easier to read where Anne's school of thought is. Well, I'm just

going to use tables because of outlook. And some people think that when you're using ghost

tables and divs, you're essentially coding the email twice. My rebuttal to that is

you see both sides. Yeah. No for sure. Like there's a there's definitely like a pros and cons. And I

think I'm gonna write like a more robust future newsletter about this too. My argument for the

ghost tables and divs is that it's more one, it's more forward looking because

outlook is going to be phasing out the word rendering engine. Now that doesn't mean companies

are going to update at the rate we would like them to. So we're still going to be dealing with

it for a while. But when that time finally comes. Instead of having to recode all

of our emails to new modern standards. We can just take out the ghost tables and we're done

with it. It also allows us to more easily code mobile first,

because outlook not supporting media queries makes that harder. So that's why with an email

design system, I often will do it mobile first with the ghost tables and the divs, because it

also allows me to do that. And then the tables literally are only read by outlook and that's it.

I set it up so that the tables are only read by outlook. They don't read the divs. Sometimes you

can use CSS just to target it all anyway, so you're not rewriting so much twice. That's kind of

like my hot take about that. Very fair. It kind of sounds like I need to to bring an in

yourself back on and do a debate about them. And like all of the pros and cons because while I

recognize this is super niche, it's also super important because I know when I was learning to

develop code, I was fortunate I had a boss who one was amazing but also was an incredible email

developer, not to mention designer. And so I got, hey, let's pull up Dreamweaver and let

me show you what you're doing wrong. And then we would go to litmus. And so I got to learn the

principles. It's funny because I had to train my direct reports and I was like, I don't know the

reasons for anything, but I know how to do it. So and there aren't

particularly in email development, but also, just like in general within martech, there are no good

resources. And it's hard. I'll just say there's a lot of resources out there that are not great. And

maybe a little, uh, Shopify bro. And they don't know what they're talking about. It's

not a good look. It's not a good look. So no, I increasingly hate being on LinkedIn because of

all the AI hype. And honestly, I think in this day and age I love the community I have. Community has

been amazing, but if I could get rid of everyone else, that'd be nice. I see all the spam DMs

and like I report every single one. All right, I want you to take a swing at this myth. Yes, AI is

going to make email developers completely obsolete, defend it, dismantle it, or make it more

complicated. But I want the version you actually say out loud for the audience is a junior

developer who's scared we're in a weird market for hiring. What are your

recommendations based off of your answer? Yeah, I feel like I talked about this a little bit

already. If I was talking to a junior developer, I would tell them to learn all the sides of email

marketing. You don't have to be an expert in all of it, but having that knowledge from all sides

positions you better positions you to be the strategist from the technical side. I mean, I would

tell them to get really good at the coding bit and understand why things are done certain ways,

and then they can layer AI on top of it. Like, I don't think AI should be

the way to do it, because at least is right now, because we see these llms randomly bright all the

time. What happens when your entire workflow hinges on the AI and it's not working? Or new

models really, or new models released? And in a standstill. If you want to use AI, you should be

layering it on top of what you're already doing to make you more efficient. It should not be doing

like the bulk of the work should just be making you faster. I agree, I think AI is like the

accouterments. It's the accessories that make it quicker, better, faster, but the fundamentals stay

the same. And to that point, I think it's just it's true for everything, even beyond email development.

Like be dangerous enough to be able to have the conversation. Like, I will never be. And I don't

want to be a Salesforce SFD CRM admin, but I can talk you

through what is not working and tell you how and recommend how to do it because it to your point

earlier, it's systems thinking it's design and architectural thinking, and as long as you are

dangerous enough in a lot of not just fields, but really niches within an industry you're

interested in, you can be unstoppable. Yeah, yeah. And so you need to, you know, it's like once

you know how to do the code, how can you learn systems to then make the emails dynamic? And what

do you need to know to be able to do that. And that's where your knowledge really comes into

play as opposed to just tinkering with code. Your approach to email, as we've mentioned, is

multifaceted, being not just that designer, that politician, but also a founder of a publishing

house which, like what? I need to know more. Those are very much not a typical resume stop

for a technical developer, and I feel very similarly. I come from a liberal arts background.

There's no direct translation except for critical thinking and reading and writing. And so how has

working across such different disciplines and contexts shaped the way you think about what

email is actually for, and how does AI change that answer at all? Yeah. So it's learning how to

communicate with people in all sorts of contexts. It's really what it is. And I actually was

I mean, be a marketer, figure out your audience. Right. So I actually this is really funny because

today I had to quickly draft up an email today to send out to parents at soccer because not only do

I coach soccer and vice president of the board, and I am the one responsible for running our

spring evaluations, which are next week. And I learned that parents were really confused about

them. And when I took over these evaluations, I had shortened. I had added more

emails to send out leading up to it because I came to it with an email marketer brain, and I

shortened up the emails a lot, knowing that people would don't read, and I linked to FAQs on our

website. I have learned that was a mistake. I should not have done that. All the information

needs, all the information needs to be in an email. I'm asking parents to do too much. Wow. I love a

perspective shift. Yeah, so I wrote up an email and I actually I've been using AI to help me write a

little bit for a lot of my volunteer work just because I'm doing so much. So I took an email I

wrote, and then I put it into Claude and I was like, hey, like, this is going to parents help me

make this more clear so that parents can get the information that they need. So it did that for me.

And I also I had to get it sent out today because like we were getting a lot of questions. That was

like a mindset shift for me to be like, okay, like this, going out to parents, I need all the

information in the email. I cannot expect them to click and go to a website to find out more

information, if they're confused or need more information about what even evaluations are. That

was a mind shift change. The other thing I've been going through is on the political

side, I'm now involved with our local Democratic Town Committee, and I kind of took over their

emails, and I'm trying to figure out how to grow that really nationally. I'm trying to figure out

how to grow that list. It's a very, very small list. It'll always be like on the smaller side. But

right now there's a lot of room for growth. But it's how do I get people to agree to sign up for

an email about local politics from a particular party. So that's that's been really

interesting to play around with different strategies to see what I can do there. That's

super fun. Good reminder. Always a B test or always be learning about your specific audience, right?

Right. Because that goes against every best practice, right? It's like I can't in these lists

are all way too small to do any testing. Like we're talking about like these particular groups,

these emails are going out to a couple of hundred people at most. I'm never going to have thousands

of people. Like, that's just not what these lists are going to be. So yeah, so it's kind of just

looking at what works and what doesn't work and kind of just making the change. Government has a

different threshold. I mean, like I hold like I our list, we use MailChimp and like I hold us mostly

because it is in MailChimp and I just know how quickly they can beat a block list people. I hold

us to really strict standards of who can get added and when they can get added, because I just

because I know MailChimp and I just don't want us to get blacklisted. Yeah. You know the risk as well.

But yeah. No, I, I feel similarly anytime, anytime I'm in charge, I'm like double verification. I

don't care what I want it because I refuse to abuse unlike everyone else.

Yeah. Yeah. Okay. Very last question before I let you go. Who is someone we have on the podcast,

particularly someone whose perspective on email martech or the intersection of technology and

creativity is not getting nearly enough airtime. I think you should have an on and Tomlin at some

point. See what she has. Sadly she's really she's a dear friend of mine and is so fun to talk to.

Her answer to these to similar questions like this are probably going to be totally different

from mine, and it'll be such a good conversation. Yeah, it's a good thing. We need diversity of

thought, because at some point you're going to need both sides of the approach to figure things

out. Absolutely. Thank you so much for coming on. Where can folks find you? Follow along. Yeah. So you

can find me on. I'm on LinkedIn a little bit so you can find me there. I have my

newsletter that's based around email development. It's called Med Codes email. So my website is

literally med code dot email. Hit me up there and you can always subscribe. And if you want more

thoughts about email development and AI and philosophical things about those topics.

Awesome. Well, thank you so much. Yeah, thank you for having me. Some listener takeaways.

AI is clearly earning its place in the hardest of problems, whether it's complex, liquid templating,

intensive if else logic. It means it's a precision tool, but not a generalist. I'm biased and like

being a jack of all trades, but it does require fresh context every single time, and it really

does fall apart on anything prescriptive as it relates to email coding, which means that the

prompt is literally the skill. And like, that's not news, but it's still a little frustrating.

So be sure to treat every output as a starting point that still needs your expertise. And

make sure you are investing in that and not just an AI subscription. Capture your brand's edge

cases your known rendering fixes your client specific or customer specific workarounds, and

feed that institutional knowledge into your prompts because otherwise into your prompts, you

need the outputs to be calibrated to your reality, not a generic average approximation of it.

Okay. Listener takeaway number two enterprise email. Like marketing cloud Bray's iterable level,

it still demands systems thinking and strategic technical partnership, which means that the AI and

drag and drop editors alone won't cut it. Especially where it counts. So developers who

master coding fundamentals first and then layer on AI on top. Well, outlast those

who build AI dependent workflows, because you need your foundation to be built on something you know

and can protect. So as a result, you need to learn all sides of email before you let AI do any heavy

lifting. Otherwise, you don't know how to troubleshoot when it goes wrong and take away.

Number three ISPs are shipping all of these drag and drop templates that fail basic accessibility

checks, which means for non-technical users or folks who are not particularly familiar with not

only the laws and regulations, but how it works, they're unknowingly sending inaccessible email at

scale. I don't think anyone is trying to be exclusive of anyone who could be a customer,

client, you name it. So these fixes aren't just Something customers should be in charge of.

They should be engineering shifts, product manager shifts. They're not huge engineering

lifts. They really aren't. Contrast ratios, language attributes, alt text. All this just needs

prioritization and it keeps getting put to the back burner. And it's not a capability

gap. It's just a prioritization problem. So if you're managing an email program audit those

templates. And if you're a PM at an ISP, this one's on you. And as customers of all the different

ISPs submit that feedback, get it prioritized. Especially now because all the aforementioned

things we've discussed, cloud code could probably get a solid V1 beta version out to certain

users. Just to get started with such a great conversation with Megan, this is exactly the one

our industry is in need of right now. Nothing about hype, not about panicking. Staying calm and

actually understanding from someone who's doing the work. Telling the truth about what tools can

and cannot do just yet. And I'm really appreciative for being so specific and honest and

really generous. And I hope every email developer email marketer person in martech who is quietly

terrified of code walks away from this being a little bit more grounded, a lot less alone. And

amidst this chaos, and for everything that we talked about today, the real use case is the

failure files, the practical starting points. This is the stuff you're not going to get from a

LinkedIn carousel. So share this one. And once again, thank you so much for tuning in to the

Making Sense of MarTech podcast. A special thank you to Christine Murtaugh, who edited this episode,

and an extra special thank you to Jenna Carter for believing in this passion project meets

business. Stay curious.