The model was never the bottleneck

Building software with AI gets sold as a typing speedup. You describe what you want, a model writes the code, and the thing that used to take an afternoon takes a minute. The pitch is always about generation — how much faster the machine writes than a person does.

That is the misunderstanding. The site went live this week: Nelson Garden, a Nordic garden brand, its product catalogue and several hundred editorial pages rebuilt across four national markets and dragged off an ageing CMS on a deadline. Building it, the writing of code was never the slow part. The slow part was knowing whether what got written was right, and remembering what right even meant across hundreds of separate sessions. A model that generates faster than anyone can read is not an asset on its own. It is a way to produce wrong work quickly.

In 2012, Bret Victor gave a talk called Inventing on Principle. Its claim was that a creator needs an immediate connection to what they make — that the gap between doing something and seeing its effect is where bad work hides. He meant a person dragging a slider and watching a drawing respond. The claim is sharper for an agent, because an agent has no eyes. It cannot glance at a page and notice that an image is missing. Working blind is its resting state, and the entire job is to take that away.

So the first thing built was not code. It was a fixed point to measure against. The old site ran on Episerver, and its public API had a shutoff date. Before that date, all four Nordic versions were crawled and their responses and images frozen to disk — a copy that would never move again. Everything afterwards was checked against that copy. The task stopped being generate the new site and became make the new site agree with the frozen one, which is a question a machine can actually answer.

The frozen copy paid for itself within days. The converter that turned old article HTML into the new format silently dropped any image wrapped the wrong way — tucked inside a heading, buried in a div. On the Swedish site that was 533 images in the source and 118 that survived. Someone reviewing the result would have scrolled through hundreds of articles full of pictures and seen nothing wrong, because a missing image leaves no hole. The loop saw it, because it was not reading the page — it was comparing the page to the snapshot.

Then it checked its own repair, diffing every document it had touched against a backup to confirm it had added the missing images and changed nothing else. The fix and the proof that the fix was safe were the same kind of operation.

After that, the shape repeated. Every migrated page was diffed against the live sites and the gaps written to a report. A check on product labels queried the real dataset and failed loudly the instant a badge had no translation, rather than letting a Swedish word sit quietly on a Finnish card. None of these were clever. They were cheap — a script and a few seconds — and cheap is the entire point. An expensive check runs once, before launch. A cheap one runs every time, which keeps the work close to the last moment it was known to be correct.

The same idea covered intent, not just data. The spec lived in Linear — a project the agent could reopen at the start of every session — rather than in a chat history that forgets itself. The crawl was the ground truth for the data; Linear was the ground truth for the intent. The move was identical both times: keep the source of truth outside the work, so the work always has something to be wrong against.

What stands out, looking back, is the proportion: almost none of the time went into writing code, and almost all of it into building the things that could check it.

I didn't move faster because the model wrote the code, but because almost nothing it wrote could stay wrong for long.