But it worked in the demo!

I built a system called IRIS, entered it in a hackathon, and it won. Fourteen agents doing security analysis, and part of why it won was how complete it was: documentation, the edge cases handled, a test plan, the corners filled in rather than faked. What the room did not see was that the version I submitted was already the third. I had rewritten it twice before, not because it was broken but because I find it very hard to leave code alone, a trait I fight more than I trust. By the standards of a hackathon it was not a rough prototype. It was a careful, complete, working thing.

And it was still nowhere near a product. It has been heading to production since, and it is now close to fifty thousand lines of Go before you count the front end, and the distance between the polished thing that won and something you could put in front of all comers turned out to be the most interesting part of the exercise. It was not more features. It was not the corners, which I had already filled in. It was everything that stands between a thing that works when I run it and a thing that keeps working when people who are not me run it, and “finished” was never going to describe the end of it, because finished is not a state software reaches. Ever.

One word, two jobs

“It works” is doing two completely separate jobs, and the confusion between them is the whole subject here.

There is works-in-the-demo: it did the thing, once, on the path I chose, while everyone watched. That is a photograph of success. And there is works-as-a-product: it does the thing, again and again, for people who are not me, on inputs I never thought of, and it keeps doing it after the next person changes something underneath it. That is not a photograph. It is a promise.

A prototype hands you the first and feels like the second. That is the seduction, and it is old. What is new is that the tools made the photograph nearly free while leaving the promise exactly as expensive as it ever was. The demo is the holiday romance in your early twenties. You can see the flaws perfectly well, and for those two weeks you are happy to ignore every one of them. The product is the marriage, where the flaws are the work. Anyone can manage the first.

The distance is not what the internet says it is

Search for why the last mile is hard and you get a checklist: edge cases, security, business rules, the input nobody expected, the load nobody tested. All true, and all mostly the apparatus I have written about elsewhere, the scaffolding a thing needs once other people depend on it. That is a real cost, but it is the wrong emphasis, because it describes the distance from the outside. From the inside the reason is quieter, and it is about knowledge.

I had that knowledge for IRIS. I had rewritten the model of it into my own head twice before anyone judged it, and even then the distance to a product ran to fifty thousand lines. What makes the distance worse for almost everyone else is the place where that knowledge goes missing. When you write software by hand, or rewrite it until you understand it, you build a model of it in your head as you go, line by line. That model is the thing that lets you debug it later, extend it without breaking it, and know in your gut which part is fragile. You never decide to build the model. It accumulates while you work, a by-product of the labour, and you pay for it without noticing you are paying.

When the code is generated for you and you keep it as it came, you get the code and you do not get the model. You are handed a finished stranger and asked to vouch for it, and the understanding that authorship used to smuggle in for free is simply not there. Nothing arrived with the code except the code.

So the distance from toy to product is the cost of building that missing model after the fact. And building it after the fact, from the outside, by reading and testing and breaking the thing, is slower and harder than building it as you go, because you are reverse-engineering understanding out of a finished artefact instead of accumulating it while you make one. This is the part the checklist misses. The thousand prompts it takes to close the gap are not the cost of the code. The code was cheap; that was the first hard part and it is solved. They are the cost of the understanding you deferred, paid back with interest. And there is no prompt that discharges that debt except the iteration that rebuilds the model, because the model was always the product and the code was only ever its shadow.

What the thousand prompts actually are

This reframes the iteration, and the reframe matters, because seen wrong it feels like failure and seen right it is just the work.

Every round looks like fixing the code. Change this, handle that, it broke on this input, tighten that behaviour. But the code change is the visible residue. The real event, each time, is you discovering one more thing your model of the system did not account for, and updating your model to include it. You are not patching the artefact. You are learning it, one correction at a time, and the patch is just where the learning shows.

Which is why “just iterate” is true and useless in the same breath. The iteration cannot be shortcut, because it is not busywork wrapped around the understanding. It is the understanding being assembled. You can no more prompt your way past it than you can read the review of a book and say you have read the book.

There is a cleaner way to name what is happening. A prototype is a lossy compression of a product. It kept the shape, the happy path, the part you could show, and threw away everything that was not on screen, which is most of it. Iteration is the decompression, and you pay for it in full, because the detail that got thrown away was never actually free. It was deferred. And there is a trust cost sitting on top: the demo earns a burst of confidence it has not proven, fluency turning the dial up before anything has been tested, and the distance is exactly where that unearned trust meets reality and gets repriced, one failure at a time.

Nobody was told the distance was there

Here is the part it would be easy to get wrong, and I want to get it right, because the wrong version is a lecture.

Someone arriving at this now, building real things with these tools and no twenty years behind them, was never told the distance existed. The demo felt like arrival because nobody explained it was a photograph. That is not a failing in them. It is a structural property of tools that make the first “works” free and leave the second one untouched, and it would fool anyone who had not been fooled by it before. I have been building software for thirty years and the fifty thousand lines still surprised me.

So the useful thing is not “learn to code properly first,” which is a gate and, in 2026, mostly the wrong advice. The useful thing is to name the distance, so that hitting it stops being a demoralising surprise and becomes the expected shape of the work. The prototype was not ninety per cent of the product. It was the first five minutes of building the model, done for you, and the model is the job. Budget for the iteration as the main event rather than the cleanup. Treat each round as learning the system, not tidying it. And keep the prompts you wrote, because that history is the record of what your model did not yet know, which is the nearest thing you have to the notes you never took.

I should concede the obvious counter, because it is real and it is coming fast. The tools are getting better at the distance too, not only at the first mile. The gap is narrowing from both ends. But the same asymmetry holds here as everywhere in this: they get better at producing the product, and they do not hand you the understanding of it. If a person is going to own the thing, keep it alive, be woken at three in the morning when it breaks, then someone still has to hold the model of what it does, and a more capable generator does not transfer that model any more than a better ghostwriter makes you know your own book. Better execution is not understanding. It never was.

Where this leaves it

The first hard part gave everyone the demo, and I would not give the gift back. Letting people build the thing they can picture, the same afternoon they picture it, is one of the better things to happen to software in my career.

But a demo is a photograph of a product, and the distance between the photograph and the thing is not features and it is not effort for its own sake. It is the understanding that authorship used to include in the price, now sold separately, payable only in iterations, and there is no version of the tools that closes it for you, because the understanding was always the product. The code just happened to be the part that used to look hard.