Ask someone who codes this way to describe what they did that afternoon and you’ll get an answer that sounds less like engineering and more like directing: “I told it to add a filter, didn’t like where the button landed, told it to move it, then asked for a loading state.” No syntax mentioned. No file names. Just a conversation that turned into working software.
That style of building has a name now, coined by Andrej Karpathy and picked up fast across the developer community. Vibe coding describes a workflow where you build software mostly by describing what you want in natural language and letting an AI agent write the actual code, shifting your job from typing syntax to directing intent and reviewing results. This post covers what vibe coding actually looks like day to day, where it works well, and the one habit that keeps it from turning into a mess.
What Changes When You Vibe Code
The traditional loop is: think about the change, write the code yourself, run it, debug, repeat. The vibe coding loop is: describe the change, let the agent write the code, review the diff, run it, describe the next change. The thinking hasn’t gone anywhere — you’re still deciding what the software should do — but the mechanical act of typing syntax has moved to the agent, and your attention shifts toward reading and judging what comes back rather than producing it yourself.
This isn’t the same as “no-code” tools, which remove programming from the picture entirely. Vibe coding still produces real code, in a real git repository, that you can read, test, and deploy normally — the agent is doing the typing, not replacing the codebase with a black box.
It also isn’t the same as autocomplete-style AI assistance, where suggestions appear line by line as you type and you accept or reject them in place. Vibe coding operates at the level of whole tasks — “add this feature,” “fix this bug” — with the agent producing a complete, multi-file change for you to evaluate as one unit, which is a fundamentally different rhythm than reviewing individual autocomplete suggestions as they appear.
A Typical Vibe Coding Session
# You describe the feature in plain language to the agent
"Add a search box above the product list that filters as you type"
# The agent writes the component, wires up state, and shows you a diff
# You review it, then either accept or refine:
"Good, but debounce the input so it doesn't filter on every keystroke"
# The agent adjusts, you review again, then commit
git add . && git commit -m "feat: add debounced product search"
Each round trip is fast — often faster than writing the code by hand would have been — which is exactly why review discipline matters more here than it did before, not less. It’s tempting to accept a diff that “looks right” after the third or fourth quick exchange, and that’s where mistakes slip through.
Where Vibe Coding Shines and Where It Doesn’t
| Task type | Vibe coding fit | Why |
|---|---|---|
| UI components, CRUD screens | Strong | Well-understood patterns, easy to verify visually |
| Boilerplate, config, scaffolding | Strong | Repetitive, low-risk, fast to review |
| Novel algorithms, tight performance code | Weaker | Requires precision an agent can’t verify by “looks right” |
| Security-sensitive logic (auth, payments) | Weaker without careful review | Mistakes are subtle and consequences are high |
| Exploratory prototypes | Very strong | Speed matters more than polish at this stage |
The pattern is consistent: vibe coding is strongest wherever “does this look and behave correctly” is a good enough check, and weakest wherever correctness depends on subtleties a glance won’t catch.
The One Habit That Keeps It Safe
The failure mode of vibe coding isn’t the AI writing bad code — it’s the human stopping the review discipline that made the workflow trustworthy in the first place. A code review checklist for AI-written code is worth keeping close, because the speed of the loop is exactly what erodes the instinct to actually read every diff.
The other habit worth building in is isolation: give each vibe-coded task its own branch and workspace, so a session that goes off the rails doesn’t tangle with the one before it. This is the same principle behind git worktrees — separate working directories mean you can throw away a bad session without losing a good one.
Why the Term Caught On So Fast
Part of why “vibe coding” spread so quickly as a term is that it named something a lot of developers were already doing without a shared word for it. Before the term existed, people described the same workflow in roundabout ways — “just chatting with the AI until it works,” “letting Copilot drive” — none of which captured the specific shift of treating conversation as the primary interface rather than a helper alongside manual coding. Giving it a name made it easier to talk about openly, including its risks, instead of treating it as an embarrassing shortcut.
The Collins Dictionary recognition of the term reflects something real: it’s not a fad description of a tool, it’s a description of a workflow that has stuck around because it matches how a growing share of software actually gets written now, from solo indie projects to production features at established companies.
Setting Expectations for Non-Trivial Codebases
Vibe coding demos tend to show greenfield projects — a new app built from nothing in an afternoon — which understates how the workflow behaves inside a large, established codebase with its own conventions, legacy quirks, and hidden coupling between modules. The conversational loop still works there, but it requires more context up front: the agent needs to know the existing patterns before it can match them, and a vague prompt in an unfamiliar corner of a big codebase produces worse results than the same vague prompt in a fresh project with no history to clash against.
This is where the discipline from writing better prompts matters most — feeding the agent the specific conventions of the file or module you’re touching turns a vibe coding session in a mature codebase from a coin flip into something closer to a reliable collaboration.
Getting Started
- Pick a small, well-scoped feature — a UI component or a form — and describe it to an agent in plain language instead of writing it yourself.
- Review the diff line by line before accepting it, even though the temptation is to skim once the pattern feels reliable.
- Iterate with short follow-up instructions rather than one long upfront prompt; vibe coding works best as a conversation, not a spec.
- To keep each vibe-coded session cleanly isolated with a proper diff to review, try Agents — every session gets its own worktree, branch, and a right-side diff panel, with a 7-day free trial before the one-time $9.99 purchase.
Vibe coding is a real shift in how software gets written, not a gimmick — see Andrej Karpathy’s original description of the term for where it came from. The workflow works as well as your review habits do, so the goal isn’t to code less carefully — it’s to spend that care on reading diffs instead of typing syntax.