Vibe coding, honestly: what changes when the agent writes the code

"Vibe coding," describing the intent and letting the agent produce the code while you review the outcome instead of the keystrokes, gets written about in two registers: breathless ("you'll never write code again") and dismissive ("it's autocomplete cosplay"). Both are wrong. It's a genuine shift in what a unit of work is, wrapped around a set of failure modes nobody puts on the slide. Here's the honest version.

What actually changes

• The unit of work moves up. You stop thinking in lines and start thinking in tasks and pull requests. Your job becomes specification and review: directing, not typing. On well-specified, well-tested work, the throughput change is real, not hype.
• The bottleneck moves to review. The agent can produce a 600-line diff faster than you can read it. The constraint on your day is no longer how fast you can write. It's how fast you can verify, a different skill, and often a harder one.
• The model becomes a commodity. This is the uncomfortable one. The frontier models are remarkably close (the benchmark shows how close), and they leapfrog monthly. What actually determines your experience isn't which model. It's the harness around it.

The model is the commodity. The harness (context management, tools, sandbox, the test loop) is the product. Teams that get this stop chasing the leaderboard and start engineering their loop.

What doesn't change

• You still own correctness. The agent's output is plausible, and plausible-wrong is more dangerous than obviously-broken, because it survives a glance. The discipline that made you a good engineer, tests as the oracle, small reviewable steps, reading the diff, matters more, not less.
• Garbage in, garbage out, amplified. A vague prompt produces confident, voluminous code that's wrong. The agent doesn't fill the gaps in your spec with judgement; it fills them with whatever's statistically likely. Specification is now the skill that matters most.
• Tests are still the ground truth. Repos with real tests get dramatically better agent results because the agent has something to check against (this is the whole thesis of the Claude Code post). No tests, no oracle.

Where it works, and where it bites

It works when the task is fenced and verifiable: a migration with a passing suite, a mechanical refactor across many files. Give it a clear goal and a way to check itself, and it delivers.

It bites when:

• The project's real truth lives somewhere the agent can't see. An undocumented deploy step, a flaky test it learns to route around, an API whose behavior contradicts its docstring.
• You let the diff get too big to reason about. A 600-line change you can't hold in your head is a liability wearing a feature's clothes.
• You confuse speed with progress. Fifteen minutes of confident work down the wrong path is fifteen minutes of debt.

The practical posture

Treat the agent like a fast, literal junior who never gets tired and never doubts itself:

• Specify like you mean it. Acceptance criteria, the files to touch, how to test. The scoping discipline that saves tokens also saves correctness.
• Keep diffs reviewable. Plan first, approve, execute in steps. A reviewed 80-line change beats a magic 600-line one.
• Invest in the harness, not the leaderboard. Good CLAUDE.md/AGENTS.md, a real sandbox, tests it can run, context discipline. That's where the wins compound.

Vibe coding is a real productivity shift, not a revolution and not a parlor trick, available only to people who keep the engineering discipline the hype tells them they can drop.

Inspired by the practical, hype-skeptical coverage at vibecoding.cz.