Vibe Coding: A Practitioner's Guide to Shipping With AI

Vibe coding went from an offhand tweet to a verb the whole industry uses in under a year, and most of what gets written about it is either breathless or dismissive. Neither is much use if you actually ship software. The honest version is more interesting: vibe coding is a real shift in how code gets written, it genuinely speeds up some work, and it produces insecure, unmaintainable garbage the moment you stop paying attention. This guide covers what vibe coding actually is, the workflow that works, exactly where it breaks, and how senior teams use AI heavily without letting the quality bar drop. We build software this way every day, so this is the practitioner's view, not the hype.

What vibe coding actually is

Vibe coding is writing software by describing what you want in plain language and letting an AI generate the code, then judging the result by whether it runs and behaves rather than by reading every line. You stay in the prompt, not the editor. You see stuff, say stuff, run stuff, and accept what works.

The term comes from Andrej Karpathy, who posted it in February 2025: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He described his own loop as "I just see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works." The throwaway post was viewed millions of times within days, because it named something a lot of people had quietly started doing.

The defining trait isn't "using AI to code." It's the deliberate decision to stop reading the output. That is what separates vibe coding from the broader practice of AI-assisted development, where a person still owns and reviews every change. Karpathy was explicit that he meant it for weekend projects, "throwaway" software where the stakes are zero. Most of the trouble in the field comes from people taking a mode built for prototypes and pointing it at production.

It helps to put it on a spectrum:

• Autocomplete. The AI finishes the line or block you are already writing. You read all of it. This is barely a change to the job.
• AI-assisted development. You prompt for whole functions or features, then review and edit the result like a senior reviewing a junior's pull request. You own the code.
• Vibe coding. You prompt for behavior, run it, and accept it if it works, without reading much. The AI owns the code; you own the goal.

These are not better or worse in the abstract. They are different amounts of trust, appropriate to different stakes. The mistake is using the wrong one for the job, and the most expensive version of that mistake is vibe coding something that needed review.

Vibe coding is not "using AI to write code." It is choosing to stop reading the code. That choice is free on a prototype and ruinous on anything that ships.

Two things make this possible now that were not true a few years ago. Models got good enough to produce working code from a vague description, and the tools wrapped around them got good enough to run that code, read the errors, and try again on their own. The first is the model. The second is the agent loop, which is the same reason-act cycle we cover in our explainer on how AI agents work: the model proposes an action, code runs it, the result feeds back, and the loop repeats until the goal is met or you stop it.

The vibe-coding workflow, step by step

A good vibe-coding session has a shape. People who get value from it are not just typing wishes into a box. The loop looks like this:

1. Describe the outcome, not the implementation. You tell the tool what the program should do and what "done" looks like. "Build a CLI that takes a CSV of transactions and prints monthly totals, with a flag for a specific account." The clearer the success condition, the better the result, because the AI has something concrete to aim at.
2. Let the AI generate. A modern coding agent scaffolds files, writes the code, and often runs it. You watch it work rather than write it yourself.
3. Run it and read the behavior. You execute the program and check the output against what you asked for. This is the heart of the loop: you are testing the behavior, not auditing the source.
4. Steer with the next prompt. It is wrong in some way, so you say how. "The totals are off because it is double-counting refunds." The AI reads the feedback, often reads the error itself, and revises.
5. Repeat until the vibes are right. You loop on behavior until the thing does what you wanted, then you stop.

Three things make the difference between a session that flies and one that spirals into a mess.

Context is everything. The AI can only reason about what it can see. A tool that has read your whole repo, your types, and your conventions writes code that fits. A tool working from a single prompt with no project context writes plausible code that does not match anything around it. This is the single biggest predictor of output quality, and it is why the tooling section below cares so much about how much each tool can see.

Small steps beat big ones. Ask for one coherent change, verify it, then ask for the next. The instinct to describe the entire app in one prompt feels efficient and reliably produces a tangle that is hard to debug because too much changed at once. Tight loops keep each change small enough to judge.

Say what is wrong, specifically. "It doesn't work" gives the AI nothing. "It crashes on empty input" gives it a fix. The quality of your steering is the quality of your result. Vague feedback gets vague code in return, and you spin.

The uncomfortable part is that none of those steps include reading the code. That is the design of the thing, and it is exactly why the next section exists.

Where vibe coding breaks

This is the part the demos skip, and it is the whole reason a guide like this is worth writing. Vibe coding fails in specific, predictable ways. Knowing them is the difference between a tool and a foot-gun.

Security is the big one

Code that runs isn't code that's safe, and the AI optimizes for the first. When you stop reading the output, you stop catching the SQL injection, the hardcoded key, the missing auth check, the unvalidated input. The AI will happily produce all of these because they make the program work in the happy path.

