The pull request looked perfect. Two approvals, every check green, a diff so tidy the reviewer barely paused before merging. An AI assistant had written the whole thing in about ninety seconds that Tuesday afternoon, a small function to apply a customer discount, and it did precisely what the ticket asked for. It shipped. Three weeks later a support escalation landed on a completely unrelated team: a handful of customers had been charged the wrong amount, because the discount was supposed to stack with a regional rebate that the ticket, and therefore the prompt, and therefore the model, never mentioned once. The code was not buggy. It was almost right.
That last sentence is the whole problem, and 49,000 developers just put a number on it. I have shipped software for 25 years, long before an assistant could autocomplete a function, and I have never watched a single failure mode spread this fast. The reflex is to blame the model and wait for a smarter one. I think that reflex aims at the wrong target. And the data, read carefully, is starting to agree.
Why is AI code so often almost right but not quite?
Because almost right is exactly what a faithfully built underspecified requirement looks like. The model did what the prompt said. The prompt was missing the part that lived in someone's head. In its 2025 Developer Survey, Stack Overflow asked roughly 49,000 developers across 177 countries how they actually work now, and the top-line is blunt: 84% use or plan to use AI tools, up from 76% a year earlier. Adoption is settled. What is not settled is the trust, and the single biggest frustration, named by 66% of developers, is AI output that is, in the survey's own words, almost right, but not quite. Read it twice. Not wrong. Almost.
Here is why that exact phrase matters so much. Wrong code fails loud: a stack trace, a red test, a crash you cannot miss and cannot merge. Almost right code passes. It compiles, the happy path runs clean, the demo dazzles, and the one condition nobody specified waits quietly in the gap until production goes looking for it on your behalf. A model does not hallucinate a rebate rule it was never told about. It fills the silence with the most probable thing, ships that guess with total confidence, and moves to the next ticket. The gap was never inside the model's weights. It sat in the ask, in the space between what the ticket said and what the system actually needed to do, which is the same adoption-without-trust hangover we traced in the copilot hangover.
Is this a model problem or a requirements problem?
Mostly a requirements problem. Let me grant the counterargument its one fair sentence: model quality genuinely matters, a stronger model will misread fewer instructions and invent fewer details, and that part of the gap really is shrinking every release. Now the part that does not shrink. The residue that survives every single model upgrade is the piece nobody wrote down, and no amount of parameter count discovers a rule that exists only in the memory of an analyst who retired in 2021. A smarter model reads your prompt better. It cannot read your mind. And it certainly cannot read the mind of the person who left the company before the ticket was ever filed.
When I first watched teams hit this wall, I assumed better prompting would fix it. Cleaner instructions, a few examples, a tighter system prompt. It helped, honestly, a little. Then I noticed what actually sat underneath the failures: the prompts that produced almost right code were not badly written at all. They were faithfully written against an incomplete understanding of what the software was supposed to do. You cannot prompt your way out of a requirement you do not know exists. That is not a language problem to be solved with better wording. It is a discovery problem, and it is old, far older than AI, the exact gap that has quietly sunk software projects since long before a model could type a line.
This is where the current wave of spec-driven tools gets it half right. Writing a spec before you generate code genuinely beats vibe-coding a prompt and hoping for the best. But a spec-driven tool inherits the very gap it was built to close, because it formats the decision, it does not discover it. If the missing rule never made it into the spec, the tool renders your incomplete understanding as clean, structured, confident markdown and feeds it to the model, which then builds the wrong thing with even more conviction than before. We went deep on this in why specs are the problem, and again in why vibe coding with specs is still broken. The short version fits on a sticky note. A spec you can write down is a spec you already knew. The requirement that hurts you is the one you did not.
What does almost right cost once it ships?
More than the bug it hides, and the same survey put a number on the tax. After almost right itself, the second-biggest frustration developers named was that debugging AI-generated code is more time-consuming, cited by 45%. Sit with what that does to the promised time savings. The model writes the function in ninety seconds, then quietly hands the time back to you later, at the worst possible moment, in the least predictable place, wearing the disguise of code that already passed. You did not save an hour. You borrowed one, at interest, payable in production.
And the cost is not always a rounding error on an invoice. Sometimes it is a legal precedent. The most instructive almost right failure of the last two years did not happen in a code review at all. It happened in a courtroom, because an AI system did precisely what it was built to do while missing the one rule that lived somewhere else entirely.
In November 2022, Jake Moffatt visited Air Canada's website hours after a family death, looking for a bereavement fare. He asked the airline's support chatbot. The bot answered fluently, confidently, and helpfully: yes, book now, then apply for the reduced bereavement rate retroactively within 90 days. Reasonable. Well phrased. Almost right. The one problem was that Air Canada's actual bereavement policy, sitting on a page the bot even linked to, said the opposite: the discount could not be claimed after travel. The bot had faithfully generated a plausible answer to fill a gap in what it knew. Nobody had encoded the real constraint into what it could say.
Moffatt booked, relied on the answer, and was refused the refund. He took it to the British Columbia Civil Resolution Tribunal. In February 2024, in Moffatt v. Air Canada, the tribunal rejected the airline's argument that the chatbot was somehow a separate entity responsible for its own words, found negligent misrepresentation, and ordered Air Canada to pay damages. A small sum, 650.88 dollars. A very large point. The output was not a bug in the model. It was a requirement nobody wrote into it, and the failure was invisible right up until it wasn't. The lesson generalizes cleanly to code: an almost right answer, shipped with confidence, carries a real bill that arrives later and addressed to someone else.
What actually closes the gap?
Not a smarter model. A better question, asked earlier. If almost right is the shadow of a missing requirement, then the fix is not more generation, it is more discovery, done before the model ever runs. Surface the assumptions, the edge cases, the regional rule, the two teams that each think the other owns the rebate logic. Get them onto the page while it still costs a conversation. Then generate against a complete ask, and watch how much of almost right simply stops happening, because the silence the model used to fill with a guess now has an actual answer in it.
That practice has a name, and it is not gap analysis or better prompting. Running the searches for what a requirement left out, before the build, with a machine doing the scale and a human confirming the intent, is the working shape of requirements intelligence: treating the intent behind a system as something to actively recover and make testable, not a lucky byproduct of a well-worded prompt. Do it and the economics flip. The requirement you surface in a Tuesday conversation costs a Tuesday conversation. The same requirement, discovered as an almost right bug in month five, costs a production incident, a debugging marathon, and sometimes a tribunal. Same rule. Wildly different invoice. The model was never going to send you the cheap one.
Almost right is a requirements signal, not a model verdict.
84% of developers now use AI, and 66% name almost right, but not quite as their top frustration. That is not a bug report on the model. It is a status report on the ask. Almost right code is a complete, confident build of an incomplete requirement: it passes every check the wrong way and surfaces only in production, where 45% of developers say the debugging eats the time the generation was supposed to save.
A smarter model shrinks the capability half of the gap and cannot touch the other half, the rule that was never written down. Spec-driven tools format the decision without discovering it. What actually moves the number is discovery before generation: surface the silent assumptions and edge cases while they still cost a conversation, then let the model faithfully build a requirement that is finally whole.
What are the most common questions about AI code quality?
