The phrase started as a joke in our standup. Michaela had just shipped a non-trivial change to the RAG pipeline and described her workflow as “vibing with the agent until it got the chunking right.” Alena said something similar about a workflow YAML. It stuck. Now we use it without irony.
“Vibe coding” is a terrible name and an accurate description. It points at a real change in how software gets built — one that’s already happening on our team and at most of the better-organised AI-native teams we work with, even where they don’t have a name for it.
What it is, concretely
Vibe coding is what you do when:
- You start with intent (“I want chunking that handles tables better”), not with code.
- You describe the change to an agent the way you’d describe it to a senior colleague.
- The agent proposes a diff. You read it.
- You either accept it, or refine the description and try again, or take the agent’s output and edit it by hand.
- You iterate until the result fits the vibe of the codebase — the patterns, the conventions, the gotchas the agent doesn’t know about.
- You ship.
That’s the loop. The interesting parts are what it isn’t.
What it isn’t
It isn’t no-code
No-code tools constrain you to a fixed set of building blocks. Vibe coding has no such constraints — you’re asking for arbitrary changes to arbitrary code. The output is real code in a real codebase that real engineers maintain.
It isn’t low-code
Low-code tools generate scaffolds you fill in. Vibe coding doesn’t generate scaffolds — it generates surgical changes against an existing system. You’re collaborating with the agent on production code, not graduating up from a visual builder.
It isn’t “copilot autocomplete”
Autocomplete-style assistants amplify your typing. Vibe coding amplifies your specification. The expensive cognitive work shifts from typing-the-code to articulating-the-intent, which is a different muscle.
It isn’t hands-off
You read every diff. You reject most first attempts. You take the agent’s code and edit it. The human is the architect, the reviewer, and frequently the finisher. The agent does the keystrokes.
Why it works (when it works)
Three things have to be true for vibe coding to actually be productive, and most teams that try it and bounce off are missing at least one of them.
- The agent has access to the whole codebase. Not just the file you’re editing. The whole repo, in retrieval, with semantic search. Otherwise it makes confidently wrong choices that ignore existing patterns.
- The feedback loop is fast. If you have to wait 60 seconds between “here’s what I want” and “here’s the diff,” you lose the conversational rhythm that makes the loop work. Sub-10-second turnaround changes the experience qualitatively.
- You can read code well. If you can’t evaluate the diff in 30 seconds, you can’t catch the agent confidently shipping a subtle bug. This is why “vibe coding for non-engineers” doesn’t really work yet, despite the marketing.
Where voice fits in
Half our team types prompts. Half talks to the agent through Whisper-on-the-laptop. There’s no obvious productivity difference between the two for short edits. For longer specifications — “I want this whole module restructured around this new abstraction, and here are the constraints, and here are the failure modes I’m worried about” — voice wins, hands-down. You can’t type that fast, and trying to type it tightens up the language in counterproductive ways.
Voice also unlocks the most important property of vibe coding: working away from the keyboard. The interesting bugs get debugged on a walk, where there’s no keyboard and no temptation to start typing.
Our internal canvas tooling lets you describe a workflow with your voice and watch the YAML write itself, then iterate by saying things like “but make the retry exponential, and add a dead-letter step at the end.” That’s vibe coding for workflow definitions. The shape of the loop is identical to vibe coding for source code.
Why it isn’t the death of programming
Every six months someone announces that programming is over. They’re always wrong. Programming isn’t the production of source code — it’s the structured thinking required to produce something that works. Vibe coding doesn’t replace that thinking; it removes the keystrokes that historically expressed it.
If anything, vibe coding makes the underlying skill more visible. When typing was the bottleneck, weak architects could hide inside fast typists. With the typing removed, weak architecture is exposed in three iterations: the agent keeps producing diffs that work but feel wrong, and only a strong architect can articulate why.
The senior engineers on our team have never been more valuable. The juniors who used to specialise in “writing the code carefully” need to skill up into “deciding what the code should be.” That’s a different career — not a worse one.
The bottleneck moved from typing to deciding. Programming didn’t end. The boring part of it did.
How to start, if you want to try it
- Pick a real, scoped task. Not a greenfield prototype — a real change in a real codebase you understand.
- Set up an agent with retrieval over the whole repo. Don’t feed it one file at a time.
- Describe the intent in two or three sentences. Read the diff. Resist the urge to skip the reading.
- If the diff is wrong, say specifically what’s wrong. Vague feedback gets vague second drafts.
- Ship the result and observe what the existing review process catches. That tells you what your taste is missing.
- Iterate the loop, not just the diff. The way you describe intent, the way you review diffs, the way you decide when to stop — all of that improves with practice.
The first week feels weird. The second week feels productive. The third week you can’t go back. The fourth week you start describing your day to your spouse the way you describe a task to the agent, and you’ll know it’s become a habit.
That’s vibe coding. Better name welcome.