Andrej Karpathy recently drew a line between where enterprise software development is and where it needs to go. Vibe coding — using AI to generate code quickly and intuitively — raises the floor, he said. Agentic engineering is about raising the ceiling: coordinating AI agents while preserving correctness, security, and maintainability. His framing at Sequoia’s AI Ascent conference was precise about what the discipline requires: you are not just prompting models. You are acting as a technical supervisor who sets the standards, reviews the outputs, and maintains the architectural coherence that prevents individual AI contributions from drifting.
Most enterprise teams have not made this transition. They are using AI tools at the task level — individual developers prompting models for functions, tests, and components — without a coordination layer that ensures those contributions fit together at the system level. The individual contributions are faster. The integration and quality work has not gotten faster. The gap between the two is where the enterprise software problem lives in 2026.
sequenceDiagram participant A as Ad-hoc AI Team participant E as The Build participant O as Orchestrated Team Note over E: Feature requested A->>E: Each dev generates independently E-->>A: Integration conflicts surface A->>E: Manual reconciliation required Note over E: Same feature requested O->>E: Standards defined before generation O->>E: AI agents work within architecture E-->>O: Output meets quality gate E-->>O: Ships without reconciliation
What Enterprise Teams Are Actually Doing
Walk through the engineering practices of a mid-market company that adopted AI coding tools in the past two years and you typically find the same pattern. Individual developers are faster. Pull request volume is up. The number of lines shipped per sprint has increased. At the sprint level, everything looks improved.
At the system level, a different picture emerges. Integration issues are surfacing more frequently. Architecture decisions that were previously consistent are beginning to diverge across features — different developers made different choices about the same patterns because each was working with a model that filled in the blanks based on what was already in the immediate context. Test coverage has grown, but a meaningful portion of the tests are testing the model’s assumptions about the code rather than the code’s actual behavior. Technical debt is accumulating faster than it looks like from the contribution metrics.
This is not a problem with AI coding tools. It is a problem with treating AI code generation as a drop-in replacement for human code generation without redesigning the coordination layer that made human code generation coherent at scale.
What Coordination Actually Requires
Karpathy’s enterprise orchestration framing is useful precisely because it shifts the unit of work from the individual contribution to the system. Orchestration — in the technical sense he is describing — means treating each AI contribution as an agent output that needs to be checked against the system’s constraints before it is accepted.
At Oakwood Worldwide, I spent three years overseeing architecture for a 3,000-person company running more than 80 applications across global locations, with more than 100 developers contributing to a distributed technology infrastructure. The work that moved the program forward was not any individual architectural decision — it was establishing and maintaining consistent patterns across the entire development organization so that each team’s work fit together with the other teams’ work. When those patterns were clear and enforced, individual contributions compounded into system-level improvement. When they were absent or inconsistent, individual contributions compounded into integration debt.
Enterprise AI development has the same shape. The coordination layer — the architectural standards, the quality gates, the review processes, the integration patterns — determines whether individual AI contributions compound into capability or accumulate into debt.
The Orchestration Layer in Practice
Building an orchestration layer for enterprise AI development requires four things.
Defined architectural constraints. The system needs to have established patterns for how AI-generated contributions should connect to existing architecture — the data models they should use, the APIs they should call, the error handling conventions they should follow. Without this, each AI contribution is being made against a different mental model of what the system is.
Review standards specific to AI output. Code review for AI-generated code needs to account for failure modes that are specific to AI output: hallucinated dependencies, tests that mock rather than test, integrations that match documentation rather than actual API behavior. Standard code review processes were designed for human code and miss these failure modes reliably.
Integration tests that verify system behavior. Unit tests on AI-generated code verify the AI’s assumptions. Integration tests that run against real external dependencies verify reality. The gap between the two is exactly where vibe-coded enterprise applications are failing in production.
Ownership of the coordination layer itself. Architectural standards drift when no one is accountable for maintaining them. The orchestration layer needs an owner who has both the technical authority to enforce standards and the organizational standing to push back on contributions that violate them.
The Ceiling Karpathy Is Pointing At
The shift from vibe coding to agentic engineering is a maturity transition, not a technology upgrade. The tools are the same. What changes is the discipline around how those tools are used — the supervision, the standards, the integration rigor, and the architectural coherence that allow AI contributions to scale without degrading the system they are building.
Enterprise software teams that are still at the ad-hoc generation phase are leaving most of the value on the table. The productivity gain at the contribution level is real but modest compared to the productivity gain available at the system level when AI contributions are well-coordinated and the integration work stops being the bottleneck.
The ceiling Karpathy is pointing at is not theoretical. It is the delta between what teams are seeing now — faster individual contributions with no change in integration velocity — and what is available when the coordination layer is built correctly. Closing that gap is the enterprise software strategy for 2026 and beyond.
