Vibe coding is building software by describing what you want in plain language and letting an AI agent write, run, and iterate on the code, rather than typing every line yourself. You say "add a pricing page with three tiers," the agent generates the components, wires up the routes, and runs the build. You look at the result, say what's off, and it adjusts.
The term comes from a specific moment: on February 2, 2025, Andrej Karpathy — an OpenAI co-founder and Tesla's former AI director — described "a new kind of coding" where you "fully give in to the vibes" and "forget that the code even exists." The post cleared 4.5 million views in weeks. Merriam-Webster logged the phrase as slang in March 2025, and Collins named it Word of the Year for 2025. By mid-2026 it has stopped being a novelty and become a normal way small teams and solo builders ship real products.
It works. It also has a specific, predictable failure mode, and understanding that failure mode is the difference between vibe coding a real product and vibe coding a demo that falls apart the first time a client opens it on their phone.
How vibe coding actually works
The loop looks the same whether you're using Claude Code, Cursor, or Codex CLI:
- You describe the change in natural language, in a terminal or an editor chat panel.
- The agent reads the relevant files, plans an approach, and edits code directly.
- It runs the build, the tests, or a dev server to check its own work.
- You review the result, either by reading the diff or looking at the running app.
- You give more feedback, and it loops back to step 2.
What makes this different from autocomplete is step 3. A modern coding agent doesn't just suggest a line and wait for you to accept it. It executes commands, reads the output, and corrects itself, often through several iterations before it hands control back to you. That's the "agentic" part, and it's the reason vibe coding can produce a working feature from one sentence instead of a hundred keystrokes.
Vibe coding vs. just using AI to code
Worth drawing a line here, because the terms get blurred. Simon Willison made the useful distinction early: not all AI-assisted programming is vibe coding. If you read every diff the agent produces, understand each change, and would be comfortable maintaining the result by hand, you're using AI as a fast typist — that's AI-assisted development, and it's the norm for professional engineers.
Vibe coding, in Karpathy's original sense, is the stronger version: you stop reading the diffs. You accept the changes, run the app, and steer by outcome — "that's broken, try again" — without holding the code in your head. That's liberating for a throwaway prototype or a weekend tool. It's also exactly where the risk concentrates, because the further you get from reading the code, the more you depend on seeing the result clearly. Which is where the failure below comes from.
What it's good at
For a huge range of tasks, this loop is genuinely faster than typing the code by hand:
- Boilerplate and scaffolding. New components, API routes, form validation, database migrations — the stuff with a well-known shape that the model has seen a million times.
- Refactors with a clear target. "Extract this into a hook," "convert this class component to a function," "rename this across the codebase." The agent can grep, edit, and verify faster than you can find every call site.
- Debugging with a stack trace. Give it an error and it can often read the trace, find the file, and propose a fix in one pass.
- Working across an unfamiliar codebase. You don't have to hold the whole mental model in your head before making a change; the agent can read what it needs on demand.
This is why the term stuck. For a solo founder or a small agency, an agent that can plan, edit, and self-correct across a real codebase changes how much one person can ship in a day.
Where it breaks
The failure mode is consistent enough to name: the agent is confident about code it wrote and blind to how that code actually renders.
A coding agent reads and writes text. It can run a build and confirm there's no type error. It can run a test suite and confirm the assertions pass. What it cannot do on its own is look at the live page the way a person does — notice that a modal is centered on desktop but clipped on mobile, that a button's hover state never fires because a sibling element is intercepting the click, or that a form technically submits but the success state is invisible against the background. None of that shows up in a terminal. All of it shows up the first time a real person opens the page.
This is the gap every "vibe coding disaster" story traces back to: not that the agent wrote bad code, but that nobody in the loop actually looked at the rendered result before it shipped. The code compiled. The tests passed. The thing still looked broken, and the first person to notice was a client or a user, not the person who built it.
The fix isn't "stop vibe coding." It's closing the loop the same way you would with a human junior engineer: someone reviews the actual output before it ships, and that review has to be specific enough to act on. "The button looks off" doesn't tell an agent anything it can use. "This element, at this width, with this selector, should have 16px more top margin" does. The difference between vague feedback and a coordinate the agent can act on is most of what separates a smooth review cycle from an endless back-and-forth.
That's the whole reason a visual feedback layer exists in this workflow at all: not to replace the agent, but to hand it eyes it doesn't have. A pin dropped on the live page carries the selector, the viewport, and often the console output along with the note, which is a very different input than a screenshot pasted into chat with a paragraph of description trying to make up the difference.
The tools people actually use
Vibe coding isn't one tool, it's a stack. Three pieces show up in almost every setup:
- A coding agent. Claude Code, Cursor, and Codex CLI are the three most common choices in mid-2026, each with a different balance of terminal-first versus editor-first workflow.
- A place to run it. Increasingly, agents connect to external tools over MCP — Model Context Protocol — so they can read a database, control a browser, or pull structured feedback without you copy-pasting context by hand.
- A way to check the output. Deploy previews, local dev servers, and (for the visual gap above) a review layer that lets a human point at the live page instead of describing it in prose.
If you're assembling this stack for the first time, the tool choice matters less than most debates make it sound. All three major agents can plan, edit, and self-correct; they differ more in speed, context handling, and price than in raw capability, and the field moves fast enough that any specific claim here has a shelf life of months, not years.
Is vibe coding safe to ship with?
Yes, with the same discipline you'd apply to any code you didn't personally review line by line. That means:
- Running the app and clicking through the actual flows, not just trusting a green build.
- Reviewing diffs for anything security- or data-sensitive, since an agent can be confidently wrong about auth logic or permissions.
- Testing the selector an agent wrote against real markup before you trust it — the CSS selector tester is a fast way to check one in isolation.
- Keeping feedback specific: a pinned element and a clear ask beats a vague note every time, whether the note is going to a person or an agent.
Vibe coding removes the friction between having an idea and having working code. It does not remove the need to look at what got built. The teams getting the most out of it are the ones who treat the agent as a fast collaborator that still needs a second pair of eyes on the rendered page, not a black box you can trust blind.
Beyond your own review
Two related loops sit next to this one once real people are involved. If you're collecting review notes from clients or teammates instead of just reviewing your own work, the same "coordinates, not descriptions" principle applies — see our roundup of website feedback tools for how that category works. And if the person paying for the site is the one giving the feedback, the workflow shifts again toward approvals and sign-off, covered in our guide to client feedback tools for agencies.
Shotline is a hosted feedback layer that pins comments to the live element (not a screenshot) and exposes the whole queue over MCP, so a coding agent can pull the exact selector and console context instead of guessing from a picture. It's free to try, from $19/mo (billed annually; $25 month-to-month) after your trial. If you're deep in a vibe coding session and tired of re-describing which button you mean, start a free trial and hand your agent a pin instead.
