AI coding tools are deployed across enterprise engineering teams worldwide. GitHub Copilot, Cursor, Claude, Gemini. Billions of dollars invested. Productivity narratives everywhere.
The measurable enterprise results haven’t arrived.
McKinsey’s own data shows that while AI tool adoption is near-universal, fewer than 30% of enterprises report meaningful productivity gains from software development automation. Microsoft — the company whose CEO confirmed that 20 to 30% of its own code is now AI-generated — cancelled its Claude Code licences across entire divisions when per-engineer API costs hit $2,000 per month. In November 2025, core Windows 11 features were found to have been broken since July — four months undetected.
Enterprise teams are not failing to adopt AI. They are failing to extract value from it. The question nobody is asking clearly enough: why?
The answer is not the tools. The answer is the software the tools are integrating with.
When an enterprise AI initiative underperforms, the standard response is to reassess strategy, retrain teams, improve governance, upgrade infrastructure. Deloitte, McKinsey, Gartner, Accenture all have frameworks for this. They are thorough, well-researched, and widely used.
Not one of them looks at the codebase.
his is not a minor oversight. AI does not deliver value through strategy, governance, or training programmes. Unlike Agile, SAFe, CCPM, or Lean — which are methodologies you adopt by changing how people work — AI is technology. It integrates into systems. It runs through code. And if that code is not structurally ready to absorb it, the value never arrives. Not because the strategy is wrong. Not because the team isn’t capable. Because the substrate is incompatible.
The Big Four assessed AI readiness the same way they assessed Agile readiness. Interviews. Workshops. Culture surveys. So we did something different.
We didn’t interview people. We interviewed the software.
350 open-source repositories across 15 industry verticals. Four leading AI systems — Claude, OpenAI, DeepSeek, Manus.im — each asked to independently assess and grade the AI readiness of the same codebases. No system saw another’s results. No pre-assigned grades influenced the outcome. We then ran each repository through CodeWeTrust’s structural scanner and compared the results.
Across five completely independent systems — four qualitative AI assessors and one structural code scanner — agreement within one letter grade was 85.1% across all 350 repositories.
The radar charts below show how each assessor compares — first against LLM consensus as the benchmark, then against the structural scanner as the benchmark. All four LLMs are systematically more optimistic than structural scanning. They assess on reputation, known governance, visible signals. The scanner measures structural conditions that are invisible to qualitative judgment.
Before the outliers, two findings from the benchmark that matter commercially:
1. C2M’s structural scanner converges with the world’s leading AI systems — despite using completely different inputs.
The LLMs assess AI readiness qualitatively — repository reputation, governance signals, community health, documentation, known architecture. C2M measures structurally — long method density, commit velocity, active ownership, security exposure, code duplication, dependency health, fix instability, complexity. Completely different data sources. Completely different methods. Yet 85–90% agreement within one grade across 350 repositories. This is not an accuracy claim. It is a convergence finding: the structural conditions C2M measures are the same conditions that independent expert judgment recognises as determinants of AI readiness. The two approaches are reading the same underlying reality from different angles.
2. The convergence held as the benchmark scaled from 20 to 350 repositories.
This study did not begin with 350 repositories. It began with 20 — a deliberately chosen set spanning well-maintained and structurally problematic codebases. As the benchmark expanded — adding new industry verticals, new languages, new structural types, new assessors — the agreement pattern held. The methodology did not improvise to fit new data. It produced consistent results at scale. That is the scalability validation that distinguishes a reproducible instrument from a one-time exercise.
Together these two findings establish something precise: C2M does not guess. It does not rely on reputation or visible signals. It measures structural properties mechanically — and those measurements align with what the most capable AI systems in the world conclude from qualitative assessment. At scale. Consistently. That is the foundation on which the divergence cases below become meaningful rather than arbitrary.
The 8 cases where C2M diverged from LLM consensus by three grades or more are the study’s most commercially important result. In every single case, all four LLMs rated the repository A or B. The structural scanner found conditions that explain precisely why AI integration would be fragile in practice.
TECHNICAL DEBT ≠ AI READINESS
Technical debt asks: how much would it cost to fix what is broken? AI readiness asks: are the structural conditions compatible with safe AI-assisted development? A codebase can carry near-zero technical debt and still be structurally incompatible with AI integration. PromptFlow is the clearest example in the dataset: 0.4% technical debt, grade C on AI readiness.
The organisations that will extract returns from AI investment are not necessarily the ones with the best strategy or the largest budgets. They are the ones that sequence the journey correctly.
AI integration does not have to succeed everywhere at once. It has to succeed somewhere first — where the structural conditions are right, where the codebase will absorb AI-generated changes safely, where velocity and ownership and complexity make integration tractable. Start there. Build knowledge. Move to the harder modules later.
Organisations that deploy AI at scale without a structural readiness signal risk exactly the scenario Microsoft faced: spiralling API costs and destabilised core products. Correlation is not causation — but the pattern is consistent with what happens when deployment outpaces structural assessment.
The question is not whether to proceed with AI. The question is where to start.
This study does not claim that a structural scan predicts production outcomes. That longitudinal evidence is the next research phase. What it establishes is simpler and more immediately useful: the structural dimension is real, measurable, and consistent across independent methods — and it is the dimension nobody currently measures before committing the budget.
The full benchmark — 350 repositories, 15 industries, five assessors, complete grade data — is available on request. If you want to know where your own codebase sits: structural assessment in 48 hours, no source code leaves your environment.
codewetrust.com, info@codewetrust.com
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.
Discover how C2M 9.2 combines deterministic software analysis with AI-driven insights to assess security, quality, and technical debt—without ever sharing proprietary source code.