Summary
The most repeated observation about AI coding is the 70% problem: vibe coding sprints you to a working-ish prototype and then stalls, and the final 30% turns brutal. The usual diagnosis is that the last 30% requires deep engineering knowledge the beginner lacks. I think that diagnosis is wrong, or at least imprecise. The last 30% is hard because you do not understand the code you are now responsible for, and no amount of engineering seniority saves you if you skipped comprehension on the way up. The cliff is made of comprehension debt, and comprehension debt is refinanceable.
The Standard Story, And Where It Breaks
Addy Osmani frames it cleanly: AI gets you 70% of the way fast, then “fixing one bug introduces others,” returns diminish, and you need expertise to ship. The implied fix is to be a better engineer. Learn more, and the 30% shrinks.
That advice is true and useless. It is true that a senior engineer clears the last 30% faster. It is useless because it mislocates the cause. The senior engineer is not winning on knowledge, they are winning on a habit: they never let code they do not understand accumulate in the first place. They read the diff. They keep a model of the system in their head. When the bug arrives, they are debugging a system they comprehend, not archaeology on a codebase they have never actually read.
The beginner who vibe-coded to 70% is in a different situation entirely. They have a working prototype and zero mental model of it. The 30% is not hard because it is intrinsically advanced. It is hard because every fix is a blind edit to a black box, and blind edits to black boxes is exactly the two-steps-back pattern. Fixing one thing breaks another because you cannot see the coupling.
Comprehension Is The Thing You Skipped
Vibe coding, in its strict sense, means not reading the AI’s code before running it. That is a legitimate mode for a prototype you intend to throw away. The failure is carrying that mode across the line into something you now have to maintain. You did not save the comprehension work, you deferred it, at interest.
This reframes the whole problem. The 30% cliff is the moment the bill for deferred comprehension comes due, all at once, at the worst time, under a bug. And that is good news, because comprehension debt behaves like financial debt: you can refinance it on a calm day instead of paying the penalty rate during an incident.
How You Actually Cross The Cliff
You do not cross it by becoming senior overnight. You cross it by installing the thing the senior engineer has that the beginner does not: a system that keeps understanding and correctness from decoupling from the code.
- Pay comprehension down deliberately. Before you are stuck, get the agent to explain the system back to you, trace the data flow, and mark the parts you could not defend in review. That is refinancing the debt while rates are low. See comprehension debt is refinanceable.
- Move up the verification ladder. The reason the last 30% feels like whack-a-mole is that you have no way to know a fix did not break something else, other than clicking around. Types, tests, and invariants convert “I hope this still works” into “the machine says it still works.” That is what actually kills the two-steps-back pattern, not seniority.
- Match scrutiny to blast radius. Not all of the 30% deserves the same care. The parts that touch money, auth, or data need real review; the cosmetic parts do not. Beginners spread panic evenly and burn out. The skill is spending your comprehension budget where being wrong is expensive.
- Constrain, do not just correct. When you find a class of bug, encode it as a lint rule, a type, or a test so the agent cannot reintroduce it. The senior engineer’s real advantage is a lifetime of these constraints internalised. You can externalise them into the repo far faster than you can internalise them, which is the whole point of learning loops.
Why This Matters
The knowledge framing is quietly discouraging: it tells the beginner the wall is their inexperience, which they cannot fix on the timescale of the project in front of them. The comprehension framing is empowering and, I think, more accurate. The wall is not what you do not know, it is what you chose not to read, and reading is a decision you can make differently starting now.
The models will keep getting better at generating the 70%. That does not shrink the cliff, it moves more code behind it, faster. The durable skill is not out-coding the AI on the last 30%. It is refusing to let comprehension and correctness fall behind the code in the first place, and building the verification scaffolding that makes the last 30% a checklist instead of a cliff.
Related
- Comprehension Debt Is Refinanceable – the debt this note is about
- The Verification Ladder – the machinery that makes the last mile tractable
- AI Code Review – where to spend your scrutiny
- Code Stewardship Over Authorship – owning code you did not type
- Learning Loops – turning each bug into a constraint
Part of the field guide
This is one of my field notes in AI Native Software Engineering, a plain-English guide to building software with AI agents. The terms behind it are defined in the AI Coding Dictionary.
