Earlier this year, Andrej Karpathy posted about a shift in how he was using LLMs: he had moved “a large fraction” of his token budget from generating code to using AI to build and maintain personal knowledge bases — structured, interlinked Markdown wikis compiled from raw source documents and kept current by the model itself. For personal research, this is a productivity pattern. For enterprise software, the architectural implications run considerably deeper.
mindmap
root((Enterprise software<br/>in the AI era))
Knowledge management
LLM-maintained architecture docs
Living integration maps
Documentation upstream
Context before generation
Authoritative single sources
Human oversight
Architecture review gates
Accountable owners
AI as contributor
Code generation from context
Knowledge base maintenance
Enterprise Software Has Always Been a Knowledge Management Problem
Before it is a technology problem, enterprise software is a knowledge problem: hundreds of applications built by different teams at different times, architectural decisions made in contexts that no longer exist, integrations documented to varying degrees of accuracy, and institutional knowledge distributed across people who may or may not still work there.
At First American Financial — the world’s largest title insurer at the time, managing roughly 770 applications across 15+ subsidiaries, with 900 engineers and a database containing 100 million U.S. property records — I was part of a team that spent months auditing the application estate and making the architecture legible enough that decisions could be made from it. The resulting enterprise architecture documentation became known internally as the Livermore Report. The central challenge was not building anything new — it was making existing institutional knowledge visible and authoritative before any decisions were driven from it.
That is the enterprise version of what Karpathy is describing at a personal scale. The AI-era execution would look different, but the purpose is identical.
What Changes When AI Maintains the Knowledge Base
Karpathy’s approach treats the LLM as a compiler: it reads raw source documents and produces a structured, cross-referenced wiki that it then maintains and updates. For a personal research context, this means the model is synthesizing new information against existing notes and identifying contradictions as they arise.
For an enterprise architecture team, the same concept applied to institutional documentation would produce a different starting point for every technical decision. Instead of a developer spending two days hunting through Confluence to understand how a legacy integration works before writing their first prompt, the knowledge is synthesized and current. The AI coding agent has access to the actual integration map, the security policy, and the data model — not the version from two years ago that was never updated after the migration.
The compounding effect is not in the AI’s ability to generate code faster. It is in the accumulated institutional knowledge it can draw on when generating. Documentation maintained at the level of architectural precision that Karpathy describes for his personal knowledge bases would change the quality of AI-generated code in an enterprise context more than any improvement to the underlying model.
Three Structural Shifts in Enterprise Software Creation
The AI era is changing how enterprise software gets built in three specific ways — not because the tools are impressive in the abstract, but because they alter the economics of foundational work.
Documentation has a new leverage point. When AI coding agents work from institutional documentation, the accuracy and completeness of that documentation directly determines the quality of the generated output. This inverts the traditional relationship where documentation was a downstream artifact teams produced after the code was done. In an AI-first model, documentation is upstream context that shapes what gets built. A team with current, accurate architecture documentation will see better AI output than a team with a better model and outdated docs.
Architectural knowledge compounds differently. At First American, the architecture work took months to produce and was captured in static diagrams. An AI-maintained knowledge base of the same scope would produce a living document — one that updates as new decisions are made and that can be queried directly by the coding agents extending the system. The compounding effect is not just efficiency; it is the ability to apply accumulated organizational knowledge at the point of generation rather than in the review afterward.
The self-development signal is real. According to Anthropic, Claude is now leading 26% of the company’s own model R&D end-to-end. The model that millions of developers use to generate enterprise software is itself being used as a development contributor on the next generation of the model. Whether or not that specific percentage compounds, it marks a point where treating AI as an architectural participant rather than a code typist is no longer theoretical.
What Doesn’t Change
The shift in enterprise software creation that matters is not about which tools teams adopt. It is about whether the underlying knowledge and architectural discipline are in place to support AI-generated output.
A team without clean architectural documentation doesn’t fix that problem by giving everyone a coding agent. The agent generates against the context it has — if that context is incomplete or inconsistent, the output reflects it. The First American experience is the benchmark: the architecture work that produced the Livermore Report was valuable not because of the technology used to produce it, but because of the systematic effort to make institutional knowledge legible and authoritative before decisions were driven from it.
That work is still the prerequisite. The AI changes how it is maintained, not whether it is needed.
