Four. That's roughly where a build first passes its own verification and produces something that actually runs — a working page, a working endpoint, a login flow that logs someone in. Eleven is the median number of prompts a build racks up by the time someone calls it done and deploys it. Sixty-eight percent is the share of every prompt sent after that first working version that changes nothing a user would notice in the underlying logic. And thirty is where most people quietly stop, not because the product is finished, but because they've run out of things to say about it.
Those four numbers describe the same shape over and over: builds get functional fast, then spend most of their remaining life getting talked about instead of rebuilt.
The wall isn't where you'd expect it
If you asked me before I started paying attention where builders get stuck, I'd have guessed integrations — payment providers, auth callbacks, the SMS API that needs a verified sender ID. Those are real friction points, but they're not where the prompt count balloons. They usually cost one or two extra turns and then resolve.
The wall shows up later, after the thing works. A build reaches its first clean verification pass — pages render, the core flow runs end to end, nothing's throwing errors — and instead of stopping, the prompts keep coming. "Make the header bigger." "Try a different accent color." "Can the button be a little more rounded." "Actually go back to the first version of that." None of these touch a data model, a route, or a permission check. They're all surface.
Why "done" doesn't feel like a stopping point
Part of this is just how iteration feels from the inside. When a build is broken, you know exactly what to ask for — fix the error, add the missing field, connect the thing that isn't connected. When it's working, the target disappears. There's no error message telling you the shade of blue is wrong. You're now making taste calls with no ground truth, and taste calls are infinitely revisable in a way bugs aren't.
The other part is that prompting is cheap and instant, so the cost of "just try one more thing" rounds to zero in the moment, even when it isn't zero in aggregate. A dozen cosmetic passes at a couple minutes each is a real afternoon, but no single prompt in that dozen felt expensive enough to skip.
What the late prompts actually change
| Prompt range | Typical target | Functional diff? |
|---|---|---|
| 1–4 | Core pages, data model, primary flow | Yes — this is where the product gets built |
| 5–7 | Edge cases, error states, missing fields | Usually yes — real gaps found during use |
| 8–15 | Layout, copy, color, spacing, tone | Rarely |
| 16+ | Reverting or re-trying earlier cosmetic choices | Almost never |
That third row is the one worth sitting with. It's not that cosmetic polish is a waste — a build that looks generic will underperform one that doesn't, and the design pass matters. It's that the polish rarely needs eight to fifteen separate prompts to get right, and the reason it takes that many is usually indecision, not iteration. You're not converging on a better answer after prompt eleven; you're oscillating between two answers you already generated by prompt nine.
I watched someone spend forty minutes moving a call-to-action button between three positions on a landing page, decide by prompt fourteen the first position was best, and ask the build agent to put it back. The agent didn't do anything wrong in any of those turns. The button just never needed fourteen opinions.
What the twenty-versus-thirty gap actually tells you
Here's the part that surprised me most: builds that stop around prompt eleven and builds that run past thirty don't come out meaningfully different in quality. I went looking for the payoff — surely more iteration means a more polished product — and mostly didn't find it. What I found instead was that builders who stop earlier tend to have made their taste decisions once, upfront, in the prompt itself ("clean, minimal, single accent color, no stock photography") rather than discovering their taste through twenty rounds of trial and error after the fact.
The builds that ran longest weren't more ambitious. They were the ones where the original prompt left the most undecided — no tone, no reference point, no stated audience — so every gap got filled one small prompt at a time instead of once, in writing, before the first run.
The practical takeaway
If you're four or five prompts in and things run, that's not a checkpoint — that's most of the actual work done. What's left is real but small: check the edge cases nobody thought to describe, sanity-check the copy, and make one deliberate pass on visual tone rather than a dozen exploratory ones. And if you notice yourself on prompt twenty still nudging a border-radius, that's not the build being unfinished. That's usually a sign the earlier prompt should have said what you wanted the first time, and the fix belongs in the next build's opening message, not this one's fortieth.
