Andrej Karpathy recently described his coding workflow shifting from 80% manual to 80% agent-assisted, with 20% touchups. That is a real shift, and for teams operating at high speed it describes something important: the agent does most of the generation, and the engineer does the review. The question most teams have not answered is what happens when the review gets skipped.
stateDiagram-v2 direction TB state "Agent generates feature" as Gen state "No tests written" as NoTests state "No docs or ownership assigned" as NoDocs state "Production incident" as Incident state "Architecture review reveals gaps" as Review state "Rework at scale or due diligence" as Rework [*] --> Gen Gen --> NoTests: review skipped Gen --> NoDocs: agent moves on NoTests --> Incident: first edge case in prod NoDocs --> Review: six months later Incident --> Rework: root cause unclear Review --> Rework: ownership gaps compound
What the Code Footprint Actually Is
When an AI agent generates a feature, it leaves behind more than code. It leaves behind an architecture decision — even if that decision was never made explicitly. A table schema, an API integration, a dependency — each one has an implicit logic that will govern every future change to that part of the system. If the engineer who shipped the feature understood that logic, the footprint is manageable. If the agent shipped it and the engineer moved on, the logic exists only in the implementation, where it waits to be discovered under pressure.
This is the code footprint problem. It is not about whether the code works. It usually works, at least initially. It is about who understands it, what it assumes, and what happens to those assumptions when the business scales, the team changes, or someone attempts to integrate a new system.
Gergely Orosz made a pointed observation in a recent post: professional software engineers using AI tools and paying close attention, validating before committing, should not be described as vibe coding. The term matters because it sets expectations — both for teams doing the work and for leadership evaluating the output. If the code was generated carelessly and shipped without review, that is a different product than code that was generated and then validated by someone who understood the architecture.
What Gets Left Out When the Agent Moves On
The agent does not write tests unless you tell it to. It does not document ownership. It does not flag when a new integration conflicts with an existing pattern. It does not flag when a generated schema creates migration complexity three releases from now. All of those things require deliberate judgment — the kind that comes from someone who has thought about the system as a whole, not just the feature at hand.
At Carvana, I led a small data team of five developers processing millions of vehicle records daily using an event-driven architecture. What made that team effective was not their speed — it was the relentlessness they brought to accuracy. Every integration point was reviewed. Every data contract was explicit. The architecture was not the output of the fastest code generation — it was the output of the most careful reasoning about what the system needed to sustain. Small teams with solid architectures outperform larger ones with sprawling footprints. The AI era has not changed that. It has made the contrast more visible faster.
The Acquisition Due Diligence Problem
When Ziptask — the technology marketplace startup I co-founded — came close to acquisition three times, I learned directly what the other side of the table cares about. Acquirers want to understand what they are buying. They want architecture materials at the ready. They want to know who built what, why the decisions were made, and whether the team minus a few key people can sustain the platform. “As organized as humanly possible” is how I describe the preparation that matters, because walking into a boardroom without that organization is visible immediately.
A vibe-coded codebase that was never reviewed, documented, or stress-tested does not pass that test. It does not fail dramatically — it leaks. The technical due diligence team finds something unexpected in the database schema. The integration map is incomplete. The test coverage is thin. Each finding is a discount or a condition or a reason for a slower process. None of that is visible in the demo.
The Discipline That Closes the Gap
The answer is not to abandon AI-assisted development. It is to treat the review and documentation steps as non-negotiable, exactly because the generation step has become trivially fast. The leverage of vibe coding is real — features that took a week to build can now take an afternoon. But that leverage only compounds when the code footprint is managed. When it is not managed, the speed advantage of the first year becomes the technical debt problem of year three.
The teams that navigate this well have made a deliberate decision: AI generates, engineers validate, and the architecture review happens on a cadence that keeps the footprint legible. That discipline does not slow the team down meaningfully. It keeps the codebase sellable, scalable, and maintainable — which is the outcome that matters at the moments that count.
