HTML email production and artificial intelligence

You'll have noticed that AIs are increasingly taking their place in the world of work. By 2025-2026, the use of AIs is no longer an option, but a necessity. a strategic necessity, with a utilization rate exceeding 60% in this sector (source : verified.email). Email is no exception: whether for illustrations or content writing, some service providers are already assisted by these AIs. But what about email production? Is it possible to have a ready-to-use HTML file with an AI? We took a closer look.

Objective: generate an HTML email using AI

To test the use of AI on email production, let's set up a certain framework. First, the’objective. Here, it will be to have a ready-to-use HTML file, with no need to rework the code. I carried out tests using 3 approaches:

1. Giving AI a model so that it can be reproduced as HTML code for the email, based on a design.
2. Provide email briefing and design guidelines to let the AI send me a newsletter
3. Give an email briefing for AI to work within a framework with existing components

1st test: based on a design

For this first approach, I first fed my AI (Claude) with our guide on how to code an email in HTML. Then I gave Claude the task of going through a number of HTML files we'd produced. On the basis of these elements, I asked him to write a document that brought together all the lessons he had learned, and to use this as a basis for writing HTML code for email.

Then I took a screenshot of the Badsender newsletter and passed it on to Claude with instructions to write me an HTML email file based on the design I'd sent him.

Here's the initial design:

The result was not usable. Content not respected at all ; AI has even invented items. The color codes didn't match, and there was absolutely no recognition of the original design that had been passed on to him, or even the graphic codes. The code, while not flawless, was to my surprise acceptable (here is the Email On Acid rendering, without images). While the buttons render poorly in Outlook mailboxes, in the rest of email clients the rendering doesn't break. There are variations, but these are within the realm of “acceptable degradation”.

2nd test: content briefing and design guidelines

The second approach begins like the first. I give Claude the guide and sample production files, and also give him the best practices file he compiled from the first test and ask him to update this file in case it was needed (unsurprisingly, it wasn't... ).

Then I gave him our guide to system design for email asked to browse the Badsender site and build himself a system design file for email that he could use to build emails.

Based on these two elements, the best practice guide and the system design, I gave him a briefing containing the copy and asked the AI to generate a ready-to-use email for me.

The result is already significantly better. The code holds up (he even managed to arrange the buttons in Outlook!) and the rendering is much more consistent with Badsender's graphic style. Not all is perfect, but the file received is functional and usable. To achieve this result, however, a certain number of iterations were necessary, asking you to correct certain points step by step. For me, the limitations are that you have to accept that the rendering is “about right”. Everything is “more or less” right. You also have to accept that you can't control the structure. It's probably something that can be built up bit by bit, enriching the AI as you create emails. So a passable and functional result, But it hasn't yet reached the level of finish of an email builder or “handmade”.

3rd test: using the Maizzle framework and a component library

For this last test, I framed the AI in a Maizzle project. I've included components, a graphic style and a custom template.

The idea is that Claude should no longer be able to interpret what he considers to be the correct code or graphic style, but should be confined to what has already been prepared for him. Maizzle is the perfect tool for this. As it's a technical framework, Claude can handle it quite easily.

Finally, I simply briefed Claude once again, specifying for each section which block to use (text-image block, intro block, etc.). And the result this time was impeccable. I had the exact rendering that I wanted, having only written a briefing. For the exercise, I limited myself to rewriting two blocks, but this shows that, within a framework defined by the framework, you have total control over the desired result.

Conclusion

What I've learned from this experience is that, while AI may be ready to replace humans for pure development, this isn't quite the case yet when there's a defined system design, and it needs to be framed so that the work output is relevant.

It's worth noting that I re-tested with Claude between version 4.5 and 4.6, and the result seems to be better with 4.6. So it's still evolving. I'd also like to point out that if I haven't succeeded in giving Claude a Figma design, in the meantime Figma and Claude improve their interoperability.

The use of AI can therefore facilitate and accelerate production processes. Here, once the Maizzle project has been set up, email production can simply be based on a text briefing. In a way, it's the “cheap” version of an email builder: instead of composing your own email in a graphical interface, you write a document for the AI, which will create the email based on the elements provided to it. For those wishing to evolve within a locked graphical framework and simply produce emails quickly and efficiently, this will work very well.

We can of course create a Maizzle project for you. if you'd like to give it a try.