Fast to Build, Slow to Finish

Since the summer, we've been cranking out websites here at a ridiculous pace. "We" means I describe what I want, an AI agent writes the code, and I look at the result and point out what's wrong. The first part is absurdly fast. Scaffolding, database, admin panel, forms: things that used to take days are often done before my coffee gets cold. The second part, fixing things, now eats most of the time.

It comes down to how the agent sees a page. It reads source code. It knows which rule hits which element and can explain every line. What it doesn't see on its own is the result in a browser, and it has even less of a sense for what it's like to click through the thing. As far as the agent is concerned, a page is done when the code is right.

My favourite example is a web app for a photo booth. Every check passed, and the agent reported it as done. I opened it and saw every screen stacked on top of each other: start screen, camera, admin, Wi-Fi settings, PIN pad and on-screen keyboard. A single CSS rule, display: flex on a class, had overridden the hidden attribute. You'd never spot it in the code. One screenshot and it's obvious.

This site had the same kind of problem on phones. The project cards stack on top of each other as you scroll. On a narrow screen, though, a card with a long description gets taller than the display, and everything below the edge was out of reach. When I measured it, five of the eight cards were missing lines. The same day, a project image collapsed to zero pixels wide, because it's absolutely positioned and the grid shrank it to the width of its content. Both make sense once you know what's going on. You still have to see them first.

Anything that happens over time is harder still. "Make the transition faster" is a clear instruction to me and a guess to the agent. We went round in circles on one animation until I sent a screen recording of the reference. The agent read the colour values at one fixed pixel frame by frame and got the real number. The transition took 0.4 to 0.5 seconds, and we'd been working with 1.4 to 1.6. To be fair, I was the one who'd originally asked for "slow". When it rebuilt the contact section from a reference site, it measured that site very carefully. It just picked the wrong section.

Then there are bugs where the code is fine and the wrong thing still shows up. One web app kept showing its old version after every update, because the service worker preferred its cache to the network. The agent fixed bugs, I kept seeing the old ones and reported them again. We talked past each other for several rounds before it became clear that the server had been sending the new version all along.

All of this turned into fixed rules. A UI change only counts as done once a headless browser has taken screenshots at desktop and phone widths, following the same path a visitor would take. And every screenshot gets looked at. That sounds obvious, but it wasn't. Once, 13 screenshots were taken and five of them opened. One of the other eight showed the JavaScript error I ended up finding myself. For animations, I send videos instead of adjectives, and "make it like this site" means reading the actual values, not estimating them.

It's still faster, by a long way. I just spend less time in the code and more time in front of the screen, checking that what it shows is what I actually meant.