Vibe Coding vs. Agentic Engineering

Sources#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501
• OpenAI Codex lead on the new shape of product work
• Thread by @AndrewYNg

Summary#

Andrej Karpathy coined "vibe coding" in 2025 and, a year later, names its serious successor: agentic engineering. The distinction is about which bar moves. Vibe coding raises the floor — anyone can build software now. Agentic engineering preserves the quality bar of professional software while going much faster: "you're not allowed to introduce vulnerabilities due to vibe coding; you're still responsible for your software, but can you go faster — and how do you do that properly?" It's an engineering discipline for coordinating spiky, fallible, stochastic-but-powerful agents without sacrificing quality.

The two bars#

• Vibe coding — floor up. Everyone can vibe-code anything. "Amazing, incredible." Democratization (cf. Printing Press Software Democratization). Quality is not the point; access is.
• Agentic engineering — ceiling up, quality held. You keep the responsibilities of professional software (security, correctness, maintainability) and use agents to go faster without dropping below that bar. "Doing that well and correctly is the realm of agentic engineering."

These are different activities, not points on one line. One lowers the entry cost; the other raises the output ceiling for people who already clear the bar.

"10x is not the speedup"#

Karpathy explicitly retires the old "10x engineer" trope as too small: "10x is not the speedup you gain… people who are very good at this peak a lot more than 10x." The ceiling on agentic-engineering capability is very high, and the spread between mediocre and AI-native practitioners widens, not narrows. (Echoes Harness Shrinkage as Models Improve: the leverage keeps growing as models improve; the binding constraint becomes the operator's taste — see Outsource Your Thinking, Not Your Understanding.)

What an AI-native practitioner looks like#

Asked to contrast a mediocre vs. a fully AI-native user of cloud code / codex / open claw, Karpathy's answer is mundane and important: invest in your setup, use all the tool's features. Same as the engineers who got the most out of Vim or VS Code — now applied to Claude Code / Codex. Mastery is configuration-and-features fluency, not a secret prompt.

Hiring has to be refactored#

A practical corollary: most teams still hire with the old paradigm (puzzles, leetcode). Karpathy argues agentic-engineering hiring should look like "give me a really big project and watch someone implement it well" — e.g., build a secure Twitter-clone-for-agents, then a red-team agent ("codex 5.4 xhigh") tries to break it and can't. Hiring should test verifiable, end-to-end build-and-defend ability, not isolated puzzle-solving. (See The Verifiability Thesis for why "and it can't be broken" is the load-bearing half.)

The human residue#

Even at the high ceiling, the human stays in charge of spec, taste, judgment, and oversight — agents do the fill-in-the-blanks. His MenuGen war story: the agent matched Stripe and Google accounts by email address instead of a persistent user ID — "such a weird thing to do," the kind of mistake Jagged Intelligence (Ghosts, Not Animals) predicts. You must design the spec ("these must be unique user IDs we tie everything to") and supply the taste; the agent handles the API details you've stopped memorizing.

The veteran's failure mode: over-specification (Cherny)#

Boris Cherny names the characteristic mistake of experienced engineers with modern models (YC interview, July 2026, practitioner-opinion): "way over-specific instructions… you must do one, then two, then three, then four. And for modern models, that's actually really not the way to do it." The correction: go a level higher — describe the task, the guardrails, and the exit criteria, then "let the model cook." He frames it as an unlearning problem: decades of building deterministic systems trained engineers to over-specify, and "when I look at engineers that have been coding for decades, this is a really really common failure mode… it's a journey to unlearn it" — treat the model "like you would a coworker. That's the level of intelligence that it's at now." This is the same operator-skill axis as Karpathy's mediocre-vs-AI-native spread, but with the sign flipped: what widens the gap isn't tool fluency alone, it's willingness to drop priors that used to be professionalism. (The advice is model-generation-indexed: "this is just not something that would have worked 6 months ago, but it does work today" — the delegation level itself is a shrinking-harness dial.)

The moving goalposts: supervised vs. unsupervised (Ambrosino)#

Andrew Ambrosino (OpenAI Codex) restates the same "which bar moves" distinction as a moving-goalposts observation, and welcomes the movement as evidence of progress. Asked what fraction of the product is AI-written: "If you use the goalposts from last year, 100% of our product is AI-written code. So the question is more like — is the code written supervised versus unsupervised? That's a totally different thing. I welcome the moving of goalposts, because that means we're making progress." The salient axis is no longer human-vs-AI authorship (settled) but how much human supervision the authoring still needs — which is exactly the agentic-engineering "quality bar held while going faster" line, measured as supervision cost.

He also captures the interactive form as "coding is steering the AI": the honest measure of AI's contribution isn't "what percent of my code did AI write" but "how many times did I have to steer it in the right direction" — the allocator/steerer role, restated. And on the frontier: "loops are so last week." The leading edge has moved past orchestrated loops to autonomous development and harness engineering — e.g. an agent doing overnight "garbage collection" of the codebase — though he flags it isn't there yet (models "usually increase complexity" and are bad at deleting code). This dates the vibe-coding→agentic-engineering ladder from the OpenAI side: the practitioner question is now supervised-vs-unsupervised and how autonomous a loop you can trust, not can the model write it.

The dissent from the craft side: DHH rejects the vocabulary and redraws the line#

DHH — twenty years of handcrafted Ruby, now shipping 100% agent-written code — engages this page's framing directly on Lex Fridman #501 (2026-08-26, practitioner-opinion) and rejects half of it.

On the term. "Agentic engineering — oh, I fucking hate that term… first of all, it's become marketing slop speak at this point. Like, it's just slapped onto everything. I wish we had a different word that just meant AI doing stuff." He is no happier with the other one: vibe coding "smells exactly like script kiddies did in the early 2000s. People applying PHP scripts they just downloaded offline that they don't understand anything of."

On the line itself — a different cut. Karpathy's split is about which bar moves (floor vs. ceiling). DHH's is about implementation visibility, and it is sharper because it is binary: "vibe coding, if we define it here, is you tell an agent to build software for you. You do not look at the implementation. That, to me, is what separates vibe coding from programming or, let's say, agent-accelerated development." He refuses to let the result be called programming, on the grounds that programming names an understanding of primitives — loops, conditions, variables — not the production of programs: "you could say in the pre-agentic era, well, your CEO is programming… I don't think most people would call that CEO a programmer." He then classifies his own work under both labels at once: he vibe-coded Omawrite (a C++/Qt Markdown editor he has never read a line of, deliberately, "100% a black box") while still reviewing the shape of everything in Omarchy's model layer.

On expertise as a liability. The page's implicit assumption — that the AI-native practitioner is the strong engineer who invested in setup — takes its most direct hit here. Asked whether there are problems where programmers do worse than non-programmers at this, DHH says "100%." His reasoning: "there's a lot of programmers who are not very good product managers. Software is product management. What should it do? Who should it do it for?… And in the agentic era where you are letting an agent do the implementation, these are the skills you need." He reports it as autobiography, not theory: "I actually think for a while it was to my deficit to know as much as I know about programming, because I was instructing the agents to do things as I prescribed them to do… the next moment allowed anyone to describe outcomes and get better solutions than if you had a programmer prescribe the path." Set this against Returns to Expertise in Agentic Coding, which measures the opposite sign — domain expertise doubles verified success — and the reconciliation is that DHH is describing implementation expertise misapplied as prescription, while the Anthropic study measures domain expertise applied as context.

Corroborating Cherny's over-specification finding, from outside Anthropic. DHH cites the 80% system-prompt cut by name — "one of the things that Boris, working on Claude Code, shared… was that the system prompt that they ship for Opus 5 shrunk by 80% because the agent not only needed far less human instruction, it was actually being damaged by overly prescriptive humans" — and supplies the analogy that makes it stick: "any programmer who's had a pointy-haired boss knows exactly what that is like… You write shittier code if you're mandated to do things that are against your better judgment. Why would an agent not be the same?" See Harness Shrinkage as Models Improve.

And an older lineage for it. His positive prescription is not "prompt better," it is the agile argument transplanted: specification-up-front failed for forty years because "no one knows what they want until they receive it. You don't know what a program should do until you play with it. So in the agentic age, you should resist the temptation to be overly specific upfront. Be as vague as you can to manifest something, then interact with the something." The human contribution he names is differential evaluation — give a person three options and the gut answers instantly; give them twenty-two and they fall off a cliff. That is a concrete shape for the "taste" the rest of this page treats as a primitive.

Connections#

• Spec-Driven Development as the New Waterfall — the other definitional quarrel in the same space: Matt Pocock proposes persistence as the line between prompting and spec-driven development, and Robert C. Martin answers it by refusing to persist a spec at all

• Is Persistence the Line Between Prompting and Spec-Driven Development? — settles that neighbouring quarrel against persistence and puts DHH's line beside it: both are attempts to buy an observable test (is it in the repo? did you read the implementation?) for a property that is really a disposition

• DHH (David Heinemeier Hansson) — the craft-side dissent: hates both terms, cuts the line at implementation visibility, and reports his own programming expertise as a temporary liability

• The Code-Quality Payoff Is Token-Indexed — DHH's underlying economics: the quality bar agentic engineering is supposed to preserve was justified by cheap human modification, and he argues that premise expired

• Open Source Under Agent Contributions — the contributor-side case: a plugin author who never reads the C++ is vibe coding by DHH's own definition, and the maintainer welcomes it

• Building Is Cheap, Arguing Is Expensive — cheap generation is what lets prototypes settle technical debates

• Andrej Karpathy — coined both terms

• Software 3.0 — the paradigm both activities operate in

• Jagged Intelligence (Ghosts, Not Animals) — why agentic engineering needs human oversight: agents make weird, spiky mistakes

• The Verifiability Thesis — the discipline leans on verifiable build-and-defend tasks

• Outsource Your Thinking, Not Your Understanding — taste/judgment/spec is the residual human bottleneck the discipline turns on

• Harness Shrinkage as Models Improve — the ">10x and widening" leverage curve as models improve

• Printing Press Software Democratization — the floor-raising half is the same democratization Boris Cherny describes

• Claude Code Best Practices — concrete agentic-engineering practice (explore→plan→code, verification-driven)

• Verification as the New Bottleneck — Fiona Fung's org-level account of "preserve the quality bar while going faster"

• Claude Code — the surface where this plays out

• Acceleration Whiplash — the dark mirror: Faros AI's industry telemetry of what the quality bar does when orgs don't practice agentic engineering — it drops (bugs/dev +54%, incidents per PR +242.7%)

• AI as Primary Author — "you're still responsible for your software" is the responsibility half of the authorship/accountability gap Faros documents at scale

• Returns to Expertise in Agentic Coding — the two-bars thesis, measured: Anthropic's 400K-session study finds occupation barely matters (the floor rose — anyone within 7pp of a software engineer) while domain expertise still decides success (the bar held)

• Andrew Ambrosino — the OpenAI-side "supervised vs. unsupervised" / "coding is steering" / "loops are so last week" restatement

• Compute Allocator — "coding is steering the AI" is the allocator role: measure the steers, not the lines

• Agentic Technical Debt — the barrier to fully-unsupervised loops Ambrosino names: models increase complexity and are bad at deleting code

• The Three Loops of AI-Native Building — Andrew Ng published a loop taxonomy the same week Ambrosino said "loops are so last week"; they disagree only if you conflate the harness-loop (absorbed by capability) with the product-loops (structural, and unshortened)

• Prototype Fidelity After Cheap Polish — the HCI field's read on the same practice: vibe coding as "a distinct professional skill sitting between design and development" that should be taught, with the floor/bar distinction this page draws still missing from that proposal

Open Questions#

• Karpathy hints at "one domain that's very [valuable]" for founders but won't say which (didn't want to "vague-post on stage"). What verifiable RL-environment domain is he gesturing at?
• If the mediocre/AI-native spread keeps widening, what does that do to team composition — a few extreme outliers plus agents, vs. broad mid-level staffing?

Sources#

• Andrej Karpathy: From Vibe Coding to Agentic Engineering
• OpenAI Codex lead on the new shape of product work — Ambrosino: "supervised versus unsupervised"; "coding is steering the AI"; "loops are so last week"
• Thread by @AndrewYNg — Andrew Ng, The Batch (2026-06-30), practitioner-opinion: a three-loop taxonomy published the same week as "loops are so last week"
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny, YC interview (2026-07-27, practitioner-opinion): over-specification as the veteran failure mode; task/guardrails/exit-criteria over step lists
• DHH: Future of Programming, AI, Agentic Engineering, Vibe Coding & Linux | Lex Fridman Podcast #501 — DHH, Lex Fridman #501 (2026-08-26, practitioner-opinion): rejects both terms; defines vibe coding by implementation visibility; "software is product management"; programmers can be worse than non-programmers; independent corroboration of the over-specification finding