A strange thing happened to design: it stopped being the hard part. Give a good AI design tool a clear brief and half an hour and you’ll have something genuinely beautiful — screens, states, a whole visual system. A skill I spent years wishing I had is now, honestly, a no-brainer. I describe, it draws, I react, it refines.

So the muscle I’m actually building these days isn’t how to design with AI. It’s the step after, the one nobody warns you about: how do I make the coding agent respect the design? All of it. Every screen, every spacing decision, every hover, every empty state — not the impressive first eighty percent followed by a confident summary and a quiet abandonment of the rest.

Because that’s what happens, reliably, if you let it.

Crash testing is not taste testing

My first instinct was the classic one: add tests. And tests help — but notice what they actually check. Tests are crash testing. They tell you the form submits, the route resolves, the app doesn’t fall over when you press the strange button. They are magnificent at does it function and completely blind to does it look like the design.

Nothing in a normal test suite fails because a card’s corner radius is wrong, or because the evening theme was never applied to one modal, or because the loading state is a spinner where the design shows a skeleton. Visual fidelity is a category of correctness our whole testing tradition just… doesn’t see. And a design file is not a picture — I’ve written this before, but it’s the crux — it’s a list of demands. Every difference between the mockup and the build is a feature: a real code change, often one that rewires logic that already exists. “Make it match” is a hundred small engineering tasks wearing one sentence.

Why the agent gives up

Here’s the failure mode, and it took me a while to see it clearly, because it doesn’t look like failure. It looks like success with a good progress report.

The agent doesn’t refuse the work. It doesn’t error out. It starts strong, implements the first screens faithfully — and then, somewhere in the middle of a long run, the ask itself begins to dissolve. The context window fills with tool results and diffs and its own reasoning, the full brief fades into the noise, and the agent’s working sense of “the task” quietly shrinks to whatever it happened to start with. Then it finishes that smaller thing, and — this is the part that used to infuriate me until I understood it — it sincerely declares the job done.

The ask decays over a long run Four stages of an agent run. The full ask starts complete, then shrinks as context fills with tool results and reasoning, until only the first slice of the task remains — and the agent declares that slice done. WHAT “THE TASK” LOOKS LIKE TO THE AGENT, OVER TIME the full ask every screen · every state start most of it edge cases fading tool results · reasoning mid-run the happy path tool results · reasoning · more tool results late what it started with “done ✓” signs off on the slice end of run The agent doesn’t abandon the task. Its sense of the task shrinks — and it honestly declares the shrunken version complete.
The quiet failure mode. The agent completes what it started with, not what you asked for — the ask decays as the window fills, and the sign-off at the end is sincere. It isn’t lying; it’s grading a smaller exam.

It isn’t lying. It’s grading a smaller exam. What the AI thinks the task is and what you actually asked for drift apart over the length of the run, and the sign-off at the end honestly describes the shrunken version. I used to read those confident summaries and think the model was cutting corners. It’s more precise to say the corners fell out of its memory — and nothing in the loop ever forced it to go back and count them.

The agent completes what it started with, not what you asked for — unless the loop forces it to re-read the ask.

— the sentence I now design every workflow around

The sign-off loop

So the craft — the thing I now spend real hours engineering — is the loop around the agent, not the prompt into it. I’ve started calling it what it is: loop engineering. The wish-versus-contract idea from my last piece, taken all the way into the visual world.

The version that works for me has four moves, and none of them is optional:

Make it look at its own work. Not re-read its own code — look. The agent takes a screenshot of what it actually built, running, and puts it next to the design. The gap between “the code says the button is there” and “here is what a human will actually see” is enormous, and a screenshot collapses it. Self-comparison against the design, with real eyes, every step — not at the end.

Make it re-read the full ask, every pass. The to-do list — every screen, every state, the whole brief — lives outside the loop and gets re-consulted on every iteration, the way I keep a project’s brain on disk instead of in the window. The ask can’t decay if it’s re-read instead of remembered.

Make sign-off a gate, not a sentence. The agent doesn’t get to say “done.” It has to audit — walk the checklist item by item, screenshot in hand, and either mark every line verified or name precisely what’s still off. Partial credit doesn’t exit the loop; it re-enters it with the gap spelled out.

Make trying again the default. The loop’s only exit is the audit passing. Not effort exhausted, not “looks close,” not a wall of text explaining how much was accomplished. If the comparison finds a gap, the gap becomes the next piece of work, and around it goes.

The sign-off loop A loop: build a piece, screenshot the result, compare it against the design, re-read the full checklist, then audit. Only a pass exits to done; any gap loops back to building with the gap named. THE SIGN-OFF LOOP — THE AGENT MAY NOT SAY “DONE”; THE AUDIT SAYS IT the design every pixel a demand held outside the loop build a piece one item, not the world screenshot it look with real eyes compare to design side by side, honestly re-read the list the FULL ask, restated audit: signed off? every item checked, or name the gap done earned, not declared all items pass gap found → back in, gap named, no credit The design never enters the loop’s context as memory — it’s re-consulted every pass, so it can’t decay.
Loop engineering. The agent builds one piece, looks at it with a screenshot, compares against the design it re-reads every pass, checks the full list, and audits itself. “Done” is the exit condition of the loop — never a sentence the model gets to say early.

The first time I watched this actually run — build, screenshot, compare, catch its own missing hover state, fix it, compare again, then sign off — it felt less like prompting and more like having taught someone a work ethic. Which is close to what it is. The model brings the capability. The loop brings the integrity.

The two-year differentiator

I keep calling loop engineering a two-year differentiator, so let me say why I believe the number.

Everyone now has access to the same models, and soon everyone will have the same one-shot results: impressive, eighty-percent-faithful, quietly incomplete. The gap between builders is collapsing everywhere except here — in who can close that last twenty percent reliably, repeatably, without a human eyeballing every screen. That’s not a model capability; models will keep improving and the ask will keep decaying anyway, because windows are finite and long tasks are long. It’s a systems skill. Checks, gates, re-read briefs, screenshots as evidence, done as an exit condition — the unglamorous scaffolding that turns a brilliant intern into a dependable one.

Skills like that don’t diffuse overnight. They spread the way testing culture spread — slowly, through people who got burned. That lag is the moat. Two years, roughly, before “of course the agent audits its own screenshots against the design” is as unremarkable as “of course we write tests.” Until then, the builders who engineer the loop will ship things that simply match, and everyone else will keep shipping confident summaries.

The design was never the hard part. Believing “done” was.