Vibe-engineering

Vibe-engineering is the practice named by Josh Bleecher Snyder in claude-is-not-a-compiler: the engineer keeps the decisions, and the agent's job is to make those decisions faster, better-informed, and available at every layer at once. It contrasts with vibe-coding, where the decisions themselves go to the agent.

The boundary

The test is not how much code you read. Both practices involve reading very little. The test is where the judgment lives.

Claude wasn't just a compiler here. I never handed off a task and let an agent make a bunch of decisions in order to reduce it to practice. That's vibe-coding. Rather, Claude was a vertically integrated resource, a multi-compiler.

Vibe-coding is a handoff: here's the goal, come back with something that works, whatever you decided along the way is fine. Vibe-engineering keeps the engineer in the decision seat and uses the agent for the things that used to make decision-making expensive — research, exploring alternatives, surfacing failure modes, and producing candidate implementations you can compare.

There's a second-order piece that does more work than it looks: the engineer also decides which decisions matter. Most individual lines don't make that cut. A vibe-engineered system has a small set of intentional, recorded decisions and a large volume of code nobody deliberated over, which is a different shape from both traditional engineering (deliberate most of it) and vibe-coding (deliberate none of it).

Why "vertical" is the operative word

The compiler framing slotted the agent into one layer of the stack, between engineer and compiler, translating natural language into code. That framing understates it, because the real gain is that a model will talk strategy, product, architecture, code, and machine code without organizational overhead. Human organizations struggle to work across layers not from ignorance alone but from meeting cost, permission, and information hiding — the very things that let them scale. An agent has none of those, so cross-layer consultation that would need a scheduled meeting becomes a prompt.

That reframes the value proposition. Under the compiler model, an agent's worth is reliability times the size of the decisions it absorbs. Under this one, its worth is how much of the stack it can hold at once while you keep deciding.

What the practice looks like

From the DNS-server case in claude-is-not-a-compiler, the recurring shape:

• Humans settle the highest-level strategic and architectural calls directly, in person, before agents start.
• The agent is used first as a researcher — standard designs, domain internals, historical security failures, rejected alternatives, failure modes, testing strategy.
• Implementation is built several times concurrently and the results are diffed for divergence (differential-spec-analysis). Divergences are where the unasked decisions hide.
• Answers get distilled into terse written guidance as they're settled — a scar-tissue document that accumulates across iterations and is what actually survives.
• Verification is operational, not line-by-line: tests, end-to-end tests, shadow mode before production rollout.

The claim to understanding that comes out is specific. Hand-editing the code would mean a real learning curve. Reasoning about the system, answering colleagues' "what happens in condition Y", and steering future agent work are all intact. Whether that's sufficient understanding is the live disagreement — see below.

The scar-tissue document

The durable output isn't the code, it's the accumulated guidance. Written terse, for agents as much as humans, recording the decisions important enough to record across all layers, and expected to outlive bug fixes and code churn. In the DNS case it was rebuilt through three full iterations before it was empirically sufficient to walk an agent through the decisions that mattered.

This is the same instinct as the numbered acceptance criteria in acceptance-criteria-ids and the spec-as-primary-artifact argument in specsmaxxing, arrived at from the opposite direction: not "write the spec first" but "let the spec precipitate out of the decisions you found yourself making."

Where it's contested

The obvious objection is that this is vibe-coding with better branding, and the honest answer is that the distinction depends on a claim only the practitioner can verify — that they really did make the decisions. From the outside, "I read a vanishingly small amount of the code" looks identical in both cases. That's the same unobservable-effort problem as agent-principal-agent-problem and credibility-as-slop-test, now applied to the engineer's own account of their work.

Against it directly: reviewing-ai-code argues review throughput caps how much agent output can be responsibly shipped at all, and cult-of-vibe-coding treats not-reading-the-code as the failure mode rather than the method. peril-of-laziness-lost supplies the mechanism they'd both point at — human time constraints used to force simplicity, and vibe-engineering removes that constraint while claiming the judgment survives it.

Adjacent but different: control-the-ideas-not-the-code shares the conclusion (own the design, skip the lines) but gets its confidence by interrogating one model about its design, where vibe-engineering gets it by building several times and comparing. danluu-ai-coding-testing is the third route — testing heavy enough that review becomes unnecessary.

Bleecher Snyder's own prediction is that the argument expires: "in the near future, vibe-engineering is just…engineering."

Cross-references

• claude-is-not-a-compiler — the source and the worked example
• differential-spec-analysis — the method that makes the unasked decisions visible
• cult-of-vibe-coding, simonw-vibe-coding-agentic — vibe-coding proper
• agent-principal-agent-problem — the review collapse this operates inside
• specsmaxxing, acceptance-criteria-ids — the spec-as-artifact family