The 80% Problem: The Last 20% Is Where the Engineer Used to Live | jonathanbeard.io Skip to content AI gets you to a working draft fast (say four-fifths of the way), and the speed is real. The trouble is what the remaining fifth contains, and who used to build the muscle that handles it.
At the end of the last post I admitted there was a related ache I was leaving for its own post: the way the tool gets you to eighty percent in a hurry, and the last twenty was always where the engineer actually lived. This is that post.
Start with the old joke, usually pinned on Tom Cargill at Bell Labs and made famous by Jon Bentley’s Programming Pearls column: the first ninety percent of the code takes the first ninety percent of the time, and the remaining ten percent of the code takes the other ninety percent of the time. It’s funny because the arithmetic is absurd and the experience is exact. The visible part of a system, the part that demos, comes together fast. Then the project meets the part nobody budgeted for: the edge cases, the failure modes, the conditions that only show up under load, the half-page of operational reality that decides whether the thing survives contact with the world.1 That tail isn’t a rounding error in the schedule. It is the schedule.
Generative AI hasn’t repealed this rule. It’s relocated it, and in moving it created a problem worth naming carefully. Ask a coding model to build a feature and it’ll produce the first eighty percent with startling speed and fluency: the happy-path logic, the structure that passes a basic test, the scaffolding that runs in a demo. One caveat: that eighty percent is real only when the model was trained on something like your problem and can generalize to it. Point it somewhere the training data barely touched and the fluency doesn’t go anywhere, but the correctness does, you get the same confident scaffolding, now hallucinated.2 Fluent output and usable work are different things, and the model has gotten good enough to nail the first while missing the second. What it quietly skips, when the eighty percent is the real kind, is the other twenty percent, and the skips aren’t random. They cluster around exactly the parts of engineering that take sustained operational experience, the idempotency key that keeps two racing requests from corrupting state, the backoff and jitter that keep a retry from turning into a stampede, the migration written to dodge a long table lock, the rate limiter, the circuit breaker, the structured log that makes the eventual failure diagnosable at 3am. Every one of those is invisible during development, because the dev environment never exercises the condition that would expose it. The code compiles. The test passes. The demo works. The artifact looks done. Then it meets concurrency, or a traffic spike, or a partial network failure, or any of the ordinary cruelties of production, and it isn’t done at all.
That last twenty percent is where the engineer used to live. It was never the fun part, but it was the formative part, because it was the part that forced contact with the substrate and built the judgment that contact produces. You learned about memory by chasing a segfault you couldn’t explain, the sickening randomness of corruption in a parallel program, the occasional stack smash.3 You learned about concurrency by debugging a race that only showed up on Tuesdays. You learned about data shape by watching a query that flew on a thousand rows fall over on ten million. None of it taught kindly or efficiently, but it taught, because the system simply refused to work until you understood it. The eighty percent the model now generates is, by and large, the part that resisted least. The twenty percent it skips is the part that did the teaching.
There’s a takeaway in that worth saying out loud, and it runs against the anxious version of this story: experience is worth more now, not less. When the typing is partly handled for you, the decisive skill becomes everything around the typing, knowing which algorithm actually fits, seeing where the components meet and how they’ll behave under stress, holding in your head what the system is really supposed to do. That’s the judgment the last twenty percent used to build, and it’s exactly the part the model can’t hand you. (A bias I’ll cop to: I still out-optimize my own LLM more often than not, though it’s entirely possible I’m just pickier than it is.4)
The good plan, violently executed
There’s a corollary here that cuts the other way, and I first learned it in a different uniform. The US Army teaches a planning version of this same ratio, usually wrapped around a line attributed to Patton:
A good plan violently executed now is better than a perfect plan executed at some indefinite time in the future.
Gen. George S. Patton
That isn’t a license to charge in with no plan, or a bad one. It’s a warning against the opposite failure, paralysis by planning. Wait for the perfect plan and you lose...