The gap is dangerous because the demo hides it. A working prototype on day three looks like a feature that is almost done. It is a feature that has not started the hard part.
This piece covers why the last mile did not shrink, what happens when a demo is mistaken for a product, and one page to attach to any demo before a stakeholder sees it.
The 90-90 rule, again
Tom Cargill at Bell Labs put it best, in a line Jon Bentley made famous in 1985:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
It was a joke. It was also accurate. The first half is the happy path: screens, the main flow, the part that demos well. The second half is everything else: error states, permissions, edge cases, audit trails, the migration nobody scoped.
AI compressed the first half. It did much less for the second. Run a simple example.
| One feature | Before AI | After AI |
|---|---|---|
| Happy path | 5 weeks | 3 days |
| Last mile | 5 weeks | 4 weeks |
| Total | 10 weeks | about 5 weeks |
| Demo ready | week 5 | day 3 |
These numbers are illustrative, not data. But look at the shape. Delivery got twice as fast. The demo got more than ten times faster. The distance between "I saw it working" and "it is safe to ship" got longer, not shorter.
That distance is where expectations break.
What the data shows so far
The early evidence says people feel the first half and underestimate the second.
- METR's randomized trial. Sixteen experienced open-source developers worked on 246 real issues in their own mature repositories. With AI tools allowed, they took 19 percent longer. Before starting, they expected a 24 percent speedup. Afterwards, they still believed AI had made them 20 percent faster.
- Stack Overflow's 2025 Developer Survey. The top frustration with AI tools, cited by 66 percent of developers, was "AI solutions that are almost right, but not quite." Second, at 45 percent, was that debugging AI-generated code takes more time. More developers distrusted the accuracy of AI output (46 percent) than trusted it (33 percent).
Read both with care. METR's sample is small, the tools were early-2025, and METR itself now calls the result historical. Stack Overflow is a self-reported survey.
Neither study is about product teams, and neither proves AI slows delivery. What they do show is a perception gap. People judge progress by what they can see, and what they can see is the first half. "Almost right, but not quite" is the last mile, described by the people walking it.
Demo Debt
Demo Debt is the gap between what a stakeholder saw working and what it takes to make it safe to ship. Every demo creates it. Every demo is a promise, whether you meant it as one or not.
Before AI, demo debt stayed small because demos came late. By the time anyone saw something clickable, most of the hard questions had been asked. Now the demo comes first, and the hard questions come after the excitement.
Google's engineers made the same point about machine learning a decade ago. In "Hidden Technical Debt in Machine Learning Systems," Sculley and colleagues showed that the model code is a small box in the middle of a real system. Data collection, configuration, monitoring and serving surround it, and that is where the work sits. Swap "model" for "prototype" and nothing changes.
Three ways a demo goes wrong
Picture the same prototype shown to the same leadership team, three different ways.
- The demo becomes the deadline. Leadership saw it working on Tuesday and asks why it is not live on Friday. The team spends the next month explaining instead of building.
- The prototype becomes the product. Code written to show an idea gets shipped as the idea. Nobody decided that. It just never got thrown away.
- The feedback lands on the wrong thing. Stakeholders react to button colors and copy, because that is what the demo shows. Nobody asks what happens when the payment fails, because the demo never fails.
Same prototype in all three. The only variable is whether anyone showed what was missing.
The third one deserves a second look, because it feels like progress. A room full of happy stakeholders is not validation. It is agreement on the part that was already easy.
Where the last mile actually lives
In a regulated product, the invisible 10 percent is rarely a mystery. It is the same list every time.
- States. Empty, loading, partial, failed, timed out, retried twice.
- Permissions. Who can see it, who can approve it, and who can do it on someone else's behalf.
- Money. Rounding, currency, refunds, and whether the numbers reconcile with finance at month end.
- Audit. What gets logged, for how long, and whether it would satisfy a regulator reading it two years later.
- Operations. What support sees, how you roll back, and who gets paged.
None of these show up in a demo. All of them show up in production.
The Last-Mile Ledger
The Last-Mile Ledger is one page you attach to a demo before anyone outside the team sees it. None of its six fields describe what works. Every one describes what doesn't yet.
Take a feature most payment teams have prototyped in an afternoon: instant refunds to an in-app wallet, instead of back to the card.
- What is real. Which parts run on real services and which are mocked. Example: the refund screen is real, the wallet balance is hardcoded, and the settlement check is skipped.
- Unhappy paths. Every state the demo avoids. A refund on a transaction that has not settled. A double tap. A wallet on a frozen account.
- Who must sign. The people who will judge this later, and by what standard. Finance ops must confirm wallet refunds reconcile against the settlement file. Compliance must confirm the wallet limits still hold.
- Irreversibles. What cannot be undone once it is live. Money moved to a wallet cannot be pulled back without a second transaction and a message to the customer explaining why.
- Honest estimate. The remaining work in weeks, written next to how long the demo took. Demo: one day. Last mile: four to six weeks.
- Throwaway line. Which code gets rewritten before launch, and the name of the person who decided.
Field 1 is where the demo stops being mistaken for a product. Fields 2 and 5 are the hardest to fill honestly, because writing them down means telling an excited room that the fun part is over.
Never show a demo without its ledger. If you cannot fill the six fields, you are not ready to show the demo. You are ready to ask someone a question.
The edge now
AI made the demo free for every team. The edge now belongs to whoever knows what it takes to finish.
Anyone can show it working. The job is knowing what it takes to keep it working.
Sources
- Jon Bentley, "Programming Pearls," Communications of the ACM, September 1985 (quoting Tom Cargill, Bell Labs)
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025
- Stack Overflow, 2025 Developer Survey: AI
- Sculley et al., "Hidden Technical Debt in Machine Learning Systems," NeurIPS 2015
The timeline in "The 90-90 rule, again" is illustrative. Its numbers are assumptions, not findings.