Andrej Karpathy’s 2026 note on his coding workflow was specific: roughly 80% of his coding time had shifted from manual plus autocomplete to agent-driven work with touchups, a transition that happened over a matter of months.
That is a useful data point for individual developers. For an engineering team of 20, it’s the beginning of a harder conversation.
journey title Engineering Team AI Adoption Experience section Early Enthusiasm Individual productivity gains: 5: Team Management requests team rollout: 3: Leadership section Governance Reality Inconsistent output across engineers: 2: Team Security review backlogs: 2: Leadership Integration failures surface: 1: Team section Disciplined Cadence Starter templates and code standards: 4: Leadership AI-assisted velocity stabilizes: 5: Team
What Happens When Individual Productivity Scales to a Team
A single developer using AI to generate 80% of their code output is making real-time judgments about what to accept, what to revise, and what to throw away. Those judgments reflect their experience, their understanding of the codebase, and their sense of what the system needs.
Twenty developers doing the same thing in the same codebase are making 20 sets of real-time judgments. Those judgments produce 20 sets of conventions, 20 approaches to the same recurring problems, and a codebase that looks like it was written by 20 different people — because it was, mediated by 20 different prompting styles and model interactions.
This isn’t a failure of the individuals. It’s what happens when a capability designed for individual use gets deployed at team scale without a governance layer. The speed is real. The problems are also real, and they arrive in a predictable sequence: first in code review (taking longer than expected), then in integration (modules that were each generated correctly but don’t fit together), then in security (AI-generated code following patterns that don’t meet the organization’s standards).
The Discipline That Makes Small Teams Scale
In 2016, I led a team of five developers at Carvana — then a fast-growing online car marketplace — building the inventory and vehicle-data systems that would serve external partners and fuel the company’s growth. The team was small by any measure. The scale of the data was not: millions of vehicle records, processed every day through an event-driven architecture that couldn’t afford inconsistency.
What made that team work at that scale wasn’t headcount. It was architectural discipline. Every engineer understood the data model and the event contracts. Every system integration followed the same patterns. When a new feature needed to be built, the conventions were already decided, so the decisions that mattered could stay focused on the actual problem.
That team was operating in 2016 without AI coding assistance. The same principle applies today with AI in the loop — and the leverage is even higher. A team that has established its architectural conventions and encoded them in a starter template can use AI to generate within those conventions at speed. A team that hasn’t done that work will find that AI makes inconsistency faster, not slower.
What Enterprise AI Governance Actually Requires
The governance layer for enterprise AI coding doesn’t need to be heavy. It needs three things.
A shared starter template that encodes the architectural decisions the team has agreed on: data model patterns, service boundaries, naming conventions, error-handling standards, and integration points. The AI generates within this template rather than from a blank slate. This is the single highest-leverage governance decision a team can make.
A code review standard calibrated to AI output. The standard checklist for manually written code doesn’t map cleanly to AI-generated code. AI-assisted output needs review focused on: integration assumptions that weren’t validated against the actual codebase, security patterns that may have followed general conventions rather than the organization’s specific requirements, and test coverage for edge cases the AI didn’t anticipate. These are different concerns from the standard review questions, and they need to be explicit.
A designated owner. Not a committee. One person accountable for maintaining the template, updating the review standard as the team learns, and calling out when output is drifting from the agreed conventions. In enterprise organizations, this role often falls to a principal engineer or an embedded fractional CTO who can see across the team’s output and maintain architectural coherence over time.
The Bottleneck Is Judgment, Not Speed
The engineering teams doing enterprise AI coding well aren’t moving faster than the ones doing it poorly. They’re compounding better. Output is consistent. Integration is predictable. Security reviews move at normal velocity because the AI was working within known-good patterns from the start.
The teams struggling aren’t struggling because AI is bad. They’re struggling because AI is fast and judgment is slow, and they didn’t build the scaffold that would let judgment run ahead of speed.
That scaffold is what enterprise AI governance looks like in practice. It doesn’t slow the team down. It makes the speed sustainable.
