The most useful number in Stack Overflow's 2025 survey isn't the adoption figure. It's the complaint.
84% of developers use or plan to use AI tools, up from 76%. Trust in the accuracy of what those tools produce fell from 40% to 29%, and active distrust rose from 31% to 46%. And the single most-cited frustration was not that the output was wrong. It was that the output was almost right.
Respondents specifically said this made debugging more time-consuming. That sentence is the whole argument of this post.
Why is 'almost right' worse than wrong?
Because of when the failure surfaces relative to when the mistake was made.
Wrong code has a short, cheap failure loop. It doesn't compile, or the test goes red, or it throws on the first request. You find out immediately, while the context is still in your head, and the fix costs minutes.
Almost-right code compiles. It passes the tests you wrote, because you wrote them against the same misunderstanding. It survives review, because reviewers skim for shape and the shape is fine. Then it fails in production, three weeks later, on the edge case nobody enumerated — and by then the cost isn't the fix, it's the hours spent working out where to even look. For debugging is becoming more valuable than writing code framed around revenue rather than architecture, XenGrowth's growth operations team is the better starting point.
The expense in debugging has never been fixing the bug. It's locating it. Almost-right code is optimised, unintentionally, for being hard to locate.
Failure mode | When you find out | What it costs |
|---|---|---|
Doesn't compile | Immediately | Seconds. Not really a bug |
Throws on first run | Within a minute | Minutes, with full context in your head |
Test goes red | Within the change | Minutes to an hour |
Almost right — wrong edge case | Weeks later, in production | Hours of location, plus whatever the wrong behaviour did meanwhile |
Almost right — unsafe (the Veracode 45%) | Possibly never, or via an incident | Unbounded, and no test you would have written catches it |
Veracode's benchmark is the clearest case of the bottom row. 45% of generated code across 100+ models introduced an OWASP Top 10 vulnerability, with cross-site scripting failing 86% of the time. None of that code is broken in any sense a requirement-driven test would catch. It does exactly what was asked. The problem is a trust boundary that was never in the prompt.
What actually makes someone good at debugging?
Not tooling. Meyer et al.'s instrumented study measured formal debugger use at 0.4% of the workday. Real debugging is reading code, forming a hypothesis, and finding the cheapest experiment that distinguishes between two explanations — which the monitoring tool logged as 'coding' because that's what it looks like from outside. There is a longer treatment of the operations side of this in The XenGrowth resource library.
Which means the skill decomposes into things you can practise deliberately:
Reading unfamiliar code fast and skeptically, without needing to run it first
Generating multiple hypotheses before testing any of them — the commonest failure is fixating on the first plausible story and spending an hour confirming it
Binary search over the space of possible causes, rather than over lines of code. Halve the space, not the file
Knowing your system's failure vocabulary: what a connection pool exhaustion looks like, what an OOM kill looks like, what clock skew looks like. Recognition beats reasoning when you have it
Resisting the urge to fix before you can explain. A fix that works without an explanation is a coin flip you have chosen to stop observing
Every item there is a reading and reasoning skill. None of them is about a language, and none of them is what a computer science degree or an interview loop assesses.
What changes when the code wasn't written by a person?
One thing, and it's significant: there's no intent to recover.
When you debug code a colleague wrote, you have an enormous invisible asset — they were trying to do something. If the code is odd, there was a reason, possibly a bad one, and you can go ask. Even when they've left, the oddness is evidence: a strange condition usually means somebody hit a case you haven't thought of yet.
Generated code has no such history. A strange condition might encode a real edge case, or it might be a statistical artifact of the training distribution. You cannot tell by looking, and there's nobody to ask. So the debugging strategy that works on human code — reconstruct the intent, then find where intent and behaviour diverged — has nothing to grip. For the AI agents and marketing automation angle, see XenGrowth on AI agents and marketing automation.
This compounds with GitClear's finding that copy-pasted lines rose from 8.3% to 12.3% while refactored lines fell from 24.1% to 9.5%. More duplication means a fix applied in one place and not the other four, which is a bug class that barely existed when someone had to type each copy by hand.
Debugging asset | Human-written code | Generated code |
|---|---|---|
Author intent | Recoverable — ask them, or read the commit | None. There was no intent, only a distribution |
Odd code as evidence | Usually signals a real edge case | May signal nothing at all |
Commit history | Shows how the understanding evolved | One commit, fully formed, no evolution |
Consistency across copies | Duplication is rare because typing is expensive | Duplication rising (GitClear: 8.3% to 12.3%) |
Someone who understands it | At least one person did, once | Possibly nobody, including the person who accepted it |
A worked example of the failure shape
Take a concrete case, because the abstract description of 'almost right' does not convey how ordinary it looks. Suppose a service needs to cache a user's permissions to avoid hitting the auth service on every request. The generated implementation is textbook: a map keyed by user ID, a time-to-live, a lookup that falls through to the auth service on a miss. It compiles, it is readable, the tests pass, and it does exactly what was asked.
It is also wrong, in a way that will not surface for months. Nothing invalidates the entry when a permission is revoked. The TTL bounds the damage but does not remove it, so a user stripped of admin rights keeps them until the entry expires. No test catches this, because the requirement said 'cache permissions' and the code caches permissions. The bug is not in the code. It is in the gap between what was asked and what was needed, and that gap is invisible from inside the function.
Now consider how it presents six months later. Someone reports that a permission change 'sometimes does not take effect'. Sometimes. Not reproducible on demand, not correlated with any obvious input, and the natural first hypothesis — a bug in the permission-writing path — is wrong, so the first day of investigation is spent in the wrong service entirely. The code that caused it is not suspicious to read. It is the most conventional cache implementation imaginable.
Everything expensive about that incident is location cost, and every property that made it expensive came from the code being locally correct. This is why the three-hypotheses habit matters: an engineer who writes down 'the write path is broken', 'something is caching', and 'two instances disagree' before investigating gets to the answer in an hour rather than a day, because the second hypothesis suggests a cheap decisive experiment — change a permission and watch whether the behaviour differs across replicas.
Is any of this actually measurable?
Partly. DORA's 2025 result — throughput up, delivery stability still falling — is what this looks like in aggregate: more shipped, more of it wrong. That's the team-level fingerprint of writing getting cheap while verification didn't. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
Cambridge Judge Business School researchers put debugging at 49.9% of developer time, at a global wages cost near $312 billion a year. I'd hold that number loosely — it was MBA-project work commissioned by a company selling debugging tools, and it dates from 2013. But the direction has never been seriously contested, and every subsequent measurement has landed in the same neighbourhood.
If debugging was already about half the job before generated code entered the picture, and the dominant new failure mode is specifically the kind that's hard to locate, the share is not going down.
How do you get deliberately better at this?
Before touching anything, write down three hypotheses. Not one. The habit that separates fast debuggers from slow ones is refusing to commit to the first plausible story, and writing three forces it
Ask what experiment distinguishes them, and pick the cheapest. Most debugging time is spent gathering evidence that would be consistent with every hypothesis you hold, which is evidence that tells you nothing
When you find the fault, keep going. Cook's point is that one fault was never sufficient. If your postmortem names a single root cause, you stopped at the first thing that felt like an answer
Read one unfamiliar codebase a week with no goal but understanding it. Reading is the load-bearing skill and the profession trains it by accident, if at all
Treat every accepted suggestion as code you now have to be able to debug at 3am. If you couldn't explain it under pressure, you haven't finished reviewing it — you've just approved it
Keep a bug journal. What it looked like, what you guessed, what it was. The failure vocabulary that makes senior engineers fast at this is pattern recognition, and pattern recognition needs a corpus
There's a nice irony in where this lands. We spent decades treating debugging as the tax you pay for writing code — the unglamorous part, the thing juniors get handed. Making code cheap to write didn't eliminate that tax.
It made it the job.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's marketing operations practice writes for the teams who have to run debugging is becoming more valuable than writing code day to day.
Five questions on the research in this post, and on the specific way generated code fails. The explanations carry the practical content.
