Andrej Karpathy’s fireside chat at Sequoia AI Ascent 2026 led with a point that got less attention than it deserved: the primary value of LLMs is not that they speed up what already existed. It is that they enable things that didn’t exist before. The coding acceleration story is real — but it is the less interesting story.
For enterprise software, this matters. The question is not how to use AI to write the same code faster. It is what kind of software becomes buildable now that wasn’t buildable before — and whether your engineering organization is organized to build it.
sequenceDiagram participant E as Engineering participant L as Leadership participant A as AI systems Note over E,L: Old approach L->>E: Build this — 18 months, 12 engineers E->>E: Build to specification E->>L: Delivered. New technical debt added. Note over E,L: AI-era approach L->>A: What can we now build? A->>E: Scaffold and prototype in weeks E->>L: Working prototype — refine requirements L->>E: Adjusted spec based on what we see E->>A: Build governed implementation E->>L: Delivered. Architecture intentional.
What the Old Paradigm Built
First American Financial — the world’s largest title insurer, with approximately 770 active applications, 900 engineers, and a data infrastructure covering 100 million U.S. property records — was, at the time I worked there as a principal architect, a direct consequence of twenty years of the old enterprise software creation paradigm.
The paradigm worked as follows: a business need emerged, an engineering team was resourced, a multi-year project was approved, software was built, the project was delivered (or not), and the resulting system was integrated into an increasingly complex application landscape. Over fifteen years and 80-plus acquisitions, that process accumulated 770 applications with overlapping functionality, inconsistent data models, redundant infrastructure, and integration debt that had never been formally mapped.
The board-level architecture diagrams I built with the CTO revealed the full scope of what that accumulation looked like — and the picture supported a multi-year, $100M-plus consolidation investment. The old paradigm produced this outcome reliably, at every organization I worked with that pursued it long enough. The problem was not specific to First American. It was intrinsic to the method.
What the New Paradigm Changes
AI-era enterprise software creation is different in three structural ways.
Prototype before committing. The old paradigm committed resources to a requirement before a working system existed. A working system only existed after 18 months and significant engineering headcount, which meant the organization learned what the software should actually do by delivering what it thought the software should do. The AI era makes working prototypes available in days or weeks. That changes what requirements means — you define requirements in response to a working prototype rather than in anticipation of one. The software that emerges is more accurate to what the business actually needs.
Integration that compounds. AI-native development enables a different kind of integration than the old paradigm. An AI system that can read, interpret, and generate content across formats — documents, databases, APIs, legacy outputs — can act as an integration layer that the old paradigm would have required months to build manually. Organizations with significant legacy integration debt can start replacing that infrastructure incrementally rather than planning another multi-year platform migration.
Knowledge as infrastructure. The shift Karpathy described — from code as the primary output of engineering work to knowledge infrastructure as the output — has direct enterprise implications. The institutional knowledge that enterprise organizations lose when engineers leave, when systems change, when documentation falls behind — that knowledge can now be captured, maintained, and queried by AI agents designed for exactly this purpose. The enterprise software systems of the next decade will include this layer as standard infrastructure.
What Has to Change in the Engineering Organization
The enterprise software creation paradigm doesn’t change just because the tools change. The organization has to change how it uses the tools.
The most common failure mode I see: an engineering organization adopts AI-assisted development, individual engineers write code faster, and the net result is the same type of software produced at higher velocity. No change in what gets built. Just more of it, faster.
That failure mode happens when leadership frames AI adoption as a productivity initiative rather than a capability expansion. The right question is not “how does AI help us build what we were going to build anyway?” It is “what can we now build that the business needs but we couldn’t previously justify the cost to deliver?”
Every enterprise organization has a list of things on the backlog that are there not because they aren’t valuable but because they weren’t worth the cost to build with a conventional engineering team. That list is where AI-era enterprise software creation creates its greatest leverage.
The Organizational Requirement
To take advantage of this, an organization needs an engineering function with architectural judgment — not just AI-accelerated implementation capacity. The tools will generate code. Someone has to decide what to generate, why, and how it connects to the rest of the system. That judgment function is not automated by AI and is not replaced by faster code generation.
It is the thing that has always differentiated enterprise software organizations that build durable platforms from those that accumulate technical debt. In the AI era, it matters more, not less — because more code can be generated in less time, and the consequences of a bad structural decision compound faster.
The organizations that build well in this era are the ones that pair AI-accelerated implementation with deliberate human judgment about architecture. One without the other produces either slow software or fast mistakes.
