A recent Pragmatic Engineer survey of roughly 1,000 software engineers found that Claude Code has become the top AI coding tool among smaller engineering teams — but that enterprise teams still default to GitHub Copilot. The explanation for the split that showed up most consistently: monolithic codebases are the biggest blocker to enterprise AI adoption. Not budget. Not executive buy-in. The structure of the code itself.
quadrantChart title AI Coding Tool Adoption vs Engineering Org Maturity x-axis Low Org Complexity --> High Org Complexity y-axis Low AI Adoption --> High AI Adoption quadrant-1 Agent-first engineering quadrant-2 Early-majority risk zone quadrant-3 Trailing the curve quadrant-4 Tool-native teams Pre-seed startups: [0.14, 0.75] Smaller SaaS teams: [0.28, 0.80] PE-backed mid-market: [0.48, 0.44] Enterprise 500 plus engineers: [0.75, 0.30] Legacy monolithic orgs: [0.85, 0.14]
The Tool Split Is an Architecture Signal
When Claude Code leads in smaller teams and Copilot leads in enterprise, the obvious interpretation is that larger organizations are slower to change tools. That is partially true. But the deeper signal is about what each tool is actually operating on.
Claude Code shines when the codebase is modular — when the agent can understand a bounded context, generate against a clear interface, and produce output that a reviewer can evaluate without understanding the entire system. Smaller, newer codebases tend to have those properties. They were built recently, often by a small team with a consistent style, on modern frameworks with clean separations.
Enterprise codebases are different. After years of acquisitions, rapid scaling, and accumulated technical decisions made under deadline pressure, the codebase is not a well-organized library. It is a city that grew without a plan — layers of infrastructure built on top of previous layers, with integrations nobody fully understands and dependencies that exist only in the institutional memory of engineers who have been there for a decade.
An AI agent dropped into that environment does not produce clean, reviewable output. It produces code that looks reasonable in isolation and creates subtle problems at the integration points — problems that are hard to detect because the integration points themselves are poorly documented.
What I Saw at First American
At First American Financial, the world’s largest title insurer, I spent two years working with an architecture team trying to understand and consolidate over 700 software applications across 15+ subsidiaries. The company had acquired more than 80 firms in a decade, and each acquisition came with its own technology stack, its own data models, and its own set of integrations that had been promised as post-close projects and never finished.
That environment is not a corner case. It is what the majority of mid-to-large enterprises actually look like from the inside. When AI coding tools are dropped into an environment like that, the tool’s output is only as useful as the team’s ability to evaluate it — and evaluating AI-generated code against an undocumented system is not faster than writing the code manually. It is often slower, because the generated code has to be understood before it can be trusted.
The blocker is real, and it is not going away until the underlying architecture is cleaned up. Companies that understand this are investing in architecture modernization as the prerequisite for AI-assisted development. Companies that skip the prerequisite are discovering that AI tools produce code faster without producing software quality.
The Path Forward for Enterprise Teams
The path to productive AI-assisted development in an enterprise environment runs through the codebase, not around it. That means identifying and documenting the integration points, establishing clear ownership boundaries for each system, building sufficient test coverage to make AI-generated changes evaluable, and decomposing monolithic systems into bounded components that an agent can reason about in isolation.
At Oakwood Worldwide — the largest corporate housing company in the U.S. at the time — I oversaw an architecture program that targeted exactly this kind of consolidation across 80+ applications and 100+ developers. The work was slow and unglamorous. It involved chaired meetings across six departments, detailed integration diagrams, and steady pressure to establish patterns that the teams could follow consistently. It also made the resulting technology infrastructure significantly more maintainable and significantly more legible to leadership.
That is the prerequisite work for enterprise AI adoption. It is not the exciting part of the story. But the alternative — dropping AI tools onto a codebase that is not ready for them — produces AI-assisted technical debt, which is still technical debt, accumulated faster.
What This Means for Engineering Leaders
If your enterprise engineering team is not getting meaningful productivity gains from AI coding tools, the default diagnosis in most organizations is “change management” or “tool selection.” Both are usually wrong. The diagnosis is almost always architectural.
The question worth asking is not “which tool should we standardize on?” It is: does our codebase have the structure that allows AI tools to produce output our engineers can evaluate and trust? If the answer is no, the path forward starts with architecture, not tools.
The investment in that foundation is not a cost to be avoided. It is the precondition for every AI productivity gain the engineering team is supposed to achieve.
