AI in web design

What does AI actually do in web design today?

Five jobs, and none of them is "it builds the site". From a description it gives you a first draft of a layout. It writes the repetitive code: forms, tables, grids, hover states. It suggests first copy. It generates images and icons. And it explains code somebody else wrote, which sounds like the least of them and in practice gives back the most time.

What it does not do, and what gets lost between the lines of every tool advert: it does not decide. Who this page is speaking to and what it should say, which point comes first, what gets cut, and whether a claim is even true, none of that comes out of a prompt. Those decisions are what separates design from colouring in.

So the real division is this: the model gives you typing speed and you give it direction. The figure at the top of this page puts that in two columns and deliberately marks neither of them with a cross; both columns are necessary work, and the question is only whose work each is.

Four families of tool, and where each one earns its place

The first family builds a user interface from a sentence. The best known is v0, whose own documentation says it produces React components as well as HTML and CSS for prototypes and landing pages; Lovable sits in the same group. Their right place is the prototype: when you want to see an idea so you can talk about it. Where they turn into trouble is when that same output goes straight onto the live site, because you have taken delivery of a project whose structure and dependencies you did not choose.

The second family is the AI features inside design tools such as Figma. These serve somebody already working in that tool and change nothing except the speed of the repetitive steps.

The third family is the AI panels inside site builders. Every builder has one now and the logic is clear: a user who does not want to learn design. That subject deserves its own discussion and we gave it one in the piece on AI website builders; here we only note that their output is not separable from the builder own template and inherits its limits.

The fourth family, and the one we use most, is the code assistants that work in your own editor and terminal and can see the real files of the project. That is their whole difference from a chat window. When the model can read your CSS file, its answer is about that code rather than about a hypothetical one.

On access from Iran, let us be straight: neither of the first two tools has a page in our AI reference, because we hold no measured facts about them. The Vercel terms that v0 sits under require the user not to be the target of United States sanctions or those of several other bodies, and Lovable pages will not open from this server at all for us to read. So we make no claim about whether they open or can be paid for.

Why you can spot a model output from across the room

Because it learned from what is everywhere, so it builds what is everywhere. The tells are specific, and once you have seen them you cannot unsee them:

• A thin coloured bar along one edge of a card, usually three or four pixels, in a colour that comes from that card position in the list.
• A fully rounded capsule for every chip, label and button, the ninety nine pixel radius that lives in every generated template.
• Three feature columns with round icons and three sentences of exactly equal length, even when the subject does not really have three parts.
• A purple to blue gradient behind the header and a soft glowing blob in the corner.
• In the copy: a long dash mid sentence, the "not only this but also that" construction, and a closing paragraph that is nothing but a summary of what is above it.

None of these is ugly, and the problem is not aesthetics. The problem is that they are recognisable. A reader who has seen thirty pages carrying these marks in the past month does not have to think about it; they file your page in the same drawer and then trust what it says exactly that much.

On our own site we turned this into a written rule. Section ten of the rgb.ir content rules file bans a coloured bar on the edge of a block, under that very heading, that it is a machine watermark, and section two of the same file bans the long dash and several other characters in the copy. The design rule also has a mechanical test: one text search across the whole theme and plugins that looks for a border of two pixels or more on a single edge and excludes the site own neutral border. On the day this lesson was written that search returns exactly fourteen lines and all fourteen are allowed: twelve for two arrowheads that are each built from two rotated borders, one disclosure triangle, and one line sitting inside a comment that documents this very rule. A fifteenth line means somebody added a stripe.

And a warning about the list itself: the tells change. What gives a page away today may be ordinary next year and something else will take its place. What does not change is the question rather than the list: did I make this decision, or did it just arrive?

How far can you trust the code a model writes?

As far as you can read it yourself. That is the only practical test and everything else follows from it, because code that runs on your server and sits in your visitor browser belongs to you from the moment you publish, and so do its bugs.

Four specific places where model output usually falls short, and all four show up more on a Persian site:

• Right to left. The model default is English and left to right, so it writes margin-left and text-align: left, and the output is correct in English and mirrored in Persian. The CSS lesson shows the logical properties that solve this.
• Accessibility. A div with onclick, a button with no name, and a deleted focus ring are all common in generated output. The accessibility lesson has the five minute test for it.
• Dependencies. A model adds a library easily, because it does not pay the cost. Every library is a future update and a possible future vulnerability; in the WordPress world that accumulation of plugins causes most of the site security trouble we see.
• The speed budget. The code works and it is heavy. Somebody who does not read the code does not see its weight either.

And one item that has nothing to do with code quality and is more serious: whatever you paste into a chat window has left your machine. API keys, database passwords, configuration files and customer data have no place there. This is not a claim about whether that service is good or bad; it is that a copy of that text now exists somewhere else as well.

So where is the time actually saved?

In mechanical work that has volume and no decisions in it. Our real list, taken from the jobs we hand over ourselves:

• Turning a list of design tokens into CSS variables with consistent naming.
• Writing forty alt texts once you have said what each image does on its page.
• The first draft of a component you already know you will rewrite.
• Reading and explaining CSS somebody else wrote three years ago.
• Translating interface strings into several languages when you supplied the glossary of terms.
• Merging repeated styles inside one large file.

Added up on a real project that is a few hours of typing, not a few days of deciding, and the difference is worth stating plainly. Anybody promising a complete company site in ten minutes is either passing a prototype off as a site, or talking about a site nobody will maintain afterwards.

And one saving that gets mentioned less and may be the largest of all: learning. When you take the output and ask the model to explain line by line what it did and why, the cost is those few minutes and what you gain is not needing to ask next time.

Draft with a model, ship with judgment: what does that mean in practice?

It means that between taking the output and putting the page up, you go over it four times yourself, looking for one thing each time.

First pass, right to left: turn every left and right you find into a logical property and look at the page in both directions. Second pass, keyboard: Tab from top to bottom and see where you are and where you get stuck. Third pass, weight: what has been added to the page that you did not ask for, from a font to a library. Fourth pass, the tells: run the list from section three over the output and change anything from that family.

The four passes together are perhaps twenty minutes, and the difference between doing them and not is that in the first case you have a page and in the second you have a page that is yours.

And one plain thing to close on: if your goal is not learning design and you only want your business to have a site, a model is not the shortest route. The shortest route is either a site builder, which we weighed up in a separate piece, or handing the work to somebody who knows those four passes.