Andrej Karpathy posted in early 2026 that he had rapidly gone from roughly 80% manual coding and 20% agent coding to 80% agent coding and 20% edits and touchups. He described the shift as a phase transition — AI coding capability crossed a threshold of coherence around late 2025, and the workflow changed fast.
That description matches what I am seeing in enterprise engineering organizations. The implementation layer of software creation has changed materially. The architecture layer has not changed at all.
timeline title Enterprise Software Creation: What AI Changed, What It Didn't Phase 1 — Architecture : Unchanged — still requires human<br/>ownership of structural decisions Phase 2 — Requirements : AI-assisted precision — better<br/>specs enable better agent output Phase 3 — Implementation : AI-accelerated — 80% agent<br/>coding is the new baseline Phase 4 — Integration : More critical — more components<br/>and integration points to validate Phase 5 — Operational ownership : Unchanged — human accountability<br/>for system behavior post-launch
The Phase Transition Is Real
What Karpathy describes is not incremental improvement in coding assistance. It is a qualitative shift in where engineer time goes. Before the transition: an engineer designs the architecture, writes the specification, and then spends the majority of time authoring the implementation — translating decisions into code, line by line. After the transition: an engineer designs the architecture, writes the specification, and then reviews, validates, and directs the AI that produced the implementation. The ratio of creation to verification inverts.
For routine implementation work — building features within an established architecture, generating boilerplate, writing tests against a defined specification — this shift is a genuine multiplier. An engineer who previously delivered two features per sprint can now direct and validate six.
The constraint is upstream. The features are only worth building if the architecture is sound, the requirements are precise enough for the AI to work from, and the integration points are mapped before any code is generated. AI that implements against a vague specification produces code that works in isolation and fails in integration. The speed of implementation amplifies whatever quality went into the upstream decisions.
What the LERETA Modernization Taught Me About Architecture First
Before the AI coding era, the project that most clearly illustrated the primacy of architectural clarity over implementation speed was a multi-year engagement with LERETA, the second-largest property tax processor in the United States. The organization was running flagship products on aging mainframe technology, with a codebase that had accumulated decades of accumulated constraints.
What unlocked the $20 million modernization investment from the board was not a timeline or a feature list. It was architecture. I created wall-sized enterprise architecture diagrams that made the full critical path of the modernization legible — what depended on what, where the highest-risk transitions were, what could be phased and what could not. That documentation became known internally as the Livermore Report. It was the artifact that turned “we need to modernize” from a vague concern into a fundable program with a defined path.
The lesson has direct application to enterprise AI development. AI can implement against a specification faster than any team could write the code manually. The rate-limiting constraint is always the quality of the architectural thinking that precedes it. A precise architectural specification, expressed clearly enough for an AI agent to work from, unlocks the speed advantage. A vague one wastes it.
The New Upstream Discipline
Enterprise software creation in the AI age requires the same upstream discipline as before, expressed in forms that AI agents can consume. The specific artifacts have changed; the function has not.
Architecture documentation still comes first. Before any implementation begins — AI or otherwise — the structural decisions must be made: module boundaries, data model, integration patterns, failure handling. In an AI-assisted workflow, these decisions are often expressed as behavioral constraint files (CLAUDE.md files, starter templates, code footprints) that scope what the AI agent is expected to produce. The discipline of making these decisions explicitly, before implementation, is unchanged.
Requirements precision matters more, not less. AI agents are literal. A requirement that says “the user should be able to manage their account” produces something that satisfies the literal statement and misses the intent. A requirement that specifies the exact states, transitions, permissions, and edge cases the system must handle produces output that can be validated against the specification. The investment in requirement precision pays returns that were smaller when a developer could ask clarifying questions during implementation.
Integration mapping is more critical. AI-assisted development produces more components, more quickly, with more integration points. Each of those points is an opportunity for assumption mismatch — where what one component expects does not match what another provides. The speed advantage of AI implementation increases the volume of integration work proportionally. Organizations that skip integration mapping at the start pay for it when components are assembled and the assumptions collide.
What Has Not Changed
The accountability structure of enterprise software creation is unchanged. Someone must own the architecture — which means someone is accountable when the architecture does not scale, does not integrate, or does not support the next phase of requirements. AI cannot own that. It can implement within it.
Quality gates are unchanged. Code that has not been validated against the requirements, tested against defined behavior, and verified at integration boundaries does not go to production. The fact that an agent generated it is not a quality argument — it is a production input that requires the same evaluation as any other.
Operational ownership is unchanged. Once a system is in production, someone is accountable for its behavior, its failures, and its evolution. AI-generated code that no engineer fully understands is a maintenance liability that compounds over time. The speed of creation does not reduce the obligation to understand what was created.
The organizations that get enterprise software creation right in the AI age are the ones that apply AI’s speed advantage where it belongs — implementation — without relaxing the discipline that determines whether the implementation is worth building.
