Andrej Karpathy’s description of the shift from “vibe coding” to “agentic engineering” — where the developer’s role becomes orchestrating AI agents rather than directly authoring code — captures something that most company leadership has not fully absorbed yet. If AI agents are writing most of the code, someone still has to be accountable for the architecture those agents produce.
That accountability has to live somewhere in the organization. At AI-native companies and at companies that have moved substantial portions of their development into AI-assisted workflows, it is increasingly falling to the fractional CTO. Not as a codebase reviewer in the traditional sense — reading every pull request, catching every bug — but as the person responsible for the structural integrity of what the AI-assisted process is producing, at the level that matters for long-term reliability.
quadrantChart title Fractional CTO Oversight in AI-Native Development x-axis Low AI Code Generation --> High AI Code Generation y-axis Low Architecture Complexity --> High Architecture Complexity quadrant-1 Architecture review critical quadrant-2 Governance framework needed quadrant-3 Standard oversight applies quadrant-4 Quality gates and velocity management Agent pipeline companies: [0.85, 0.88] Vibe-coded MVP: [0.75, 0.25] Hybrid dev team: [0.45, 0.65] Traditional engineering: [0.15, 0.55]
What Architecture Review Looks Like When AI Writes the Code
The traditional model of software architecture review assumed a development process where human engineers made explicit decisions about structure — what belongs in which service, how data flows between systems, what the failure modes are for each integration. Those decisions were made consciously, even if not always correctly, and a senior architect or CTO could audit them by reading the design documents, reviewing pull requests, and asking questions in design discussions.
AI-assisted development changes this. A codebase built with significant AI generation grows faster than any team can manually read. Architectural decisions that a human engineer would make slowly and with deliberation — because they had to understand the codebase well enough to write the next piece of it — are now happening implicitly, as the AI model makes structural choices that compound over hundreds of generations. The resulting codebase can be functional and even impressive while accumulating technical debt at a rate that the team cannot see because they are not reading the code; they are prompting for it.
At Carvana, I led a five-person development team processing millions of vehicle records daily through an event-driven architecture. The team was small and technically excellent. The architecture was tight because five people who read every line of code will naturally detect when something is inconsistent with the structure they have been maintaining. That natural detection mechanism does not exist when the code is generated faster than any human reads it. Architecture review has to be a deliberate, scheduled function — not an emergent property of a team that knows its codebase.
The Three Things Fractional Architecture Review Has to Catch
Structure drift. As AI-assisted development generates new code across multiple features and services simultaneously, the architectural structure that was defined at the start of the project gets eroded. Services that were supposed to have clear boundaries develop cross-cutting dependencies. Data models that were designed for a specific use case get repurposed in ways that make them harder to evolve. The AI model makes locally coherent choices that are globally inconsistent with the intended architecture. A fractional CTO reviewing architecture quarterly is not enough to catch this — it has to be a cadenced review against explicit structural documentation, updated as the system evolves.
Reliability gaps. Agentic pipelines that handle production workloads have specific reliability requirements: what happens when the model is unavailable, when the output is ambiguous, when the pipeline runs longer than expected, when a downstream service returns an error? These failure modes are not self-documenting. A developer prompting for a feature is not thinking about what the feature does when the model fails at 2 AM on a Saturday. The architecture reviewer’s job is to ask that question systematically — for every agentic component in production — and to verify that the answer has been implemented.
The accountability chain. Every agentic pipeline that takes consequential action in production needs a named human owner who understands what it does and is empowered to shut it down. As AI-native companies scale, the number of agentic pipelines grows faster than the organizational accountability structure to support them. The fractional CTO’s job is to maintain that accountability map — to know which pipelines are running, who owns each, and what the intervention protocol is for each — so that when something goes wrong, there is a clear path to resolution rather than a scramble to figure out who built the thing and whether it can be stopped without taking down something adjacent.
The Oversight Function Is Not Optional
The shift to AI-assisted development reduces the cost of producing code dramatically. It does not reduce the cost of producing bad architecture — it increases the rate at which bad architecture can accumulate before anyone notices.
A fractional CTO engaged specifically for architecture review and oversight is not a luxury for AI-native companies. It is the governance layer that makes AI-assisted development safe to scale. The alternative — generating code at high velocity without a systematic architecture review function — produces a codebase that looks functional until the accumulated structural debt surfaces as a reliability event, a security exposure, or a rewrite that costs more than the original development did.
The oversight function has to be deliberate, cadenced, and owned. Whether it lives in a fractional engagement or a full-time role depends on the pace and complexity of the development. But it has to live somewhere.
