Every few months, the AI pitch resets: this time the tools are good enough; this time non-developers can build production-ready email code; this time the developer is optional. Megan Boshuyzen has heard every version of that pitch, and she has spent the last two years actually testing whether any of it holds up. The answer is more specific, more honest, and more useful than anything you will find in a LinkedIn carousel.
Boshuyzen is the development lead at Inbox Army, with prior stops at Mailgun by Sinch and Email on Acid, on the infrastructure and QA side of the industry. A graphic designer by training who pivoted into code, she sits at the intersection of design systems thinking, accessibility advocacy, and hands-on email engineering. She is not anti-AI. She is anti-hype, which is a meaningfully different position.
The Real Use Cases Are Narrow, and That is Not a Criticism
Boshuyzen does not use AI to write email code. Full stop. Her explanation is blunt: the prompting overhead required to get anything usable out of a model is roughly equivalent to the time it takes to just write the code herself, especially since she already has tested snippets and components she can pull from. What AI has earned in her workflow is a different category of problem entirely.
The first real use case she points to is complex Liquid templating. A client needed to dynamically display products that were not housed in any CRM, and the instruction was that they could not be stored in the ESP either. All the product data had to be loaded directly inside the email via Liquid, matched against a code in the platform, with conditional logic controlling which products appeared for which recipients.
"I would not have been able to do that without the help of AI."
The second use case is JavaScript debugging inside her email design system. She describes herself as knowing enough JavaScript to get 90% of the way there, and using Claude Code as a second developer to find what she is missing: a wrong object reference, a missing curly bracket. The distinction she draws matters. The AI is not architecting the solution. It is catching the small thing she cannot see because she has been staring at the file too long.
The Prompt is the Skill, and That is Still a Problem
There is a version of the AI-for-email argument that goes: if you write a good prompt, you can build a good email without knowing how to code. Boshuyzen dismisses this as dangerously oversimplified, not wrong in every case, but wrong enough to cause real damage at scale.
Her reasoning is structural. AI is trained on patterns. Email rendering is built on exceptions. The MSO-specific CSS, the ghost tables, the blending-mode tricks that control text color in Gmail dark mode, the workarounds for Outlook that experienced developers treat as institutional knowledge: none of that fits cleanly into a training corpus. The model knows the rules. It does not know the accommodations.
"AI doesn't know nuance. AI knows patterns."
When she tested how far she could push Claude on conditional CSS and inline styling within her email design system, the model's answer was simply that the inliner could not handle advanced CSS selectors. That is a correct answer. But a developer who did not already know that would not know what question to ask in the first place. The model cannot teach you what you do not know to check.
The Democratization Argument Has a Trap in It
Email development has already been democratized in one sense: drag-and-drop editors mean that millions of people send email without touching a line of code. Boshuyzen does not see AI as a meaningful escalation of that trend so much as a pressure on a specific tier of the market. Small and medium businesses were already getting by without developers. That is not changing.
What is changing is the shape of where developer expertise actually matters. Her read is that pure-code email specialists who do not develop adjacent skills will be the ones displaced, not by AI writing better email code, but because the value they offer becomes thinner as tooling improves. The developers who stay relevant are the ones who understand the strategy, the design system, the ESP architecture, the why.
"Email developers need to look at becoming a strategic partner instead of just, oh, I'm the email developer I just sit in the code."
Her advice for junior developers is direct: learn all sides of email marketing, understand the reasons behind the code before layering AI on top of it, and make sure your workflow does not depend on a model that can go offline, change behavior with a new release, or confidently produce something wrong. The foundation has to be yours before the acceleration tool is useful.
The Accessibility Problem is a Product Problem, Not a User Problem
Boshuyzen's hottest take has nothing to do with AI. It is about where responsibility for email accessibility actually sits, and why it keeps not moving. The pattern she describes is consistent: emails that fail basic accessibility checks are frequently built from drag-and-drop templates by marketers who cannot access the underlying code and would not know what to fix if they could. The problem is upstream.
She names specific gaps she called out publicly at the industry conference by Litmus: the ability to set language attributes, the ability to set direction attributes for right-to-left languages like Arabic and Hebrew. Without a direction attribute, an ESP that assumes left-to-right rendering will display Hebrew letters in reverse order. She has watched it happen in real production emails. The fix is not complicated. It is not prioritized.
"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."
Her call is specifically to product managers at ESPs and the editor platforms those ESPs white-label: contrast ratios, alt text fields, language and direction attributes are not large engineering lifts. They are prioritization decisions. Until those decisions get made, the marketers using these tools are unknowingly sending inaccessible email at scale, with no mechanism to fix it themselves.
The Design System is Where the Real Work is
The project Boshuyzen is most energized by is the email design system she is building at Inbox Army, a single code base that supports the full range of e-commerce email layouts the agency produces. It is more complex than the SaaS company system she built previously because e-commerce means image-heavy layouts, multiple product configurations, and variant logic that keeps expanding as she builds emails against it and finds new edge cases.
Her architectural approach is worth noting because it runs counter to a common assumption. She codes using ghost tables and divs rather than pure tables, which some experienced developers argue is essentially writing the email twice. Her counterargument is forward-looking: when the Outlook Word rendering engine is eventually retired, removing the ghost tables is the only change required. The rest of the code is already written in modern standards.
"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."
Claude Code's role in this project is specific: helping with the JavaScript that ties the design system together, catching small errors in complex component logic, and handling calendar and project management automation, freeing her attention for the actual development work. The AI is an assistant inside a system she architects and owns. That is a meaningfully different relationship than asking a model to generate an email from a brief.
Three Takeaways
Feed your institutional knowledge into every prompt. Your rendering fixes, client-specific workarounds, and accessibility requirements will not be in any model's training data. If you do not provide them, you get a generic average approximation of email code, not code calibrated to your actual production environment.
Enterprise-level email programs still require systems thinking that AI and drag-and-drop editors cannot substitute for. Developers who learn coding fundamentals first and layer AI on top will outlast those who build AI-dependent workflows, because they can troubleshoot when models change behavior or go down.
If you are a product manager at an ESP, the accessibility gaps in your drag-and-drop editor are your responsibility to fix, not your users'. Contrast ratios, language attributes, and direction attributes are not large engineering lifts. They are prioritization decisions that have been deferred long enough.
Special thanks to Claude for helping to summarize this conversation.
Megan Boshuyzen is the development lead at Inbox Army. Her newsletter on email development can be found at megcodes.email.
