How to Keep AI-Built Products Consistent as They Grow

The first page is not the problem. The first page usually comes out fine.

You build the homepage with an agent, iterate for twenty minutes, and it looks good. Then pricing. Then settings. Then the dashboard. Then a feature nobody planned for.

Somewhere around page five you open two tabs side by side and they do not look like the same product.

This is worth understanding properly, because the instinct is to blame the model and the cause is structural.

The mechanism

Getting the homepage right involved corrections. Maybe fifteen of them: bigger headline, less purple, tighter section spacing, drop the shadow, use the same grey as the nav.

Every one of those corrections lived in the conversation. When the conversation ended, they went with it.

So the pricing page starts from the same defaults the homepage started from. You correct it again — but not identically, because you are working from memory rather than a list. You remember "less purple" and forget "drop the shadow". Now pricing has shadows and the homepage does not.

Repeat four more times. Each page carries a different subset of your preferences. Nothing went wrong at any individual step, and the result is still incoherent.

The technical term for this is drift, and the reason it is hard to notice is that it accumulates in units too small to see. Nobody looks at 8px versus 12px of padding and calls it a bug. Forty of those and the product feels cheap without anyone being able to say why.

Where it shows up first

In rough order of how early it appears:

Font sizes. The fastest-drifting property, because almost every element has one and the scale is continuous. You end up with 15px, 16px and 17px body copy on three pages.

Spacing between sections. 32px here, 48px there, 40px somewhere. Individually defensible, collectively arbitrary.

Greys. This one is almost comical once you look. Count the distinct grey values in a six-page AI-built app and you will often find nine, each within a few units of another, each arrived at independently.

Elevation. Page one uses shadows, page three uses borders, page five uses a surface tint. All three are valid; having all three is not.

Radius. 6px on one page, 8px on the next, 12px on the third.

Button hierarchy. The one that hurts most. Once several pages each have two or three filled accent buttons, the accent stops meaning "this is the action" and becomes decoration.

Catching it

A quick audit that works well: ask the agent to count rather than judge.

Across the pages in this project, list every distinct value used for:
font-size, section vertical padding, border-radius, and text colour.
Group identical values. Do not change anything.

You get back a list. If font-size has eleven entries and border-radius has five, that is the drift, quantified, in a form you can act on. It works because counting is something an agent is reliably good at, unlike "does this look consistent".

Run it after every few pages. It takes a minute and it catches drift while it is still cheap to fix.

The fix is to move the decisions out of the prompts

Everything that follows is one idea in different clothes: a design decision should be written down in one place, outside any individual conversation, and referenced rather than restated.

Put the values in a file the agent reads

A markdown file in the repo. The scale, the colour roles, the spacing steps, the component rules. Reference it in the prompt:

Build the settings page. Follow DESIGN.md.

rather than re-typing the rules each time. This alone removes most drift, because the source is now identical for every page instead of being your memory on a given afternoon.

If you have not written one, there is a walkthrough. It takes about an hour and most of that is deciding rather than typing.

Name colours by role, not by hue

blue-600 does not tell an agent what blue-600 is for, so it will use it for whatever seems reasonable. primary with a note saying "primary actions only" carries the constraint.

This is what stops the nine-greys problem. If muted is the only name for secondary text, there is no reason to invent #6B7280 on page four when #605D52 already exists.

Prefer real components over described ones

If you have a <Button>, the agent composing from it cannot get the button wrong. That is stronger than any written rule, and it is the one form of consistency that is actually enforced rather than requested.

So as pages accumulate, promote the repeated things. The third time a page needs a titled panel with a hairline border, make it a component. From then on that pattern cannot drift.

Written rules are for what components cannot cover: page-level layout, heading hierarchy, how much space sits between sections.

Write the prohibitions down

Positive rules keep the good things consistent. Negative rules stop new categories of thing appearing:

- No gradients
- No box-shadow; depth is surface colour
- No font sizes outside the scale
- One primary action per view

Four lines, and they close off most of the ways a new page can arrive looking different from the others.

Audit at the end of each page, not at the end of the project

One extra prompt per page:

Check this page against DESIGN.md and list every value that does not come
from it.

Cheap, and it catches the specific failure where the agent needed a value the file did not cover and quietly invented one. Those inventions are where new drift enters, and the fix is usually to add the missing value to the file so the next page has it.

The thing that surprised me

I expected the file to help with the first page. It helps a bit — mostly it saves retyping.

Where it actually pays is page twelve, built weeks later, by which point I could not have told you from memory what the section spacing was supposed to be. The file could. The page came out matching, first try, and I had contributed nothing to that beyond having written eight values down once.

That is the real argument for keeping design decisions out of prompts. Not that it makes any single page better, but that page twelve looks like page one without anyone having to remember why.

If you would rather not write the file from scratch, DesignMD reads a site whose visual language already works and produces it — the actual values, named by role. But an eight-line file you wrote yourself beats a perfect one you never got round to.