0034 min read
On vibe coding
What's actually new, what isn't, and which work to use it for and which not.
“Vibe coding” is the current term for hammering at a coding agent until the result feels right. It's the second incarnation of a thing programmers have been doing forever, with new ergonomics that make it noticeable.
What isn't new about it: the tightening loop between intent and artefact. Programmers have been compressing that loop for sixty years. Punch cards → assemblers → high-level languages → IDEs with autocomplete → REPLs → live reload. Each step lets you stop thinking about a category of mechanics and think about the thing you actually want. Vibe coding is the next instalment.
What is new:the artefact loop is no longer text-only. You're not just compressing the gap between “I want a button that's centred” and “the button is centred”. You're compressing the gap between “I think this should feel like a Linear page” and “it does”. You can describe outcomes that historically required taste, and have the system iterate towards them. That's a new kind of compression: the loop between aesthetic and result, which never had a feedback channel before.
The bad part:vibe coding rewards short-horizon judgement and punishes long-horizon judgement. You converge to the local optimum that feels right, fast. You don't think about the architecture five iterations later, the test you'd want at six, the contract you'd want at twelve. The loop is so tight that you skip the slow, deliberate thinking that produces durable software. Same trap as every previous productivity jump, except more so, because each iteration is so cheap that there's even less reason to pause.
The right way to use it, I think, is to vibe-code the disposable parts of your work and grown-up code the load-bearing parts. UI variants? Vibe. Layout exploration? Vibe. Prototype to learn? Vibe. The data model, the auth boundary, the migration, the things you'll regret in 18 months? Slow down. Read the diff. Write the test. Pick the name like an adult.
The pattern that works for me: vibe forward, audit backward. Generate three drafts, read each carefully, choose. Don't merge what you didn't read. Treat the agent as a fast typist with no taste (which is mostly what it is), and supply the taste yourself.
Same as code review used to work, except your reviewee is the machine.