- Home
- The Thinking Wire
- Karpathy Retired Vibe Coding. The Replacement Is Product Management.
Karpathy Retired Vibe Coding. The Replacement Is Product Management.
Andrej Karpathy coined “vibe coding” in early 2025. In May 2026, per Jeff Gothelf’s reporting, he declared the term obsolete and replaced it with a list of activities that any honest product leader recognizes on sight.
That recognition is the story.
The List Karpathy Used to Retire His Own Term
As Gothelf reconstructs the list, Karpathy describes what agentic engineering actually requires: writing design specs, supervising plans, inspecting diffs, writing tests, building evaluation loops, managing permissions, preserving quality.
Read that list twice. Notice what is not on it. Typing code. Memorizing syntax. Picking a framework. Configuring a build tool. The activities that defined “developer” in 2015 are absent. The activities that defined “product manager” are not.
Gothelf draws the parallel directly. Every item on Karpathy’s list maps to a classic PM activity: problem definition, prioritization, outcome validation, success metrics, scope alignment, quality judgment. The vocabulary changed. The job did not.
Why This Is the Admission That Matters
For two years the conversation about AI-assisted development has been an engineering conversation. How many seats of Cursor. Which model. Which agent loop. Which IDE. The implicit assumption: this is a tools problem, solved by engineering procurement and engineering training.
Karpathy’s retirement of his own term punctures that assumption. The judgment work was never the engineering bottleneck. It was the PM bottleneck disguised as one.
When a developer accepts a bad AI suggestion and ships it, the failure was not that the model hallucinated. The failure was that nobody wrote a sharp enough spec to make the hallucination obvious. When an agent runs a dangerous command, the failure was not the agent. It was the missing permission boundary. When an evaluation loop produces nothing useful, the failure was not the loop. It was the absence of a success metric anyone agreed on.
Each of those is a PM activity. None of them are cured by buying more Claude seats.
The Quote That Should Be on Every CTO’s Wall
Gothelf’s sharpest line lands here. “The admin version of every one of those activities is now automatable, and it will be automated. The judgment version is the job.”
The admin version of writing a spec is filling in a template. The judgment version is knowing what the customer cannot articulate yet. The admin version of inspecting a diff is reading the file. The judgment version is knowing which 200 lines of refactor are net positive and which are a regression dressed in clean code. The admin version of an evaluation loop is wiring it up. The judgment version is picking the right metric to measure.
The first column is being eaten by agents on a quarterly cadence. The second column is what remains. Karpathy is, in effect, telling engineering leaders that they have been staffing the first column and ignoring the second.
What Organizations Are Doing Wrong Right Now
Three patterns we see repeatedly in 2026:
Engineering teams adding AI capacity without PM capacity. A 40-person engineering org wires up Claude Code, sees a 25% throughput lift on first measurement, and decides the bottleneck is now “more AI tooling.” Six months later, the throughput lift has flattened. Investigation reveals the missing piece is not more tooling. It is that the same five product managers are now bottlenecking twice the engineering output, and the specs they write have not adapted to a world where the executor reads them literally.
PMs treated as ticket-writers, not spec-writers. In most companies, the PM job degraded over the last decade into stakeholder management, ticket triage, and roadmap theater. The actual product thinking, the customer judgment, the trade-off articulation, got squeezed out. AI agents expose this immediately. An agent fed a ticket like “improve the onboarding flow” will produce something. Whether that something is right requires the judgment work that PMs have been increasingly absolved of doing.
“AI-assisted developer” as a job title, with no equivalent for product. Job boards in May 2026 are full of “AI-augmented engineer” and “agentic engineer” titles. The corresponding product role does not exist with the same crispness. The market is still recruiting executors for an environment where execution is increasingly automated, and underfunding the judgment roles for an environment where judgment is the binding constraint.
What to Do Monday
Audit your spec quality before you audit your model selection. Pull the last ten specs your team handed to AI agents. Ask: would a smart but literal junior, with no context about your product, build the right thing from this? If the answer is no, the bottleneck is upstream of the model. No tooling change will fix it.
Move judgment work earlier in the cycle. If a PM gets involved at the acceptance-testing stage, you have already paid for the engineering iteration. With agents producing code in minutes, that iteration cost approaches zero, which means the judgment cost dominates. PMs need to be in the room when the spec is written, not when the PR is reviewed.
Reframe AI-assisted development as a product staffing question. Stop asking “do we have enough AI-fluent engineers?” Start asking “do we have enough people who can articulate the right problem clearly enough for an agent to solve?” These are different questions, with different answers, and the second one is the one that determines outcomes.
Stop hiring PMs who cannot read a diff. The judgment version of “inspecting diffs” requires technical literacy. A PM who has never read code cannot evaluate whether the agent’s refactor is correct, only whether the demo looks right. In a world where the demo always looks right, that is no longer enough.
Build the evaluation loop as a product artifact, not an engineering one. Evaluation criteria for AI output are product decisions. What “good” looks like, what acceptance thresholds apply, what counts as regression, these are not technical questions. They are product questions wearing technical clothing. Treat them accordingly.
The reframe Karpathy is forcing is uncomfortable for organizations that spent the last two years convincing themselves the AI shift was a procurement and training problem in engineering. It was not. It was a product discipline problem all along. The tools just made it impossible to keep ignoring.
The companies that staff for that reality now will compound. The ones still hiring more executors for an environment where execution is free will spend 2027 wondering why their AI investment did not produce the returns the deck promised.
This analysis synthesizes Karpathy Said Vibe Coding Is Obsolete. What He Described Instead Is Product Management. by Jeff Gothelf (May 2026).
Victorino Group helps leadership teams reframe AI-assisted development as a PM staffing problem, building the spec-writing, outcome-validation, and judgment discipline that determines whether the agentic stack actually produces value. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation