The AI-Readiness Gap Nobody Is Measuring
Why enterprise AI tools underdeliver — and the codebase dimension no readiness framework has ever measured
AI coding tools are now standard equipment in software teams. GitHub Copilot, Cursor, Claude, Codex — adoption is widespread, budgets have been committed, and developers are actively using these tools every day.
Yet enterprise-level results remain disappointing. McKinsey reports that only 39% of organizations attribute any measurable EBIT impact to their AI investments. Deloitte finds that despite a 50% increase in AI tool access, only 20% of organizations say their talent is highly prepared to use them effectively. Nearly three in four companies plan to deploy agentic AI within two years, yet only one in five has mature governance in place.
These figures do not prove that codebase quality is causing the gap. What they establish is a consistent pattern of underdelivery that the conventional explanations — strategy, culture, talent, infrastructure — have not resolved. There is a structural factor that none of those explanations examine. And it is the most direct determinant of whether AI tools produce value or compound risk.
The conventional explanations focus on strategy, culture, talent, and infrastructure. These are real factors. But they share a common blind spot.
None of them look at the codebase.
Every major AI readiness framework — McKinsey, Gartner, Deloitte, Microsoft — evaluates organizations across five familiar dimensions: strategy and leadership, data, people and culture, process and operations, and infrastructure.
These frameworks are useful. But for software-driven organizations — which is most organizations — they systematically ignore the one thing that most directly determines whether AI tools produce value or simply produce more code.
The codebase is the missing pillar.
A compelling AI strategy, clean data, talented developers, and modern infrastructure cannot overcome a codebase that is architecturally incompatible with AI-assisted development. And yet no established framework measures this. No standard exists. No instrument has been built to assess it — until now.
This is also where AI Readiness assessment diverges fundamentally from technical debt measurement. Technical debt asks a backward-looking question: how much would it cost to fix what is broken? AI Readiness asks a different question entirely: is this codebase structurally capable of supporting AI-assisted development safely? A codebase can carry low technical debt and still be AI-unready. Conversely, some forms of debt have no bearing on AI tool effectiveness at all. The two measurements are related — but they are not the same thing, and conflating them produces the wrong diagnosis.
We scanned 20 open source repositories across eight measurable dimensions directly relevant to AI-assisted development: blocker code complexity, outdated dependencies, commit velocity, active contributor coverage, security exposure, code duplication, long method density, and fix instability — derived from commit history analysis (bugspot), capturing the behavioural signal that static scans cannot: which parts of the codebase keep breaking, and whether that instability is worsening.
The repositories were selected to represent two structural conditions — architecturally sound codebases and legacy or degraded ones — in order to demonstrate the full range of what the instrument measures. This is a controlled demonstration of range, not a statistically representative sample of enterprise codebases. We cannot yet claim, from this benchmark alone, that codebase scores causally determine AI tool outcomes. What we can show is that the structural conditions the scores measure are strongly correlated with the failure patterns that McKinsey and Deloitte consistently document — and that no existing framework has looked at them. The longitudinal outcome data that would establish causation is what comes next.
The pattern that emerged was not subtle!!!!!
On complexity — the dimension that most directly determines whether an AI coding tool can reason about and safely modify a codebase — the well-architected group showed near-zero blocker code smells across most repositories. In contrast, the legacy group averaged four times higher. More telling than averages are the structural extremes: Android AOSP contained 1,730 long methods; Hadoop contained 1,054. In a codebase with that density of complex, entangled logic, AI-generated code has nowhere safe to land. It cannot be inserted modularly, it cannot be validated reliably, and it accelerates the accumulation of the very complexity it was supposed to help resolve.
On security exposure, the divergence was even more pronounced. Jenkins recorded 31.9 hotspots per 10,000 lines of code against Kubernetes’s 0.0 — a 319× gap. These are not marginal differences in code hygiene — they represent a structural divide between codebases that AI tools can safely operate within and codebases where AI acceleration compounds existing risk rather than reducing it.
On development velocity and ownership — the signals that indicate whether a codebase is actively governed enough to absorb AI-generated changes safely — the contrast was equally sharp. The well-architected group logged a median of 1,727 commits in the past year. The legacy group logged 421. Grunt registered 6 commits across the entire year. Catalyst registered zero active developers. These are codebases where AI-generated changes would have no meaningful human oversight, no active review process, and no maintainer capable of validating what the model produced.
On fix instability, the most revealing signal was not the fix ratio itself but its trend. Repositories where the proportion of fix commits is rising year on year — WordPress, Hadoop, Grunt — are codebases where existing instability is accelerating. Introducing AI-generated code into an already deteriorating system does not stabilise it. It compounds the rate of churn.
On dependency exposure, Moodle carried 102 outdated packages; Hadoop 98. Outdated dependencies do not merely represent security risk in isolation — they represent compounding risk when AI coding tools accelerate the rate at which new code is written on top of a fragile foundation.
The table below ranks all 20 repositories across eight measurable AI readiness dimensions. Each dimension is scored 1 to 5, where 5 represents the strongest structural condition for AI-assisted development, and 1 represents a critical blocker. Dimensions are weighted to reflect their relative impact on AI tool effectiveness, with security exposure carrying the highest weight at 20%. These eight dimensions are not the only factors that bear on AI readiness — they are the ones currently objectively measurable at scale. Measurability is the primary criterion; relevance to AI-assisted development is the filter applied within it.
Only one repository in this benchmark achieves a grade of A. Kubernetes scores 92 — the result of near-zero security exposure, high commit velocity, and fully active ownership. The absence of a perfect score across any real-world codebase is itself a finding: AI readiness is not a binary condition, and the gap between the top and the bottom of this ranking — 92 versus 46 for Android AOSP — is wide enough to represent entirely different categories of risk.
One result warrants specific attention. Catalyst — an effectively abandoned project with zero commits and zero active developers in the measurement period — scores relatively well on static dimensions precisely because nothing is being done to it. This is not a sign of health. It is the most dangerous condition of all: a codebase where AI-generated changes would land in a vacuum, with no governance, no review, and no one to catch what goes wrong. The score does not measure intent or effort. It measures structural condition.
AI coding tools do not operate in isolation. They operate on existing code. And the quality of that existing code determines almost everything about whether AI assistance produces value or risk.
Consider what happens when an AI coding tool encounters a poorly structured codebase: it generates changes that break untested, tightly coupled systems. It produces plausible-looking code that misinterprets undocumented architecture. It accelerates the accumulation of debt that already exists. Nobody can safely validate what it produces because ownership is fragmented and nobody fully understands the system.
The result is not AI-assisted productivity. It is AI-accelerated entropy.
Conversely, in a well-architected codebase — modular, well-tested, clearly documented, with distributed ownership and manageable dependencies — AI tools do exactly what they promise. They accelerate genuine delivery without compounding risk.
The tool is the same. The codebase determines the outcome.
The eight dimensions in this benchmark were selected because they are objectively measurable at scale across any codebase, in any language, without requiring access to proprietary systems or internal documentation. Each maps to a specific structural condition that determines whether AI-assisted development can proceed safely.
Blocker code smells measure the density of complexity that most directly prevents AI tools from reasoning about and safely modifying code. In the benchmark, the median blocker smell density in the legacy group was four times that of the well-architected group.
Outdated dependencies measure the degree to which AI-accelerated delivery is building on a fragile foundation. When AI tools increase the rate of code production, they simultaneously increase the rate at which vulnerabilities in outdated packages become exploitable entry points.
Commit velocity is a proxy for active human oversight. A codebase receiving 6 commits per year — as Grunt did — is one where AI-generated changes will be reviewed by nobody. High velocity alone does not guarantee quality; but near-zero velocity guarantees the absence of governance.
Active contributor coverage measures ownership concentration — whether the people who understand the codebase are still present to validate what AI tools produce. A codebase where 0% of the original top ten developers are still active is one where AI output cannot be safely assessed.
Security hotspots carry the highest weight in this framework because AI acceleration makes existing security exposure worse, not better. A codebase with 31.9 critical hotspots per 10,000 lines — as Jenkins carries — becomes more dangerous under AI-assisted development, not less. The benchmark range on this dimension alone spans from 0.0 to 31.9 per 10,000 lines.
Code duplication measures the structural barrier to modular AI insertion. When the same logic exists in multiple locations, AI-generated changes must be replicated consistently across all of them — a requirement that increases the probability of silent divergence and regression.
Long method density is a significant structural contributor to AI reasoning failure in complex codebases. Android AOSP contains 1,730 long methods; Hadoop 1,054. These are not just maintenance problems — they are the specific structural conditions under which AI tools generate plausible-looking code that breaks things.
Fix instability — derived from commit history analysis — is the only behavioural dimension in this framework. It captures what static analysis cannot: which parts of the codebase keep breaking, and whether that instability is worsening year on year. A rising fix ratio is not evidence of a healthy team catching bugs. It is evidence of a codebase under compounding stress.
These eight dimensions are not a complete theory of codebase health. They are the measurable foundation of one. Additional dimensions — test coverage density, API surface stability, documentation completeness, inter-service coupling — are candidates for future iterations as measurement methodology matures. The framework will expand. What matters now is that an objective, measurable baseline exists where none did before.
Organizations are currently investing heavily in AI strategy, data infrastructure, talent acquisition, and tooling — while leaving codebase readiness completely unassessed.
The result is predictable. AI initiatives stall not because of lack of ambition or budget, but because the software foundation cannot support them. Developers use AI tools and generate more code — but in a structurally unprepared codebase, more code means more debt, more fragility, and more risk, not more value.
This creates a specific and solvable problem in enterprise budget conversations. When a CTO argues for investment in codebase remediation before AI deployment, and a CEO wants AI now, and a product team wants new features — nobody in that room has evidence. The conversation is political rather than economic. What changes that conversation is an independent, objective measure of structural AI readiness: not an opinion about the codebase, but a score.
A codebase with a D-grade AI readiness score is not ready for the AI investment being planned around it. A codebase with a B-grade score has specific, identified blockers that remediation can address. That is information a board can act on. It transforms a political discussion into a capital allocation decision.
This is where the enterprise AI adoption gap lives. Not in strategy. Not in talent. In the codebase nobody looked at.
What This Means Practically
Before committing further investment to AI tooling, organizations should answer a more fundamental question: is the codebase those tools will operate on structurally capable of supporting them safely?
That question now has a measurable answer.
C2M produces an independent AI Readiness assessment across all eight dimensions — scanning codebases of any size, in 35 modern languages, without requiring access to production systems. The output is not a technical report for engineering teams. It is a scored, graded assessment that translates structural codebase condition into the language of business risk: which modules block AI deployment, what remediation would unlock, and where investment in codebase quality produces the highest return on AI initiative value.
For organizations mid-way through an AI transformation that is underdelivering, it provides a structural explanation. For boards evaluating AI investment proposals, it provides an independent technical baseline. For investors conducting technical due diligence on software assets, it adds a dimension that no existing instrument has measured.
The enterprise AI adoption gap is real. The explanation is measurable.
The instrument exists.
Benchmark methodology and full repository results available on request.
Further reading — C2M research Further reading — C2M research
Is your AI technology stack becoming riskier over time without you noticing? This article presents a year-over-year analysis of 25 leading open-source AI frameworks, revealing that while most continue to innovate rapidly, many are also accumulating structural complexity and technical debt. It introduces the concept of "Debt Drift" and explains why monitoring the trajectory of code quality—not just point-in-time metrics—is essential for managing enterprise AI risk and building resilient AI platforms.
AI accelerates software development—but it doesn't eliminate the need for software governance. This article explains why enterprise AI adoption requires independent visibility into code quality, technical debt, ownership, and systemic risk. Drawing on real-world evidence, including C2M's analysis of Anthropic's open-source ecosystem, it demonstrates why governance becomes more—not less—critical as AI increases development velocity and code volume.
This article explores why many AI software initiatives fail to deliver expected returns—not because of the AI tools themselves, but because the underlying codebases are not structurally prepared. Drawing on a benchmark of 350 repositories assessed by four leading LLMs and CodeWeTrust's structural scanner, it introduces a data-driven approach to identifying where AI integration can succeed safely and where it is likely to struggle.