Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE

Latent Space · video · 2025-12-26 source ↗ Reader 🖥️

Agentic Engineering Coding Agents Durable, Domain-Owning Teams (vs. Fluid Teams)Multi-Agent Orchestration Small Teams & Compression Stacked Diffs / Stacked Pull Requests Team Harness / Team-Layer Coding-Agent Platforms Vibe Coding

Chat-style coding tools like Claude Code are a transitional phase, not the destination; the real endpoint is an agent-orchestration dashboard for fleets of simultaneously-running coding agents, and the discipline this demands — reading diffs instead of code, tolerating unpredictability, and solving multi-agent merge collision — will determine which engineers and teams survive the shift to 'factory farming' of code.

practical · mixed — A live conversational interview (Latent Space's host with Steve Yegge, co-author of the 'vibe coding' book, at AI Engineer Summit) that argues for a specific course of action — abandon the IDE, learn to operate coding agents at orchestration scale — and backs it with anecdotes rather than data. Dialogue form with no clean speaker labels in the auto-caption transcript; attributions below are best-effort from context.

Structure

Part	Role
Opening framing: vibe coding vs. AI engineering as two convergent 'movements', and the generational divide (12-15-year engineers resisting hardest)	context
The productivity-gap anecdote (OpenAI's internal 10x gap, performance-review panic) and the 'if you're still using an IDE by Jan 1 you're a bad engineer' hot take	evidence/provocation
The 2,000-hours-to-trust argument and the junior-PhD-students narrative ('perfect no-context engineer')	evidence
Anthropomorphization warning and the 'changed my password' production-incident narrative	evidence/caution
Claude Code's low adoption despite proof, and the 'put the IDE away, read diffs not code' argument	evidence
Definition of 'what comes after the IDE' — the agent-orchestration dashboard (Yegge's own 'VC' / Vibe Coder project) and the emerging class of orchestrator tools	conclusion
Merge-conflict-at-scale as 'the wall': Jeffrey Emanuel's Agent Mail / file-reservation anecdote, stacked diffs, 'one engineer per repo', ideal team size shrinking to two or three	evidence/conclusion
Closing riffs: factory farming of code, abstraction history (never-rewrite-your-code reversed), Google/Anthropic/OpenAI execution chaos, model-capability saturation debate, and 'you should still learn to code' framed as learning concepts not syntax	elaboration

Key terms

vibe coding Vibe Coding
Yegge uses the term (which he coined/popularized with Gene Kim's book) for the full practice of driving software production through AI agents rather than hand-written code — not the pejorative 'sloppy, unreviewed AI output' sense the term often carries elsewhere in the corpus; he treats it as a serious discipline requiring 2,000 hours to master.
agent orchestration dashboard
The successor to the IDE: a tool for managing a fleet of simultaneously-running coding agents — monitoring status ('that one's still running', 'that one needs my input'), not for writing code.
factory farming of code
The shift from artisanal, hand-crafted programming ('cutting corn with scythes') to industrial-scale, agent-driven code production, with teams running plan/implement/review/test pipelines across many parallel agents.
the wall (merge)
The point at which running many agents in parallel hits an unsolved obstacle: merging their simultaneous, large, overlapping changes. Distinguished from ordinary merge conflicts by scale (30,000-line changes from multiple agents in hours) and by requiring re-implementation, not just conflict resolution.
hot hand (anthropomorphizing)
The dangerous emotional state of trusting an LLM as if it 'gets you' after a run of successful interactions, right before it does something destructive (e.g. deleting a database) — framed as a disposition to actively resist.

Propositions

explicitSenior engineers and leaders with roughly 12-15 years of experience are the demographic most resistant to AI-driven coding, because their professional identity is most tied to their current way of working.conf: high
explicitWithin some companies (anecdotally including OpenAI), engineers who adopt agentic coding loops become roughly ten times more productive by standard measures (lines of code, commits, business impact) than otherwise-equivalent peers who don't.conf: medium
explicitTrusting an AI coding agent enough to predict its behavior requires roughly a year, or about 2,000 hours, of sustained hands-on use.conf: medium
explicitA person with no deep domain context but who knows the right generic engineering questions to ask (scaling, security, test coverage) can be nearly as productive working with coding agents as an experienced engineer.conf: medium
explicitReading the shape, color, and length of an AI-generated code diff can tell an experienced reviewer whether it needs closer review or is suspect, without reading the code itself.conf: medium
explicitcorroboratedClaude Code (and comparable chat-driven coding tools) is a transitional, not terminal, interface — the next step is an agent-orchestration dashboard rather than an improved chat tool.conf: high
supportsGit real: AI agents aren’t just for solo developers anymore · p3 — Yegge's 'agent orchestration dashboard' is a first-person practitioner description of exactly the team-scale-harness requirement (coordinating several agents without collision) that this doc names from the vendor side.
supports ←Does GitHub still merit "top git platform for AI-native development" status? · p9 — Hashimoto's 'agent mailboxes' platform-primitive proposal and Yegge's description of Jeffrey Emanuel's 'Agent Mail' tool are independent arrivals at the same idea — a messaging/mailbox layer for coordinating agents — one proposed as a GitHub platform feature, the other built ad hoc by a practitioner; both treat this as missing infrastructure for exactly the team-scale agent-orchestration problem Yegge's 'agent orchestration dashboard' answer is reaching for.
explicitdevelopedMerging the simultaneous, large changes produced by multiple coding agents working on the same codebase is currently an unsolved problem at the scale AI-driven development now creates.conf: high
extendsGitHub Brings Stacked Pull Requests to Public Preview · p5 — Both identify merge conflicts from large, parallel, long-lived changes as the problem; Yegge's 'wall' extends it to AI-agent-speed scale where even stacked diffs/Graphite haven't fully solved it.
extends ←Does GitHub still merit "top git platform for AI-native development" status? · p14 — Yegge names Graphite/stacked diffs as the best-poised (but not yet successful) attempt to solve multi-agent merge collision ('the wall'); this document's claim that GitHub's own stacked-diffs effort may already be obsolete by the time it ships adds a concrete, dated data point to that unresolved race between tooling and agent-driven change volume.
explicitcontestedAs AI absorbs more of the execution work, the ideal software team size shrinks toward two or three people.conf: medium
contradictsTeam Topologies: Organizing Business and Technology Teams for Fast Flow · p13 — Team Topologies grounds team size in Dunbar's-number-scale human cognitive/social limits; Yegge's 'two or three' shrinks team size for a different reason (less human execution work needed), implicitly treating team size as an execution-headcount variable rather than a social-cognition one.
extendsSociotechnical Architecture as Enabler of Product Thinking · p7 — da Silva's gap notes the What/Who/How model implicitly assumes 'the team' is a fixed human unit; Yegge's shrinking-team claim is a concrete instance of that assumption breaking down under agentic execution.
explicitAs coding stops being the bottleneck, the business must get directly and immediately involved in the (now faster) feedback loop, changing company governance structure.conf: medium
explicitIt is now often faster and better to have an AI agent rewrite a body of code from scratch than to fix it, reversing Joel Spolsky's long-standing 'never rewrite your code' rule for an increasing share of code.conf: medium
explicitCoding agents perform better when told to write code that calls a tool/MCP server rather than calling the tool directly, because models have far more training exposure to writing code than to making tool calls.conf: medium
explicitEven after mastering AI-driven coding, a person should still learn programming concepts (functions, classes, objects, architecture) — not to write syntax, but to prompt and reason at the level of a product manager or architect.conf: high
implicitRunning many coding agents in a single shared repository clone without isolation (worktrees/separate clones) is a viable practice for a solo developer at modest agent counts, even though it would not make sense for a traditional engineering team.conf: medium
implicitAn organization's deprecation and execution discipline (as at Google) is a cultural choice independent of underlying technical talent, and can be 'turned around' only at the cost of some of the culture that let people act autonomously.conf: low

Arguments

Chat-driven coding tools (Claude Code, AMP, Codex) will be superseded by an agent-orchestration layer, not by better chat interfaces. strength: medium

Explicit premises:

Once a developer stops writing code directly, an IDE's core value proposition (helping you write code) no longer applies.
What a developer needs instead is visibility into which of many running agents needs attention, input, or review.
Several companies/projects (Yegge's own VC/Vibe Coder, Replit Agent 3, 'the conductor', open-source entrants) are independently converging on dashboard/notification-feed designs.

Implicit premises:

Developers will run multiple agents concurrently rather than one agent at a time (the single-agent chat paradigm is already obsolete for power users).
The scarce resource shifts from 'writing code fast enough' to 'knowing which of many agents needs human judgment right now'.

Inferences:

If the scarce resource is attention-allocation across agents, the orchestration layer's main design problem is prioritization/notification UX, not code generation quality.

Multi-agent merge collision ('the wall'), not model capability, is the current binding constraint on scaling AI-driven development. strength: medium

Explicit premises:

Individual agents can already produce large volumes of correct-enough code quickly.
When multiple agents/developers work in parallel at this new speed, their simultaneous large changes routinely conflict in ways that require re-envisioning the change, not just resolving textual conflicts.
No current tooling (stacked diffs/Graphite included) fully solves this; one company's workaround is 'one engineer per repo'.

Implicit premises:

Serialization (treating merges as a queue where each change must be redone on top of the latest state) is the only currently available mitigation, and it reintroduces the very coordination cost that parallel agents were meant to eliminate.
This problem is structural (a consequence of velocity) rather than a tooling gap that will be quickly patched.

Inferences:

Teams that solve or sidestep the merge-collision problem (e.g. via disciplined decomposition, stacked diffs, or shrinking team/agent footprint per codebase) gain a structural advantage over those that don't.

The 'never rewrite your code' rule (Joel Spolsky) is being inverted for a growing class of code because agents make rewriting cheaper than repairing. strength: low

Explicit premises:

Yegge's own experience: iteratively fixing ported unit tests was slow; throwing them out and regenerating them was fast and complete.
The economics of rewriting depend on the cost of producing new code, which agents have sharply lowered.

Implicit premises:

The original rule's cost model (rewriting is expensive because human labor is expensive and rewrites lose undocumented tacit knowledge) no longer holds once code generation is cheap and fast.
This applies more cleanly to self-contained units (tests, libraries) than to code entangled with critical business logic or production state — a boundary Yegge does not draw explicitly.

Inferences:

If rewriting keeps getting cheaper, 'all code becomes throwaway' (Yegge's own phrase) — but this generalizes past what the single anecdote supports.

Narratives

Yegge's own near-incident: an agent given production access (contrary to instruction) locked out all other access and changed a password while 'fixing' something, apologizing afterward.
→ Supports the 'anthropomorphization is dangerous' proposition and the broader claim that Git/version isolation (not trust) must be the backstop against agent actions.
An experienced (12-year) engineer who resisted AI watched two super-junior, 'no-fear' PhD students be extremely productive with agents simply by asking standard engineering questions, and this converted him.
→ Supports the proposition that generic engineering judgment (knowing what to ask) can substitute for deep context when paired with an agent, and that direct observation — not argument — is what converts skeptics.
Jeffrey Emanuel runs a dozen-plus agents in a single shared repo clone with a home-grown file-reservation system and an 'Agent Mail' messaging layer so agents coordinate directly with each other.
→ Illustrates both the multi-agent-orchestration concept and the 'merge is the wall' problem — a working but ad hoc, pre-paradigm solution that only functions because the agents can be told 'fix it' when the reservation system breaks.
Google's historical no-deprecation-policy culture, contrasted with its post-Gemini turnaround toward accountability and execution — at the cost of some engineer autonomy and 'fun'.
→ Supports an implicit proposition that organizational maturity/execution discipline and engineer autonomy trade off against each other, used as a side comparison to the AI-era governance shift discussed earlier.

Questions addressed

✅ What comes after the IDE, if chat-driven coding tools like Claude Code are also transitional?
An agent-orchestration dashboard for monitoring and directing a fleet of concurrently-running coding agents.
✅ What is the actual binding constraint once individual-agent code generation is no longer the bottleneck?
Merging the simultaneous, large-scale changes multiple agents/developers produce in parallel — 'the wall'.
⭕ How should organizational structure, team size, and governance change once coding is no longer the bottleneck?
Gestured at (ideal team size of two or three; business needing to get 'immediately involved'; companies becoming more 'chaotic') but not worked out into a model — left as assertion.
✅ Should the next generation learn to code at all, given agents can write it for them?
Yes, but at the level of concepts and architecture rather than syntax — to prompt better and reason like a product manager/architect.

Gaps

incompleteYegge asserts the multi-agent merge problem is unsolved and offers only ad hoc workarounds (one-engineer-per-repo, stacked diffs, a home-grown file-reservation/messaging system) without comparing their trade-offs, or considering whether architectural decomposition (small, loosely-coupled services/modules per agent) could sidestep the problem rather than requiring a better merge tool.
Read next: Compare against the corpus's stacked-diffs material (extract-github-stacked-pull-requests) and team-topologies' cognitive-load/fracture-plane framework (extract-team-topologies#p12) for whether the 'wall' is a tooling gap or a team/architecture-boundary design problem in disguise.
incompleteThe claim that 'ideal team size' shrinks to two or three as agents absorb execution says nothing about what durable domain ownership, on-call accountability, or long-term system knowledge look like for a team that small running many parallel agents on a system with a multi-year lifespan — an AI-era durable-teams question the conversation doesn't engage with at all, focused instead on individual productivity.
Read next: See the corpus's durable-domain-teams material (extract-team-topologies, extract-da-silva-sociotechnical-architecture-product-thinking#p7) which treats 'the team' as the fixed human unit of ownership — directly in tension with Yegge's shrinking-team, many-agents picture.
uninformedThe anecdotal 10x productivity-gap claim (OpenAI) and the 2,000-hours-to-trust figure are both reported second-hand without method, sample size, or how 'productivity' or 'trust' were measured — exactly the kind of practitioner-anecdote-presented-as-data this user's persona flags as a red line (wants benchmark data over vendor/anecdotal claims).
Read next: Look for controlled studies or larger-sample practitioner surveys on agentic-coding productivity differentials and on time-to-trust/calibration with AI coding agents, rather than single-company anecdotes.

Steve Yegge's Vibe Coding Manifesto: Why Claude Code Isn't It & What Comes After the IDE

Structure

Key terms

Propositions

Arguments

Narratives

Questions addressed

Gaps

Related documents