When First American Financial acquired more than 80 companies in a decade, they accumulated over 700 software applications across fifteen subsidiaries. CRMs, policy management systems, data pipelines, portals — many of them doing similar things in different ways, none of them fully integrated, all of them generating ongoing operational cost. The enterprise architecture work required to audit, consolidate, and rationalize that portfolio was years of effort and tens of millions of dollars. The core driver was not bad technology leadership. It was a strategic approach to software creation that prioritized acquisition speed over software estate coherence.
AI is creating the same dynamic in enterprise software creation today — just faster.
timeline title Enterprise Software Strategy in the AI Era 2022 to 2023 : Individual AI tools — ChatGPT, Copilot, scattered early adoption 2024 : Team-level AI integration — prompt libraries, LLM in pipelines, productivity gains 2025 to 2026 : Strategic reassessment — build vs. buy, architecture governance, platform layer 2027 and beyond : AI-native enterprise architecture — AI in the core, not the periphery
The Build-vs-Buy Calculus Has Shifted
The traditional enterprise argument for buying rather than building rests on cost and time. A commercial vendor has already solved the problem. Licensing is predictable. Implementation is faster than development. This argument has been correct enough in enough contexts that it has become organizational default: buy unless there is a strong reason to build.
AI changes the cost side of that calculus. The development work that used to require a team of six engineers for six months now requires a team of two or three with the same timeline, or a team of six with a significantly shorter one. When custom development becomes materially cheaper, the threshold for when it makes sense to build drops — and a meaningful number of software decisions that should be “build” are still defaulting to “buy” because the strategy has not been updated.
The risk of not updating the strategy is straightforward: you buy platforms and licenses for problems that a custom solution would have solved better, cheaper, and with less technical debt, because the vendor’s product makes assumptions about your use case that do not fit your actual workflows.
The Architectural Implications of Code Generation at Scale
The Pragmatic Engineer’s reporting on Anthropic’s engineering practices found that 70 to 90 percent of internal code is now AI-generated. The architectural implication is not obvious but is significant: when code generation is this fast, architectural decisions matter more, not less, because the cost of acting on a wrong architectural premise has grown. More code, generated faster, built on the wrong foundation means more code to migrate when the architectural assumption needs to be corrected.
This is the trap that enterprises fall into when they adopt AI coding tools as a productivity play without updating their architecture governance. The code volume increases. The architecture review cadence stays the same. The gap between how fast the codebase is growing and how clearly the architecture is understood widens.
I spent years at First American working on exactly this problem without AI in the picture. The 770 applications I helped audit were not built poorly — most of them were built correctly for their original purpose. The strategic failure was building across eighty-plus acquisitions without a coherent framework for integration and consolidation, so each addition added not just new capabilities but new technical debt and new architectural fragmentation. AI accelerates that pattern for companies growing their software estate without corresponding architecture discipline.
Team Structure Is the Next Strategic Decision
The organizations that have successfully integrated AI into enterprise software creation are not simply using the same team structures with better tools. They are restructuring around AI’s capabilities.
The most significant structural shift is the ratio of architecture work to implementation work. When AI handles a larger fraction of implementation, the value of people who can define clear architectural boundaries, document patterns for AI agents to follow, and review AI-generated output for architectural coherence increases. The implementation bottleneck has loosened; the architecture and review bottleneck is tightening.
This has implications for hiring and team composition. The software teams that will perform well in the AI era are not necessarily the largest ones — Anthropic’s two-pizza team norm persists despite dramatically higher AI-generated code volume — but they need a higher proportion of people capable of architectural thinking and technical review than implementation-heavy teams required five years ago.
The Platform Layer as Strategic Investment
The strategic investment that enterprise companies are consistently undermaking is the platform layer: the foundational patterns, starter templates, documentation frameworks, and shared components that AI agents use as context when generating code.
When AI generates code against a well-defined platform layer, the output is consistent, maintainable, and aligned with architectural decisions. When AI generates code without a platform layer — against whatever context is available in the recent files — the output varies and accumulates inconsistency. The platform layer is the multiplier on every downstream AI coding decision.
The companies that will have the most coherent software estates in five years are not the ones buying the most capable AI coding tools. They are the ones investing in the platform layer that makes those tools work well at scale — because they have figured out that the tool’s output quality is determined more by the quality of the context it is given than by the capability of the model itself.
The Strategic Question to Answer First
Before any enterprise decision about AI in software creation — which tools to adopt, how to restructure teams, which use cases to prioritize — there is one architectural question that constrains all of them: what is your platform layer, and is it current?
If the answer is that you do not have a documented platform layer, or that the one you have is years out of date, that is where the strategy starts. Everything built on top of an unclear foundation inherits the lack of clarity.
