Nobody measured the code in the stalled-rollout data

Your AI pilots went in, and the profit didn’t follow. Go looking for the reason and the field hands you a clean one: your organization isn’t ready. The models are capable enough. What’s missing is governance, the settled rules for who’s allowed to do what and who owns the risk when an agent gets something wrong. Sort that out, the advice goes, and the returns arrive.

A real number sits under that advice. When McKinsey surveyed more than 10,000 executives for its State of Organizations 2026, 88% had put AI into production in at least one function, and only 39% could trace real profit to it. That leaves a 49-point gap between deploying and earning. Deloitte, surveying 3,235 technology leaders across 24 countries the same spring, found only about one in five organizations had mature oversight for AI agents while three in four planned to deploy them by 2027. Put the two together and the story writes itself: companies are rich in pilots and poor in transformation, and the missing ingredient is the governance to coordinate hundreds of teams at once.

A benchmark published this year turns up something that story has no slot for. CodeScene, a company that scores how maintainable code is, tested agentic AI, the kind that edits a codebase on its own rather than the autocomplete that finishes your line. It measured the health of the code before turning the agent loose, on a one-to-ten scale, and found a line at 9.5. Below it, the same agents produced about 41% more defects with no gain in speed, and no review process laid on top changed that. The median enterprise codebase scores 5.15, more than four points under the line. Treat those figures with care: they come from a single vendor that sells code-health tooling and co-authors the research, and no one has independently replicated them. Still, follow the mechanism.

A company with flawless governance and an average codebase ends up in exactly the same place as a company with broken governance: agents deployed, nothing to show for it. The 49-point gap can’t tell those two apart, because nobody measured the code.

Walk it through with the governance the consensus wants. Take one of Deloitte’s top fifth, with senior leadership engaged and agent oversight mature, the coordination problem genuinely solved. Point its agents at a 5.15 codebase and you get 41% more defects and no throughput, a deployment that earns nothing. In the McKinsey aggregate, that company is a dot in the 61% that deployed and didn’t convert, sitting right next to the companies whose governance actually failed. It did everything the advice asked. The number files it under organizational failure anyway, because the number never looked at the code.

This is where the framing breaks. The phrase doing the work across all this advice is “organizational, not technical,” and it sorts every obstacle into two bins: governance and incentives on one side, model quality and tooling and data on the other. Code health belongs to neither. It’s the state of the artifact you already own, and the only thing that moves it is labor on that artifact. You can’t buy your way to 9.5 and you can’t govern your way there. Notice the phrase “regardless of review process.” A review process is governance applied to the code, and the finding says the code’s starting state defeats it before the review begins. So this failure sits outside governance entirely, and the number was never built to see it.

The sharper version reaches the consensus’s favorite fix. Ask its proponents what really separates the companies that scale from the ones that stall and they point to feedback loops: close the gap between what an agent produces and what a human corrects, and the org iterates fast; skip it and you deploy once and freeze. Microsoft’s enterprise-agent framework names it as the operative lever. But a feedback loop needs something to feed it. An opaque, low-health codebase doesn’t expose the signals an agent needs to correct itself, which is why CodeScene found that tooling surfacing code-health signals during generation fixed several times more issues than an agent working blind. Governance can mandate the loop. It can’t make bad code legible enough for the loop to close. The organizational lever everyone leans on has a technical floor under it, and the average codebase sits below that floor.

None of this makes the organizational case wrong. Coordination failure across hundreds of teams is real, and the Deloitte readiness gap is real too; governance almost certainly explains a large share of that 49-point chasm. The problem is narrower than that, and it’s the load-bearing part: the gap was offered as proof that the constraint is organizational and not technical, and a gap that folds both failures into the same dot can’t prove it’s only one of them. Some unknown slice of those 49 points is a code problem that reads, in the survey, as a governance problem, and the case banked the whole number without measuring the alternative. The honest limit cuts both ways. I can’t tell you how big that slice is, and no one can yet, because the measurement that would separate the two hasn’t been taken.

You don’t have to wait for it. The aggregate can’t tell which failure is yours, but you can. Before you greenlight the reorg that’s meant to unstick your rollout, pull your own code-health score, which is already sitting in your repositories, and see which side of 9.5 you land on. If you’re near the median, the governance program you’re about to fund may be a careful fix for a problem you don’t have yet, while the real one keeps generating defects underneath it. Check the code first. The number everyone quotes can’t do it for you, and the rollout on the line is yours.