The data here is not subtle. Veracode's 2025 GenAI Code Security Report tested over 100 models across 80 tasks and found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability. The same report found AI-written code carried 2.74x more vulnerabilities than human-written code on the same tasks, and Java came out worst, failing the security tests in over 70% of cases. The finding that should stop you cold: as models got better at writing functional code, they did not get better at writing secure code. Security stayed flat while capability rose. The thing that makes vibe coding feel magical, the model's fluency, does nothing for the thing that gets you breached.

The practice inherits ordinary security risk and then removes the human who would have caught it. That's a different and worse problem than a developer occasionally writing a bug.

Debugging code you did not write

The first prompts feel fast. Then something breaks that you don't understand, because you didn't write any of it. Now you are debugging a stranger's codebase, except the stranger is a model that will confidently rewrite three working things to fix one broken one. The loop that built the feature in ten minutes can spend an hour going in circles, each "fix" introducing a new break, because neither you nor the AI holds the whole picture in mind.

This is the point where vibe coding quietly inverts. The time you saved up front comes back as time lost in a debugging spiral on code nobody owns. A person who had written the code would know where to look. A person who vibe-coded it is reverse-engineering their own program.

It does not scale

Vibe coding works beautifully up to a few hundred lines and a handful of files. Past that, the model can no longer hold the system in context, and the cracks show. Architecture drifts because each prompt optimizes locally with no memory of the global design. Patterns get reinvented inconsistently across files. The same logic appears three times in three shapes. There's no coherent structure because no one, human or model, was holding one.

A small app is a collection of working features. A real system is a set of consistent decisions, and consistency is exactly what a behavior-only loop does not produce.

Maintainability and the knowledge gap

Software is read far more than it is written, and it is maintained for years by people who were not in the room when it was built. Vibe-coded code optimizes for the one moment it first ran. Six months later, someone has to change it, and there's no mental model to change it against, no one who can explain why it works, often no tests describing what it's supposed to do.

This is the deepest problem, because it is invisible at ship time. The demo works. The cost arrives later, as a team inherits a codebase nobody understands. Developers feel this even as they lean in: the 2025 Stack Overflow Developer Survey found that while 84% of developers now use or plan to use AI tools, only 29% trust the accuracy of the output, down from 40% the year before. Adoption is up and trust is down at the same time, which is exactly what you would expect from a tool that produces working code you cannot fully vouch for.

Vibe coding vs production engineering: where the line is

The line is not "AI or no AI." Senior teams use AI constantly. The line is whether a human understands and stands behind what ships.

Production engineering has a non-negotiable floor that vibe coding, by definition, skips:

• A human has read and understood the change, or it does not merge.
• Tests describe the intended behavior and run on every change.
• Security review and scanning catch the class of flaw the Veracode numbers warn about.
• An architecture someone owns keeps the system coherent as it grows.
• A trail of why — commit messages, reviews, decisions — so the next person can maintain it.

Vibe coding is a way to generate candidate code fast. Production engineering is the discipline that decides whether that code is fit to ship. Confusing the two is the central error in the field right now. You can vibe-code the first draft of a feature and then put it through the full production gate, and that's a perfectly good workflow. What you can't do is vibe-code it and skip the gate, because the gate is the part that makes it production software.

The productivity research makes this concrete in a way that surprises people. A controlled GitHub study found developers built a greenfield HTTP server 55% faster with an AI pair programmer than without. But a 2025 randomized controlled trial from METR, run on experienced open-source developers working in large codebases they already knew deeply, found the opposite: the AI made them 19% slower — even though they had forecast a 24% speedup beforehand and still believed, after the fact, that it had sped them up. Same technology, opposite result, because the tasks were opposite. AI is fastest on greenfield and boilerplate, where there is little context to lose. It is slowest, sometimes negative, where deep system knowledge already lives in a person's head and the AI cannot see it. Where vibe coding falls on that curve is exactly where the line between prototype and production sits.

How senior teams vibe-code with rigor

Used well, AI is a genuine accelerator. The teams getting value are not going pure-vibes; they are running a tightened version of normal engineering with AI doing more of the typing. Here is what that looks like in practice.

Vibe the draft, gate the merge. Use AI freely to produce the first version, then run it through the same review, tests, and scanning every other change goes through. The speed comes from the draft. The safety comes from the gate. Nothing ships on vibes.

Read the diff, every time, before it merges. This is the one rule that turns vibe coding from a liability into a tool. You can let the AI write it all. You cannot let it merge without a human understanding what changed. Reviewing AI code is its own skill, and it is the skill that separates senior AI use from junior, which is the subject of our piece on how senior engineers actually pair with AI.

Tests are how you trust at speed. A behavior-only loop is dangerous because behavior is all you checked. A real test suite makes that safe: it pins the behavior down so the AI can move fast inside guardrails it cannot quietly break. Teams that vibe-code well write the tests, or have the AI write them and then review those carefully, because the tests are the contract.

