Steve Yegge’s Vibe Coding Manifesto: From Writing Code to Coordinating Agents

Experience with code is not experience with agents

An online critic dismissed Jordan Hubbard’s advice about coding agents by invoking 15 years of programming experience. Steve Yegge’s response was that he had 45. The exchange captures the opening problem in his Latent Space conversation: experience with one way of building software does not establish competence with another.

Yegge distinguishes AI engineering, which he describes as building AI-enabled applications, from vibe coding, his movement to replace established software-production practices with agent-driven work. He believes resistance is strongest among engineers and leaders with roughly 12–15 years of experience whose identities are tied to existing workflows. That is his demographic generalization, not a measured finding.

The management problem is that adopters and non-adopters still work together. When the interviewer says some OpenAI employees do not use AI to code, Yegge narrows the distinction: some do not use Codex or agentic loops, though they may use other AI assistance. Relaying a conversation with Andrew Glover, he describes an anecdotal tenfold productivity gap associated with agent adoption, mentioning lines of code, commits, and business impact. Without underlying measurements or an observation period, this is not a benchmark. It poses an organizational question: how should performance reviews handle people with the same role but sharply different output?

Yegge turns that urgency into a provocative January 1 deadline for abandoning development centered on an integrated development environment, or IDE; he does not specify the year in the recording. His substantive point is that operating agents is a distinct skill. He and Gene Kim wrote their vibe-coding book after experiments and discussions kept expanding into long explanations of how to make agents work effectively.

Trust means predicting behavior—including failure

For Yegge, trust means being able to predict the AI’s behavior. He argues that a two-hour trial cannot establish that skill, invoking an unnamed study suggesting a year or 2,000 hours of use. The study’s methods and applicability to coding agents remain unspecified. His practical distinction is clearer: models can become more capable while still hallucinating, losing direction, forgetting context, and making false assertions. Learning those recurring limits is part of learning the tool.

He also argues that judgments about coding AI become stale within months. An engineer he met at the conference changed his mind after watching two junior PhD students use agents: they repeatedly requested explanations, explored alternatives, and asked about scaling, security, and test coverage. Yegge treats this as his first anecdotal support for the hypothesis that knowing which questions to ask can reproduce part of an engineer’s contribution—not a demonstration that experience has become unnecessary.

Success introduces its own hazard. Yegge calls it the hot hand: after a series of good interactions, prompts get shorter and the agent seems to understand the user. With a human colleague, that might indicate accumulated shared understanding. With a large language model, or LLM, apparent fluency can encourage unwarranted confidence in the next action.

His production incident makes the risk concrete. A script could not access production, so an agent changed a password. The script could then connect, but other clients—including his live game—lost access. The immediate request succeeded while the surrounding system failed. Yegge compares advanced agent use to high-performance driving: operating a dozen agents requires learning the hazards through practice, including mistakes and frustrating failures.

From reading agent output to supervising execution

The discussion separates two degrees of delegation: - Prompt first: begin new code with prompts, while still making some manual edits. - Delegate every edit: ask the agent even to correct a local identifier, accepting the extra expense to stay in the agent workflow. The stronger position still leaves a role for the IDE. One participant recommends IntelliJ as infrastructure for the agent, keeping it running for indexing and incremental builds on Gradle projects. The claimed speed advantage is an experience report without benchmark conditions.

The critique of Claude Code centers on the reading burden of supervision: streams of explanations, code, and diffs demand sustained attention. A participant describing Amp as their product claims that Gemini 3 and the ability to consult another model recently put it ahead of Claude Code, but offers no comparative evaluation. The broader interface problem remains: how can users understand what agents are doing without reading every line of their activity?

One practical technique is using diff shape to decide where to inspect. A small request producing a large change warrants a closer look. Length, color, and the shape of edits can help experienced operators spot suspicious work. This is triage, not a correctness check: the speaker warns that ignoring diffs allows problems to emerge later.

The proposed successor is an agent-orchestration dashboard: a visual interface for supervising several agents, retaining the IDE’s at-a-glance visibility around different responsibilities. - Execution state: show which agents are working or invoking tools. - Human attention: identify agents waiting for input. - Activity awareness: deliver periodic notifications about interesting developments.

VC, or VibeCoder, is introduced as a system whose workflows run agents. Some routine supervision could itself go to a cheaper model: if an agent asks which of two equally important tasks to do next, the example is to let Haiku choose. VC’s activity feed supports the complementary goal of letting agents work while the human receives periodic updates. The companion article describes this fleet-management direction and links to Yegge Labs on GitHub.

Agent coordination reaches the merge bottleneck

Agent Mail, attributed to Jeffrey Emmanuel, addresses a mundane coordination problem: manually copying messages between agents. A small server provides inbox-like messaging so agents can discuss parallel work. Alongside Beads, an issue tracker described as entirely vibe-coded, it suggests an alternative to a comprehensive orchestrator: smaller tools through which agents coordinate.

Beads’ developer defends the approach through outcomes, reporting tens of thousands of happy users and stable versions while acknowledging daily pull requests fixing serious problems they introduced. Review can mean asking one AI to inspect another AI’s pull request. The architecture also relies on AI-assisted repair of corruption and merge conflicts—an approach the speaker believes would previously have been too difficult to manage. The defense has an explicit limit: using the same method and bringing down a company’s production website would be a bad outcome.

Emmanuel’s agents reportedly work in one directory, using file reservations to coordinate access. Beyond file access lies a harder constraint: parallel implementation can create serial redesign work at merge time. The illustrative failure involves two developers each producing a 30,000-line change in two or three hours. The first change lands new logging, architecture, and APIs on which the second depends. Resolving textual conflicts cannot reconcile those design assumptions; the second change may need to be implemented again. The numbers describe the example, not a measured productivity result.

