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

"Vibe coding" — describe the intent, let the agent produce the code, 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 can I write" but "how fast can I verify" — which is a different, and often harder, skill.
• 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, wrong, voluminous code. The agent doesn't fill the gaps in your spec with judgement; it fills them with whatever's statistically likely. Specification is now the high-leverage skill.
• 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, no trustworthy autonomy.

Where it works, and where it bites

It works when the task is fenced and verifiable: a migration with a passing suite, a well-specified feature, a mechanical refactor across many files. Give it a clear goal and a way to check itself and it's a tireless contributor.

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, slightly overconfident junior who never gets tired:

• 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 neither a revolution nor a parlor trick. It's a real productivity shift 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.