AI wrote the first 80% of my feature in 10 minutes.
The code was clean. The logic made sense. The happy path worked on the first try. I ran it, sa...
For further actions, you may consider blocking this person and/or reporting abuse
This matches my experience almost perfectly.
AI is incredibly good at getting you from a blank file to a working prototype. The part that still takes time is everything that happens between "it works on my machine" and "I'm comfortable deploying this to production."
The last 20% is usually where the business rules, edge cases, legacy data, security concerns, and unexpected user behavior start showing up. That's also the part where domain knowledge matters more than coding speed.
I've found that AI makes me faster, but it doesn't remove the need to think. If anything, it shifts more of my time toward reviewing decisions, validating assumptions, and making sure the solution actually fits the real-world problem.
The 80% is impressive. The last 20% is where engineering still happens.
You've summarized it better than I did The last 20% is where engineering still happens. that's the line AI can get you to it works. It can't get you to it's right for your users, your data, your legacy constraints. That part still needs someone who understands the why.
And you're right AI doesn't remove the need to think. It shifts the thinking from how to write it to is this actually the right thing for this context?
Thanks for this perfect summary. 🙌
the first 80% builds false confidence. you ship to staging feeling great, then spend 2 days chasing a race condition the happy path hid. I track this as 'AI debt' now - fast draft, slow integration.
AI debt that's the term I was missing Fast draft, slow integration. The first 80% gives you confidence, the last 20% gives you humility The race condition example is perfect the happy path hid it, the staging environment revealed it, and the 2 days were spent paying for the 10 minutes you saved.
The debt doesn't show up on your velocity graph. But it shows up on your calendar.
I'm using AI debt from now on. Thanks for this. 🙌
yeah AI debt is exactly the frame. borrows fast, compounds silently. and the staging invoice always lands harder than you expect
The 80/20 split names the symptom. The structural cause underneath is that the lineage that wrote the happy path is also the lineage that would have to spot the edge cases. Confident-imagination of edge cases by the writer is a different distribution from the ones that actually appear — business logic the model didn't have, legacy data it never saw, null branches three function calls deep. Asking "what could go wrong?" of the path that produced the optimization returns the most plausible-sounding gaps. Not the real ones.
Failing tests before code is the right primitive, but the variant worth holding onto is the bite-check version: the test has to fail against the pre-change code, not just exist. A test that passes against both states isn't a gate. It's decor with passing CI.
Tracking time-to-ship over generation speed shifts the metric to the right axis. The leverage point underneath is whose attention catches the 20%. If the same person who accepted the 30-second code runs the 3-hour debug, the gap stays. If the gate refuses the merge until the bite-check fires, the gap moves where it can't be skipped.
Mike this is the most technically precise comment in the thread. Thank you Confident imagination of edge cases by the writer is a different distribution from the ones that actually appear That's it. The AI doesn't imagine edge cases it simulates them. And the simulation is based on what it already knows, not what it hasn't seen. The real gaps come from business logic the model never had, legacy data it never saw, null branches it didn't know existed.
Asking 'what could go wrong?' returns the most plausible-sounding gaps. Not the real ones This is the key. The AI will confidently invent gaps that sound plausible but they're the ones it can imagine. The real gaps are the ones it can't A test that passes against both states isn't a gate. It's decor with passing CI Line of the year.
If the same person who accepted the 30-second code runs the 3-hour debug, the gap stays This is the structural problem. The person who says it works and the person who says it's ready need to be different or at least different mindsets.
Thank you for this it's the most important comment in the thread. 🙌
Simulation vs imagination — that's the cut. The simulator is bound to the lineage that trained it; the real edge cases are out-of-distribution by construction, which is why "ask harder" doesn't reach them. The says-it-works/says-it's-ready split is the structural answer at the team layer — same shape as the test that must fail against pre-change code at the gate layer and the operator-is-the-second-view position at the workflow layer. Three places to put the catch, same reason it has to live somewhere the writer can't reach.
Mike this is a framework. Not just a comment. A framework Simulation vs imagination that's the cut. The simulator can only produce what it's seen. The real edge cases are, by definition, out-of-distribution. No amount of ask harder gets you there.
Three places to put the catch
Same shape at every layer the writer can't be the only reviewer This is the structural answer. Not better prompts. Not more careful prompting. A system where the gap has nowhere to hide.
Thank you for this it's the most useful comment I've received on this post. 🙌
Thanks for the read. The framing about layers needing structural independence from each other matters too — gate + team + workflow only do the work if they aren't reading from the same source. Otherwise three layers becomes one in three coats. There's a long-form version of this coming this week — the version one floor up, where the same disease shows up at the multi-path verification layer. I'll point you at it when it lands.
The reframe that does the work here is that AI relocated the effort instead of cutting it. That's the whole trap. The 80% feels finished, so your guard drops right before the part that needs it most. Writing the failing tests first is the move I'd keep, since it hands the model the unhappy path as a target before it writes the happy one, and some edge cases get caught on the way in instead of three days after launch. The 4x budget is smart too, though I'd bet the real multiplier swings a lot with how strange your domain data is.
This is the sharpest reframe in the thread AI relocated the effort instead of cutting it. That's it. The work isn't gone. It just moved from writing to finishing. And finishing is harder because it requires judgment, context, and the ability to recognize what the AI couldn't see.
The 80% feels finished, so your guard drops right before the part that needs it most. This is the psychological trap. The speed of the first 80% convinces you the hard part is over. It's not. It's just been deferred. Failing tests first hands the model the unhappy path as a target before it writes the happy one.
Exactly. The test defines what shouldn't happen before the AI writes what should happen. That flips the whole dynamic The real multiplier swings with how strange your domain data is. Yes the 4x is a baseline. The stranger your data, the higher the multiplier. Legacy systems, weird business logic, inconsistent data formats the AI's blind spots are bigger there.
Thanks for this it's the most precise comment in the thread. 🙌
The honest part here is 'it optimized for the world where everything goes right.' That's the whole failure: the model writes the happy path because the happy path is the well-trodden one in its training, and edge cases are by definition the under-documented territory. The last 20% is slow because it's the part no prompt specified and no example covered. Which means the lever is specifying the failure modes up front, not discovering them on Thursday. The 80% you saved on Tuesday was never the expensive part.
Most precise comment here Model writes happy path because happy path is well-trodden in training that's it. Edge cases are under-documented. AI hasn't seen them The last 20% is slow because no prompt specified and no example covered structural answer.
The lever is specifying failure modes up front, not discovering them on Thursday the line The 80% saved on Tuesday was never the expensive part - exactly.
Best comment here. 💎
The 80/20 framing is exactly right, and the deeper issue is that AI has no concept of "done." A human developer knows when they're done because they understand the domain -- they know what the code is for, who uses it, and what happens when edge cases surface. AI has none of that.
The first 80% is pattern-matching against what "correct" looks like. The last 20% is judgment -- which edge cases matter, which null checks are critical, which error messages users will actually read. That judgment comes from experience with the problem space, not from training data.
One pattern I've found useful: write the error messages first. Before the happy path, write what the code should say when something goes wrong. That forces you to think about the failure modes, and gives the AI something to optimize toward instead of just "it should work."
The deeper issue is that AI has no concept of 'done' that's it. You, the developer, know when it's done because you understand the domain. You know who uses it. You know what happens when something breaks. The AI has none of that. It just keeps generating until you stop it.
The first 80% is pattern-matching. The last 20% is judgment. This is the cleanest way to frame it. Pattern-matching is fast. Judgment is slow because it requires experience, context, and the ability to prioritize which edge cases actually matter.
Write the error messages first. This is brilliant. Before the happy path exists, write what the code should say when it fails. That forces you to name the failure modes before the AI optimizes for success. The AI then has something to optimize toward not just make it work.
Thank you for this the error-messages-first pattern is going into my toolkit. 🙌
The “AI wrote it in 10 minutes, I shipped it in 3 hours” pattern feels very real.
What’s interesting is that the last 20% is usually where product knowledge, business rules, and operational realities show up. AI can generate a solid implementation, but it rarely knows about the legacy edge case, the enterprise customer workflow, or the failure mode that only appears under production load.
One thing we've noticed across AI-assisted development engagements at IT Path Solutions is that teams often overestimate generation speed and underestimate verification time. The bottleneck shifts from writing code to validating assumptions, handling edge cases, and making sure the feature survives real-world usage.
The faster AI gets at the first 80%, the more important that final 20% becomes. That's often where production readiness is decided.
The bottleneck shifts from writing code to validating assumptions that's the new reality Writing is no longer the constraint. Validation is Teams overestimate generation speed, underestimate verification time pattern, not anecdote.
The faster AI gets at 80%, the more important the final 20% becomes exactly. Production readiness is decided there.
Thanks for the real-world data. 🙌
This is so true! I've experienced this firsthand. Getting the initial prototype with AI takes just a few prompts, but then comes the real grind edge cases, error handling, and making it production-ready. The last 20% really tests your actual coding skills. Great article!
Urmila The last 20% really tests your actual coding skills That's the line. 🙏
The AI can handle the familiar. The 20% is where the unfamiliar lives and that's where you actually have to think Edge cases, error handling, production reality those can't be prompted away.
Thanks for reading and for naming the real test. 😊
There are already techniques that can increase the percentage of quality work done by AI from 80% to, say, 90–95%. Spec Driven Development, for example. In that case, using AI turns from plain vibe-coding into high-level engineering, where you and the LLM align on approaches, test cases, and possible states. I personally know of a large, old project with a backend team of more than 20 people alone. They adopted SDD, and development and maintenance became much faster. It also became easier for newcomers to get up to speed. Of course, you still can't do without a human touch, but in my opinion, it's important to know how to use modern tools competently.
This is a great point and honestly, the article should have mentioned SDD Spec Driven Development turns AI from vibe-coding into high-level engineering That's the frame shift. The AI doesn't get smarter. The input gets better more structured, more explicit, more aligned with what the AI actually needs to produce something useful.
The 20% gap isn't fixed. It's a function of how well you set up the problem before the AI writes a single line Large, old project, 20+ backend team SDD made development and maintenance much faster This is the real-world proof. Not a greenfield project. A legacy codebase. The kind where edge cases are hiding everywhere. SDD gave structure to the process and the AI could work within that structure.
I'd add: SDD doesn't eliminate the 20%. It makes the 20% predictable. Instead of discovering edge cases in production, you're listing them in the spec before any code is written.
Thanks for this adding it to my toolkit. 🙌