Using AI to build email HTML feels efficient right up until you count what it actually costs you.
Every time you ask a chatbot to generate a template from scratch, you’re paying to solve a problem that email builders solved years ago, and you’re paying again every time you ask it to fix the version it just gave you. I’ve spent thirty years watching email tooling evolve, and this is the first time I’ve seen marketers pay more, get less reliability, and call it progress. 🤷♂️
Stop Asking AI to Build Email HTML
The tokens you’re burning on a solved problem
A production HTML email isn’t a short document. It’s nested tables, inline styles repeated on every element because email clients ignore stylesheets, Outlook-specific conditional comments, and fallback fonts stacked three deep.
Every one of those tokens gets generated fresh, every single time, when you ask a model to write it from a prompt. A drag-and-drop builder like Stripo or BEE stores that structure once, tested, and reuses it for free on every send. You’re not paying a subscription to avoid learning HTML, but to stop re-solving a problem that has a known, working answer.
This is the same economics I apply to any automation decision. If a task is deterministic (the same input should produce the same reliable output every time), it belongs in a system built for that, not in a model that generates a fresh, slightly different answer on every call. Email HTML is about as deterministic as marketing gets. You want the same header, the same button behaviour, the same fallback fonts, every time, for every send.
Ask it to fix one thing, and it breaks another
This is the failure mode nobody warns you about.
You ask AI to widen a column, and the button padding shifts.
You ask it to fix the padding, and the mobile breakpoint stops working. 🤦♂️
This isn’t bad luck, but a structural property of how these models work. GitClear’s independent analysis of 211 million lines of AI-assisted code found that code churn, the share of code rewritten within two weeks of being written, roughly doubled between 2020 and 2025, while the proportion of genuinely refactored, reused code fell from around a quarter of all changes to under 10%. Duplicated code blocks rose eightfold in a single year. That’s not a coding-specific quirk. It’s what happens whenever a model regenerates output without full memory of every earlier decision it made.
The mechanism now has a name: context rot. As a session grows, earlier constraints carry less weight than the most recent instruction, so a fix five prompts in can quietly contradict a decision from prompt two. In a website, that shows up as a bug. In an email template you’re about to send to 200,000 people, it shows up as broken padding in Outlook that nobody catches until the complaints start.
Email HTML was never a fair fight for AI
Even without the regeneration problem, the underlying task works against a general-purpose model.
Outlook for Windows renders HTML using Microsoft Word’s engine, not a browser engine, so flexbox, grid and max-width simply don’t apply. Gmail clips any email past 102KB of HTML and drops your entire style block if a single rule has a syntax error.
A model trained overwhelmingly on modern web development produces exactly what you’d expect: code that looks flawless in a browser preview and falls apart the moment it hits an actual inbox. Stripo’s own comparison of AI-generated HTML against purpose-built output put it plainly: generic LLMs still build web HTML, not email HTML, which is why the output breaks in Outlook, Gmail and Apple Mail. There’s no guardrail warning the model that a background image needs a VML fallback for Outlook, because that constraint doesn’t exist anywhere in the web development patterns it learned from.
Layer dark mode on top and the case closes itself. Litmus’s own subscriber data puts over 40% of opens happening in dark mode, and every major client handles the colour inversion differently, with no single coding pattern that works across all of them.
A dedicated builder has already fought that fight and baked the fix into its output.
A model generating from a prompt is fighting it blind, every time.
Where AI is genuinely worth the tokens
None of this makes AI the wrong tool for email marketing. It makes HTML production the wrong job for it.
The jobs that actually suit a language model are the ones with no fixed right answer, where judgement and pattern recognition beat a rulebook.
- Segmentation and predictive analytics. Spotting who’s about to churn or who’s likely to buy next is a statistical pattern problem, exactly what these models are built for.
- Hyper-personalisation at scale. Tailoring product recommendations or send timing to thousands of individual behaviour patterns isn’t something a human can do by hand.
- Subject line and copy variants. Generating and testing dozens of angles for an A/B test is cheap, fast, and disposable by design, so regeneration inconsistency doesn’t matter here.
- Image generation for creative concepts. Producing visual drafts and concepts to react to, not final production assets.
- Campaign analysis and reporting. Summarising performance and flagging anomalies across a list of campaigns is language work, not layout work.
Validity’s State of Email 2026 report found that teams with deep AI integration are 75% more likely to hit an email ROI above 45:1 than teams using it superficially. That gap comes from AI doing the analytical and personalisation work a human can’t do at the same scale, while the production work stays in tools built for exactly that job.
The comparison that should settle it
Put the two approaches side by side, and the decision stops being about preference and starts being about arithmetic.
The table below is how I explain it to clients who are still on the fence.
My rule of thumb
If the output needs to be identical, tested and reliable every single time, it goes in a deterministic tool.
If the output benefits from judgement, pattern recognition or genuine variation, it goes to AI. Email HTML is the first category. Segmentation, personalisation and copy variants are the second.
Confusing the two doesn’t just waste tokens, but also puts a broken email in front of your entire list and calls it innovation.
Leave a Reply