AI made the easy 90% of software instant. The hard 90% is still yours.
You type one sentence into a prompt box. Ninety seconds later, there's a running app.
A form. A database. A chart that updates when you submit it. It looks done.
It isn't.
Open two browser tabs. Log in as the same user in both.
Submit the same form twice, fast — the way a nervous user does when the button doesn't visibly respond.
Leave the thing running for a week instead of a five-minute demo.
Somewhere in there, the wheels come off. A race condition nobody wrote a test for. A query that's instant at 40 rows and takes 40 seconds at 4 million. A webhook handler that isn't idempotent, so a single retried request charges someone twice. A rate limiter that doesn't exist, so one flaky client retrying in a loop quietly takes the whole service down.
Pull up the git history. There's a decent chance an API key is sitting in a commit from three days ago, in plain text, one git push
from being public forever. None of this means the model failed. It built exactly what you asked for: something that runs.
Whether it survives real users, real load, and real time was never the question it was answering.
In 1985, a Bell Labs programmer named Tom Cargill coined a line that Jon Bentley made famous in a Communications of the ACM column.
The first 90 percent of a project's code takes 90 percent of the time. The remaining 10 percent takes the other 90 percent.
Bentley called it, only half-jokingly, the "Rule of Credibility" — a warning to anyone tempted to trust a schedule from someone who'd never shipped anything to production.
Forty years later, the joke lands harder than it used to.
AI collapsed exactly the part of the timeline the rule isn't about. Scaffolding an app — the login form, the CRUD boilerplate — used to eat real days. Now it's minutes.
What Cargill was pointing at was always the second 90 percent: migrations that can't safely run twice, and the edge case where a deleted user's session token quietly keeps working for six more hours because nobody thought to invalidate it.
That part hasn't gotten any faster. It was never a typing problem to begin with.
Ask an engineer with ten years of on-call scars what they think about while reviewing a pull request. It's rarely the syntax.
It's this: What happens under load? What's the blast radius if this throws at 3 a.m. and pages someone? Where does this leak a secret, a connection, or a customer's data?
Those aren't questions you answer by reading more code. They're questions you answer by having watched systems break before, and having built a mental model of why.
A language model doesn't have that model. It has, at enormous scale, a very good sense of what competent code looks like.
That's genuinely useful. It's also not the same thing as knowing what competent code does under pressure.
Ask it for an authentication flow and you'll get something clean, conventional, and quietly wrong — in a way that won't surface until one specific, unlucky sequence of events happens in production.
At which point it's not a code review comment anymore. It's an incident.
It's the opposite, actually. Worth saying plainly, because a lot of people are drawing the wrong conclusion from how good the tools have gotten.
The part AI is genuinely eating is the mechanical translation of a spec into syntax — which was always the least interesting part of the job anyway.
Junior work that amounted to "implement this ticket exactly as written" is getting cheaper by the month. It's not coming back.
But the value of understanding how a database index actually works, or why two requests hitting the same row in the same millisecond corrupt data, hasn't dropped.
If anything, it's gone up. That understanding is now the only thing standing between a working demo and an outage. The engineers pulling ahead right now aren't the ones who avoided AI. They're the ones using it the way you'd use a very fast, very confident junior developer: delegate the boilerplate, then read every line that comes back like it's a pull request from someone you've never worked with before.
What is it assuming about the input? What happens if this function gets called twice at once? Is the error actually handled, or just caught and silently swallowed?
None of that is a new skill. It's the same one code review has always demanded, aimed now at a collaborator that writes fast and never once says "I'm not sure about this part."
The engineers falling behind aren't the ones without AI access — everyone has AI access. It's the ones who ship what it hands them without being able to explain why it works, and who have no idea where to even start once it stops.
That's the actual gap AI hasn't closed. It never set out to.
This piece was sparked by Anuradha Weeraman's essay on the same gap*— worth the five minutes.*
Originally published on ZyVOP
💡 For more articles like this, subscribe to the ZyVOP newsletter!