The 9.5 code-health gate is a retrofit tax

The estimate lands on your desk and it’s ugly. Before AI coding agents can work safely in your codebase, you first have to raise its health score from where it sits today up to near-perfect. For a typical enterprise codebase that means a refactoring program measured in years, at a cost nobody can pin down. The logic feels airtight. Fix the foundation, then build on it. So the cleanup goes on the roadmap, and the agent rollout waits behind it.

Here is where that estimate comes from. CodeScene, a company that sells code-analysis tooling, ran a benchmark across 25,000 files and reported a sharp result: below a code health score of 9.5 out of 10, AI-assisted development produces 41% more defects, with no gain in speed. Above the line, defect risk drops and the model burns fewer tokens. The industry average health score is 5.15, more than four points under the bar. Read together, those numbers say most codebases sit in a zone where turning agents loose makes the work worse. One caveat matters and I’ll keep it in view: this is CodeScene’s own benchmark, internally consistent but not yet replicated by an independent team.

That reading treats 9.5 as a fact about agents. Agents need code this clean to behave, the way an engine needs a certain grade of fuel to run. If that’s what the number is, everyone pays it. Built-from-scratch or decades-old, every codebase has to clear the same bar before an agent can be trusted inside it.

A separate line of research says the number was never measuring that.

The 9.5 threshold isn’t a fact about what agents need. It measures how far your existing code sits from guarantees a system built for agents gets for free. It’s a retrofit tax, and a codebase designed AI-native from day one never owes it.

Follow the mechanism, because that’s where the reframe earns itself. Microsoft’s 2026 red-team analysis, a study where security researchers deliberately try to break a system, found that roughly 31% of production agent failures come from tool misuse: the agent calling a function with the wrong arguments. A system designed for agents from the start checks each action against its rules before running it, not after. That single pre-flight check erases the whole tool-misuse failure class. Systems that organize their knowledge as a graph upfront, so a model can reason across many files at once, score 42% higher on cross-document reasoning than the same thing bolted on later. Both results are verified.

Now put that next to the health score. A codebase built for agents catches, by construction, the exact failures the score was standing in for. So a greenfield system at a health score of 7.0, well below the sacred line, might show zero defect inflation, because its validators intercept the misuse the score was only ever a proxy for. The score, it turns out, was reading distance: how far your code sits from a guarantee a purpose-built system starts with. Build for agents and that distance goes to zero, while the score itself never moves. I want to flag the seam here plainly: that last step is an inference, not a measured result. Hold it loosely for a moment. I’ll come back to how you’d test it.

First, why the number looked like a law of nature. Sampling. Every codebase in that 25,000-file benchmark is a retrofit, because in 2026 nearly every codebase is. The cell of the experiment holding greenfield AI-native systems is close to empty, not because the guarantee fails there, but because almost nobody has built there yet. A universal claim drawn from a sample with a whole cell missing just reflects the data you happened to have. Call it a law and you’ve mistaken your sample for the world. And 5.15 describes the installed base of legacy code, artifacts written long before anyone designed them for the workload they now carry. Read as a natural baseline for human code, it’s the wrong number entirely.

Which opens the door the benchmark couldn’t draw. It framed the choice as two options: remediate the whole 5.15 codebase up to 9.5, or accept 41% defect inflation. Whole-codebase remediation is the multi-year program with the unknown price tag, and the researchers list its cost as an open question precisely because it’s daunting. There’s a third option. Don’t remediate everything, and don’t swallow the inflation. Carve out the surface agents actually touch and build that part new, with the guarantees baked in, while you wrap the legacy core and leave it running. That’s the strangler-fig pattern, where you grow a new system around an old one and replace it piece by piece. It turns an all-or-nothing cleanup into a bounded new build, almost certainly the cheaper of the three. The two-door framing wasn’t just incomplete. It was steering enterprises toward the priciest of three options because it had no way to show the third.

Here’s the honest counterargument, and it’s a real one. Maybe greenfield systems have to hit 9.5 too. Nobody has actually measured it. Everything I just walked through rests on a single inference: that architectural guarantees dissolve the failure the health score proxies for. The verified pieces are narrow. Pre-flight validation kills the tool-misuse class. Upfront graph reasoning beats the retrofit version. But no study has run CodeScene’s defect-inflation metric on a greenfield AI-native codebase, so “greenfield never owes the tax” is plausible and one step from the evidence, not proven. And notice the trap. The original number traveled from one vendor’s benchmark to a treated-as-universal law inside a day. Flipping that into “greenfield dissolves it” on a single inference is the same mistake with the sign reversed. A number this consequential deserves better than either rush.

The good news is that the test is buildable, and it’s the same instrument pointed at the empty cell. Run the defect-inflation benchmark on greenfield AI-native codebases, and record their health scores. Two outcomes split it cleanly. If a 7.0-health greenfield codebase shows no inflation while a 7.0 retrofit does, the score was proxying for architecture all along, the tax is real, and so is the third door. If greenfield systems also have to reach 9.5 to stay clean, then the threshold is a genuine property of agents working on code, and the cleanup everyone recommends really is unavoidable. The measurement that decides it isn’t whether greenfield is better. Of course it’s better. What matters is defect inflation with the health score held fixed, varying only by when the code was built. Until someone runs that, treat the multi-year cleanup as one option of three, and price the third before you fund the first.