In his Sequoia AI Ascent 2026 fireside chat, Andrej Karpathy drew a clean line between vibe coding and what he called agentic engineering — a professional discipline of orchestrating long-running AI agents, reviewing their output with rigor, and maintaining quality oversight. He described his own transition from 80% manual coding to 80% agent-directed work, and framed the current era as Software 3.0: programs written as prompts, LLMs as the interpreter that runs them.
The individual framework is correct and clearly articulated. What it doesn’t address is what happens when twenty engineers on the same team make this shift simultaneously — without a shared specification standard, without updated review processes, and without a clear ownership model for code that agents generated.
stateDiagram-v2 direction TB state "Individual coding<br/>Engineer writes every line" as S1 state "AI-assisted coding<br/>Copilot and autocomplete" as S2 state "Agentic engineering<br/>Orchestrate, spec, oversee" as S3 state "No process update<br/>Quality drift, ownership gaps" as Stall state "Org-adapted agentic<br/>Spec standards and review gates" as S4 [*] --> S1 S1 --> S2: 2022–2024 S2 --> S3: 2025–2026 S3 --> Stall: old review process<br/>no ownership model S3 --> S4: specification standards<br/>explicit review gates Stall --> S4: leadership intervention S4 --> [*]: sustainable high output
The Rundown: Software 3.0 and the New Discipline
In his Sequoia AI Ascent fireside chat, Karpathy traced three eras of software programming. Software 1.0 is code — explicit instructions that humans write. Software 2.0 is learned weights — neural networks trained on data. Software 3.0 is prompting: the program is the text in your context window, and the LLM is the interpreter.
From that framing he defined two distinct positions in the current landscape. Vibe coding raises the floor: anyone can build a functional thing without understanding how it works. Agentic engineering raises the ceiling: a professional discipline of directing long-running agents — writing tight specifications, reviewing agent-generated diffs with actual rigor, designing evaluations that catch regressions, managing permissions and security. The engineer’s role is no longer to write every line but to maintain judgment, taste, and quality oversight over what the agents produce.
Karpathy marked December 2025 as the inflection point where multi-step agentic workflows started producing coherent, reliable output at meaningful scale — not demos, but production-level work. He described feeling “behind as a programmer for the first time,” not because AI replaced him, but because the pace of capability expansion outpaced his ability to adapt his own workflow.
For Engineers: Quality Ownership Is Now the Job
When agents can generate a thousand lines of functional-looking code in ninety seconds, code generation is no longer the bottleneck. Quality judgment is.
Karpathy is direct about what the new skill set requires: spec design (a description tight enough that the agent builds the right thing), diff review (evaluating large AI-generated changes with the rigor a senior engineer applies to their own code), and eval design (tests that distinguish working from working-by-accident). These are the skills that determine whether your output is reliable or just plausible.
The gap between vibe coding and agentic engineering is exactly this: vibe coding accepts what the agent produces. Agentic engineering owns what the agent produces. If you are not actively building evaluation skills — how to write acceptance criteria, how to detect edge-case blindness in a large diff, how to design a test that actually exercises the intended behavior — you are accumulating a quality debt that will become visible when the stakes are real.
The practical step is to find one project where you are accountable for the outcome, use agents throughout, and build your evaluation practice around the real consequences. You learn the discipline by owning the result.
For Business Owners and Operators: The Organizational Layer Needs Updating
Your engineers are already using agentic tools. Most engineering organizations have not updated their processes to match.
Code review is structured for human-written code. Ownership models assume one engineer understands their module. Performance assessment measures tickets closed or lines shipped, not the quality of specifications written or the rigor of oversight applied. Those measures made sense when code generation was the constraint. They do not make sense when agents can generate ten times as much code in the same window.
The questions that surface when an engineering team makes the agentic shift:
- Who owns the specification? When an agent builds to the wrong spec, who is accountable?
- What does a valid review look like for a 600-line AI-generated diff?
- How do you assess whether an engineer is developing judgment or just shipping agent output without real oversight?
These are not questions agents answer. They are organizational questions, and most engineering teams are working through them after a production incident forces the issue.
My Take
I spent several years as the senior architect at LERETA, leading a team of thirty-plus developers through a multimillion-dollar mainframe modernization effort. Multiple teams were working in parallel on interdependent modules, each making design decisions that touched shared architecture. The one structural practice that kept quality intact was an explicit review gate: nothing moved toward production without a checkpoint staffed by someone accountable for evaluating the whole, not just the piece in front of them. We built it because we had to — without it, quality decisions that needed coordination were being made independently at the feature level, and the inconsistencies accumulated.
Agentic engineering will require the same kind of gate, and most organizations are trying to build it retroactively. The engineers I work with now are producing impressive output with agents. The gap is not the tools — it’s the oversight structure. Some engineers have built disciplined evaluation practices. Others replaced their old review process with nothing, because the agents made friction easy to bypass.
Karpathy’s framework defines the new discipline at the individual level with unusual clarity. The organizational translation — how you structure a team of engineers who are all now orchestrating agents, how you maintain quality accountability across that structure, and who sets the specification standard — is the work that falls to engineering leaders. The companies that build these practices deliberately will have a real and durable advantage over those that discover the gap from a post-incident review.
