AI covers the easy 70% of a project at great speed, but the final 30% — edge cases, error handling, architecture, robustness — still demands human judgment and decides whether the software survives in production. The lesson: AI collapses the cost of starting, not the cost of finishing.
There's a magical and treacherous moment in every project built with AI: it's eleven at night, you asked it for an app, and twenty minutes later you have something that works, looks good, and even seems finished. You feel like you won. The next day you try to make it handle a user who does something weird, a payment that fails halfway through, an empty field, two people hitting the same button — and the magic turns into a swamp. Welcome to the 70% problem: the best-documented — and least confessed — phenomenon of the AI-assisted coding era. AI hands you 70% of the way there at a speed that feels like sorcery, and then lets go of your hand right at the 30% that decides whether your software is a toy or a product.
Who named it and why the number matters
The name isn't ours. Addy Osmani, an engineer at Google, dubbed it "the 70% problem" after watching pattern after pattern in people building with AI. His thesis is uncomfortably precise: AI easily covers the patterned, predictable part of a project — the scaffolding, the CRUD, the pretty screen, the stuff it has seen a million times in its training — but the remaining 30% still demands senior-engineer judgment. That 30% isn't more code: it's a different kind of work. It's the edge cases nobody asked for, the error handling that only matters when something breaks, the architectural decisions you can't see but that hold everything up, the robustness that separates the demo from the deployment. And Osmani's sharpest observation is about who survives there: seniors shape and constrain the AI's output the way you'd prune a tree; beginners get trapped in an infinite debugging loop, asking the machine to fix a bug they don't understand and generating three new bugs for every one they patch over.
The fish and the fishing rod: why the 30% is made of different stuff
The best way to understand it is an old image flipped on its head. AI doesn't teach you to fish; it hands you the fish already cooked, plated, with the table set. It's an instant feast. The problem is that production isn't a dinner: it's a storm on the open sea. And when the net rips, when the engine fails, when water pours in from a side nobody foresaw, you don't need more fish — you need to know how to fish. That knowing is the 30%. It isn't generated, it's exercised. That's why the senior and the beginner live the same moment in opposite ways: for the senior, the AI's 70% is a fast first draft to apply judgment to; for the beginner, that same 70% is a black box that almost works, and "almost works" is the most dangerous place in the world in software, because it looks finished and isn't.
Why the demo shines and production stumbles
This connects to something we've been saying for a while. Vibe coding — building on pure conversational instinct with the AI — is spectacular in the demo precisely because the demo lives in the 70%: the happy path, the user who does exactly what you expected, the clean data. Production is the opposite: it's the 30% multiplied by thousands of real users doing things you never imagined. We'd already put numbers on the gap between the demo and reality in our essay on the math of 27% — how much performance collapses between the lab and the world — and the 70% problem is the other side of that same coin, seen from the building side instead of the performance side. One measures how far AI drops when it leaves the lab; the other explains exactly which part of the work it drops in. Both point at the same abyss: the distance between "it works on my screen" and "it holds up in the world."
What Osmani actually proposes (and what he doesn't)
It's worth being honest about the source, because on the internet people attribute cures to Osmani that he never prescribed. His answer to the 70% problem isn't a rigid methodology of specs up front; it's a handful of habits for living alongside AI. The first: treat the AI's output as a "first draft," never as the final version. The second: the "constant conversation" — iterate in dialogue, correct course turn by turn instead of accepting the first output. And the third, the one that sums it all up: "trust but verify." Trust the speed of the 70%, but verify every inch of the 30%, because that's where AI is at once most convincing and most wrong. If you're after a more formal discipline of specifying before generating, it exists — Spec Kit and spec-driven development go that way — but that's another conversation, not Osmani's. His lesson is simpler and more portable: the AI's speed doesn't exempt you from verification; it makes it more urgent.
The lesson you can take with you and share
Hold on to this mental frame, because it doesn't expire even as the models change: AI collapses the cost of starting and doesn't touch the cost of finishing. Starting was never software's hard problem; finishing is. The 70% AI does for free was always the cheap part — the part a good developer also did fast. The 30% it leaves you alone with was always the expensive part, the one that cost time and judgment, and it still does. So the right question to ask of any tool that promises to build apps for you isn't "how fast does it get to 70%?" — they all get there fast, that race is won and it's boring. The question is "what does it do with the 30%?" Anyone selling you the automatic 100% is selling you the demo and hiding the storm.
How we see it
At NeuralOS we don't pretend the 30% doesn't exist; we build around it. That's why the platform doesn't end where generation ends: the Automations engine is resumable, with durable waits and checkpoints, precisely because real processes fall over halfway through and have to be picked back up without corrupting anything — that's 30% territory. That's why integrations store their credentials in a per-tenant encrypted vault instead of leaving them loose, and why we work with verification discipline and smoke tests on the paths that handle money: not because it's glamorous, but because it's exactly the 30% where software lives or dies. Our bet is the opposite of the hype's: AI flies you to the prototype, and we take seriously the boring, decisive stretch that comes after. Trust the speed. But judgment — setting limits, verifying, making it hold up in production — that isn't delegated. It's systematized. And that's the whole difference between a demo your circle applauds and a product that survives your users.