The designer as system architect: a working AI front end workflow

How should designers work with AI code generation? Not by handing a finished mockup to a generator and then fighting what comes back. Brief the model with a written design system before you generate a single screen, generate inside the component library instead of freehand, and review the output against that system rather than against taste. That is a five step loop, and it is the actual workflow behind this site: designed and built as one continuous act, with the system as the contract the model has to work inside.

Most teams are not running that loop yet. They are running the old handoff with a faster typist attached to it, and the speed is hiding a review problem that is about to get much bigger.

The old handoff with a faster tool

The default way teams have folded AI into front end work is to keep the old sequence and swap one step. Design a mock, hand it to a generator instead of a developer, then spend the review meeting arguing about what came back. The draft got faster. The review did not, and in most teams I have watched adopt these tools, the review got slower, because now someone has to catch drift that a human collaborator would never have introduced on purpose: a spacing value invented on the spot, a state the component was never asked to handle, a color a shade off the palette because the model was pattern matching on vibes instead of reading a rule.

None of that is a model failing at its job. A generator without a system to read is doing exactly what it was asked: producing something plausible. Plausible and consistent are different properties, and consistency was never going to come from a prompt alone.

Where the loop starts

The workflow that actually holds starts at the system, the same foundations that this site is designed and built on: color as named roles with contrast pairs, a type scale with rules, spacing on one base unit, and every interactive state named before a component is allowed to exist. A model briefed with that system produces inside it. A model briefed with a screenshot and a vibe produces something that merely resembles it, and the two look identical for about a day, right up until the third component reveals the drift.

This is the same lesson design systems have always taught, just applied one level up. A rule written down and reused is worth more than a decision remade every time, and that was true before any of this tooling existed. What changed is the cost of ignoring it. A human developer improvising past a gap in the system produces one inconsistency you catch in review. A model generating at speed produces the same inconsistency ten times before lunch, because it has no memory of the argument you had about it last week unless the system itself carries that argument forward.

The five step loop

System first. The foundations and the named states have to exist as a written thing before any generation happens, not discovered mid session by whichever prompt someone happens to type. If the system is not written down, you are not briefing a model, you are hoping one.

Brief the model. Every generation starts with the system and the real content for that screen, never a placeholder. Lorem ipsum and a vague description are how a generator ends up inventing spacing and copy tone that then has to be unwound later.

Generate inside the library. The output has to compose from named components and variables, not new markup that happens to look right. Freehand generation is where drift enters, because a model with no library to point at will build its own version of a button rather than reuse yours.

Review against the system. This is a review against the written rules and the accessibility bar. Personal taste does not get a vote. Treat the output the way you would treat a junior contributor's first pull request against a codebase: assume it is close, check it against the standard, and be specific about what broke and why.

Fold corrections back. The step almost every team skips. A correction that only lives in that day's review teaches the model nothing and the same drift shows up again next week. A correction folded back into the system, as an updated rule, a new named state, a tightened variable, means the next generation starts from a better brief than the last one did. This is the step that turns the loop into a loop instead of a straight line you walk over and over.

The loop closes because step five feeds step one. That is also why it beats the old handoff on more than speed. The old handoff had no memory. Every screen relearned the same lessons. This one accumulates.

Building a working version of this loop, system documented and generation briefed against it, is a large part of what my design to development handoff work looks like when a team asks for help getting past the plausible-but-inconsistent stage.

What the loop caught here

Review the output the way you review a junior's pull request, against the system, not against taste.

The rule that keeps the loop honest

I run this loop on my own front end, so the failures are not theoretical. The commonest one is not a dramatic bug. It is a generated component that looks correct at a glance and is quietly using a spacing value adjacent to the scale rather than on it, close enough to pass a fast look and wrong enough to show up the moment two of them sit next to each other. The fix is never just fixing that one instance. It is naming the gap that let it happen, usually a state or a rule the system had not written down yet, and adding it, so the next generation does not have to guess in the same place again.

That habit, folding the correction back into the system instead of just fixing the instance, is the same discipline I have argued for in design systems generally, and it is the reason the case studies collected at the work I have shipped hold together across very different products. The tool doing the generating changed. The discipline that keeps output consistent did not.

The old handoff versus the loop

The draft speed is roughly the same in both columns. That surprises people, because speed is the thing everyone expected AI to change. What actually changes is where the slow part sits. In the old handoff, the slow part is review, and it never gets faster because it never learns anything. In the loop, the slow part is writing the system in the first place, which is genuinely slow the first time and then keeps paying that cost down on every generation after.

Takeaways

Write the foundations and the states down before you brief a model with anything, so the system is what gets read first, before the screen. Generate inside the component library on purpose, because freehand generation is where the drift enters. Review the output against the written rules and the accessibility bar, the way you would review a junior's pull request, rather than trusting a glance that it looks close enough. And treat every correction as a system update rather than a one off fix, because that is the step that turns a single generation into a loop that actually improves.

The tools will keep getting faster at the draft. The teams that get ahead are the ones who stop treating that as the whole workflow and start treating the system as the thing the workflow actually runs on.

The workflow above is about how the work gets made. If you want the career case for why owning the rules matters more than owning the output, that is the argument in own the system, not the screens.