Give the AI your stack, not just a prompt. Output quality tracks context. Senior teams invest in feeding the tool their conventions, types, and architecture so the generated code fits the system instead of fighting it. The mechanism for this is maturing fast: agent skills and project files let you teach a coding agent your codebase's rules once and have it apply them every time, which we cover in our guide to Claude Code skills. Connecting the agent to your real data and tools through the Model Context Protocol extends the same idea to the systems around the code.

Keep a human owning the architecture. Let the AI fill in functions; do not let it decide the shape of the system. A person holds the design, makes the structural calls, and uses the AI to execute them. This is the difference between a coherent system and a pile of locally-optimal files, and it is the practice we mean by agentic coding: an engineer directing AI agents through real work, not abdicating to them.

The pattern across all five: AI generates, humans decide. The acceleration is real, and it lands precisely because the team kept the parts that vibe coding throws away.

The tools that make it work

A note on framing first: this is a snapshot of mid-2026, and this category changes monthly. Treat the names as examples of stable categories, not a leaderboard, because any ranking is stale by the time you read it. What matters isn't which tool is "best" but how much of your context a tool can see and how much control it leaves you. Those two properties are stable; the logos aren't.

The landscape sorts into three classes:

• AI-native editors and IDE extensions. Tools like Cursor and GitHub Copilot live where you already work and see your open files and often your whole project. They sit between autocomplete and full agent, which makes them the workhorse for AI-assisted development: fast, in context, and easy to keep a human in the loop.
• Terminal-based coding agents. Tools such as Anthropic's Claude Code run in your terminal, read the whole repo, run commands, and handle multi-step tasks like a developer would. They are the closest thing to "describe it and it does it," and the most context-aware, which is why they punch hardest on real codebases. This is the agent end of the spectrum.
• Prompt-to-app builders. These generate a whole project from a description. They are the purest expression of vibe coding and the best fit for its sweet spot: prototypes, demos, and throwaway tools where speed matters and the stakes are zero.

Cutting across all three is the Model Context Protocol (MCP), an open standard Anthropic released in November 2024 to connect AI tools to the systems where your data and tools actually live. It matters here because context is the whole game: an agent that can reach your database, your docs, and your internal services through a standard interface writes code that fits your reality instead of guessing at it. MCP is becoming the connective tissue of this space, and it is worth understanding on its own terms.

The selection criteria that survive the news cycle:

• How much context can it see? Whole repo beats open files beats a single prompt. More context, better code.
• How much control does it give you? Can you review before it acts, scope what it can touch, see what it changed? Control is what keeps the speed safe.
• Does it fit your existing workflow? A tool you have to leave your stack to use gets used less and trusted less.

For a fuller, vendor-neutral breakdown of the categories and how to choose, see our guide to the AI coding tools landscape. The honest summary: pick the tool that sees the most of your context and gives you the most control, and ignore the demo that promises you never have to look at the code.

When to vibe-code and when not to

The decision is mostly about stakes and reversibility. Vibe coding trades understanding for speed. That trade is a bargain when a mistake is cheap and a disaster when it is not.

Vibe-code freely when:

• You are prototyping to test an idea, and the code is going in the bin either way.
• You are building an internal tool with low stakes and a small blast radius.
• You are exploring an unfamiliar API or language and want a working example to learn from.
• You are doing one-off scripting — a data transform, a quick automation — where you will read the output, not the source.

These are Karpathy's original case: throwaway software where giving in to the vibes costs nothing.

Do not vibe-code when:

• The code touches authentication, payments, personal data, or anything irreversible. The Veracode numbers are not a suggestion here.
• The work will be maintained by a team for years. Someone inherits the knowledge gap, and it is expensive.
• The change lives deep inside a complex system whose constraints the AI cannot see. This is the METR case, where AI goes negative.
• You cannot describe "done" clearly enough to judge the result. If you can't tell whether the output is right, you can't steer it, and you're just hoping.

The reliable instinct: the higher the stakes and the longer the code lives, the more it needs a human who understands it, which means the more it needs real engineering and the less it can run on vibes alone. Vibe coding is a fast way to a first draft. Whether that draft is allowed to ship is an engineering decision, and on anything that matters, the answer is "not until a person stands behind it."

That is the whole craft, really. Vibe coding is a real and useful mode, the speed is not a lie, and the failures are just as real as the wins. The teams that come out ahead are not the ones who vibe-code the most or the least. They are the ones who match the mode to the stakes, lean on AI hard where it is cheap to be wrong, and keep the boring discipline exactly where being wrong is expensive. AI-native engineering is what we do, and that judgment — knowing which mode the moment calls for — is the part worth getting right. It is what the modern AI software engineer actually does, the kind of engineer we hire, and the bet we are compounding.