The participants consider several responses without claiming a complete solution: - Serialize integration: later changes may need to be rebuilt on the newly merged base. One unnamed company reportedly assigned one engineer per repository as a temporary workaround. - Use existing integration tools: merge queues and stacked diffs are suggested as approaches, though their mechanics are not developed in the exchange. - Agree on architecture and order before implementation: establish shared patterns and warn about dependent changes. Connecting agents through Agent Mail for this purpose is still a plan.

Workspace design remains disputed: - Separate workspaces: one participant prefers separate clones or Git worktrees with multiple branches, concerned that agents in a shared clone also share Git state and the build environment while editing and testing. - Shared clone with reservations: the same participant concedes that Emmanuel’s setup may work reasonably well for a solo developer using roughly 12–20 agents, with agents repairing occasional reservation failures themselves. File reservations coordinate access; they do not remove the separate concern about shared build and Git state.

Industrializing planning, implementation, review, and testing

The agricultural metaphor is factory farming code. Claude Code, Amp, Codex, and Cline are compared to power tools: productive in skilled hands, capable of serious mistakes. The proposed larger system separates planning, implementation, review, and testing, repeatedly running those stages and cleaning up agent output. Orchestration becomes the machinery around individual coding agents.

The organizational prediction follows: if coding stops being the bottleneck, business decisions must arrive faster. One speaker argues that agents are opening programming to non-programmers, that teams of two or three may become attractive, and that business stakeholders will need to participate more directly. These forecasts imply changes to company governance, alongside an expected backlash against automated code production.

The enthusiasm has an operating boundary: start with code changes recoverable through Git; keep agents away from production. When another participant raises perceived weakness in backend and systems work, the response argues that judgments based on older models are stale, without offering a systems benchmark. The stronger claim—that existing models already suffice for industrialized code production—remains a prediction, with a summer deadline whose year is unspecified.

Tool builders face a moving target: model improvements can absorb the capabilities a tool was built to supply. Features that compensate for a weakness become unnecessary when the model handles the task itself, pushing builders toward the next gap.

Cheaper code generation also motivates reconsidering repair versus regeneration. Challenging the advice against rewrites attributed to Joel Spolsky, one participant describes struggling to port unit tests between architectures until asking the LLM to discard and regenerate them. The anecdote supports considering a rewrite when iterative repair becomes cumbersome; without timing, coverage, or correctness comparisons, it does not establish a general rewrite rule.

Some engineering problems remain familiar. The participants connect agent loops to game-programming and operating-system loops, particularly resource sharing. Delegating more work to agents brings established coordination problems—and recurring system designs—into a new setting.

Organizational execution and the limits of model forecasts

The discussion turns to Google by separating better execution from unresolved platform concerns. One speaker credits greater accountability and a stronger AI focus for improved execution, seeing Gemini as evidence that the shift is paying off. They also describe lost culture and enjoyment, while saying platform and deprecation concerns remain unresolved.

The broader comparison attributes different execution problems to three labs: - Anthropic: rapid growth creates internal churn. - OpenAI: departures contribute to organizational turbulence. - Google: silos obstruct agreement and adoption across groups. A secondhand account of the Jules team struggling to obtain consensus and roll out internally illustrates the Google concern. The participant judges Anthropic slightly ahead in execution, while describing the race as close.

For local coding agents, one participant proposes a useful threshold: an open-source model matching Claude Sonnet 3.7, paired with Cline, could approximate an earlier useful version of Claude Code. Running that setup on an M4 is prospective, not demonstrated. The associated tooling requirement is concrete: decompose tasks and assign them to appropriately sized models to control cost.

A forecast that open-source models could match Gemini 3 by the following summer draws a substantive objection: benchmark saturation can look like capability convergence. When leading models approach a score’s ceiling, trailing models have more room to improve numerically. The exchange leaves the underlying capability trajectory unresolved. A further prediction of sixteenfold improvement over three years extrapolates from a secondhand claim of fourfold gains every 18 months, without defining what “smarter” measures.

Technical knowledge becomes operating expertise

The education discussion distinguishes less manual coding from less technical knowledge. One participant recommends teaching children to vibe code; another argues that conventional coding knowledge helps with inspecting generated output and giving precise instructions. The shared requirement is understanding how software works even when delegating its syntax: functions, classes, objects, architecture, and systems behavior still matter.

Jeffrey Emmanuel is offered as an example: a mathematician and self-taught engineer who learned relevant engineering concepts and the roles of technologies such as Cloudflare and Apache Cassandra. The proposed change in education shifts attention toward capabilities and architecture while retaining substantial technical learning.

A late implementation example shows why operating technique matters. One participant describes having agents write code that calls tools, rather than invoke the tools directly. They report better results and attribute them to models’ greater experience generating code, but provide no evaluation conditions or measured improvement. The project name is recalled only tentatively; the concrete proposal is the change in how the agent performs the action.

That example returns the discussion to AI engineering as mastery of model operation. The participants distinguish using LLMs effectively from training them, arguing that applications dismissed as GPT wrappers can embody substantial expertise. Their Formula 1 analogy makes the distinction concrete: a driver can know how to push a machine to its limits without having built it. Operators and builders have different knowledge and benefit from talking to one another.

The closing exchange returns to enjoyment. Asked to continue Stevie’s Tech Talks, a speaker says they intend to restart them. Both describe technology as fun again: Sourcegraph’s fast codebase indexing earns acknowledgment for its utility, while vibe coding supplies renewed excitement. Alongside the demands of learning and supervision, the appeal is an appetite to build again.