AI-Assisted Coding vs Vibe Coding
There are two fundamentally different ways to use AI for code, and anyone using it should be able to tell which one they're doing at any given moment. The problem is not which one is "better", because both have a place. The problem is not knowing which one is happening, because the right answer to "is this safe to commit?" depends entirely on which mode produced the code.
I wrote this distinction into the AI usage policy for a studio earlier this year, and the vocabulary turned out to be the part of the policy people actually used. Once people had words for the two modes, the conversations about where each one belongs got dramatically easier. This post is the distinction itself, what depends on it, and where each mode fits.
The Two Modes
AI-assisted coding means the engineer is the author. They understand the problem, direct the AI, and read, evaluate, and own every line of output before it's committed. The AI speeds up the work, but the engineer could explain and defend the result without it. If someone asked "why does this do X?", the answer is a technical explanation, not "Claude wrote it." The AI is a research assistant and a fast-fingered colleague, and the judgment is the engineer's.
Vibe coding means the AI is the primary author. The human describes what they want, accepts the output based on whether it appears to work, and may not fully understand the implementation. They direct at the level of intent and outcome, and the AI fills in the how. This is a valid way to build things quickly. It also carries real risk. An author cannot catch bugs they do not understand, cannot maintain code they did not write, and has no way to evaluate whether the output is secure, performant, or architecturally sound.
These are points on a spectrum more than a binary, but the spectrum has a clear midpoint. If the author couldn't sit in a code review and walk a colleague through what each block does and why, they have crossed from assisted into vibe. The crossover is the part that matters, because that's where the risk changes character.
The Review Asymmetry
Both modes produce code that looks plausible. That property of modern LLMs is what makes them productive and what makes them dangerous in equal measure. The mode the author was in when the code was produced is the thing that tells the team what to do with it next.
For AI-assisted code, the next step is normal. Review the diff, run the tests, ship the PR. The AI was a tool that compressed the authoring time, but the human is still the author and the usual author-accountability machinery is intact.
For vibe-coded output, the next step depends on what the output is for. If it's a personal experiment or a throwaway script, "looks like it works" is the only bar that matters. If it's anything other people depend on, every assumption baked into the output by an author who didn't fully understand it is now a hidden risk. The bug class shifts from "the author made a mistake I can find by re-reading the diff" to "the author shipped a structure they never modeled in their head, and the break is in a part of that structure neither of us is looking at."
The reason this matters in practice is that vibe-coded output can be reviewed, but it can't be reviewed the same way. A reviewer looking at vibe-coded code is doing first-author work on someone else's code, not second-author review on a colleague's code. That's a different and much heavier task, and pretending it's normal review is how vibe-coded code ends up in production without anyone really understanding what landed.
Where Each Mode Belongs
The policy split I landed on, after iteration, was this. A given studio's variant will differ, and the structure is what matters.
Production projects. Anything shipping to players, anything other people depend on, anything in the production engine repo gets AI-assisted only. The person who commits the code owns it and must be able to explain it line by line. AI speeds up the work, it does not author it.
Internal and experimental projects. Workshop prototypes, internal tools, and exploratory work that may or may not become something can use vibe coding at lead discretion, provided the safeguards below are in place. The bar here is "is this learning, or is this becoming something people will depend on?" If it crosses the second line, the rules of production apply from that point.
Personal and throwaway projects. No restrictions. Experiment freely. Use whatever produces results fastest. Do not use production credentials, repos, or assets, and do not ship the result anywhere other people will depend on it without re-authoring it under the production rules first.
The reason for the split is not a value judgment about vibe coding. It's that the consequences of "code I don't understand" scale with how many people depend on the code and how long the code lives. A throwaway script is unaffected by whether the author understands it five months from now, because there's no five months from now. A piece of game code that ships to players has a five-year tail, and "I didn't really understand this" compounds across every bug, every refactor, every onboarding, every postmortem.
Vibe Coding Safeguards
Where vibe coding is allowed, the problems that bite hardest aren't the obvious code-quality ones. They're the outside-the-code ones, the things that aren't in the diff at all.
Source control first. The project must be in a Git repo with a recent commit before a session with a code-writing AI begins. This is non-negotiable. Tools like Claude Code can write, move, rename, and delete files across an entire project at speed. Unlike a normal editor, there's no universal Undo that covers everything the AI does. A local repo costs nothing, needs no internet, and gives full rollback. Before each session, check for uncommitted changes, commit them, then let the AI work.
No production credentials. Vibe-coded projects must not have access to production API keys, secrets, encryption keys, or databases. Use isolated environments with their own credentials. The risk isn't that the AI does something malicious. It's that an unsupervised author writing code they don't fully model can ship a credential leak or a destructive operation without ever seeing it on its way out.
Dependency review. Do not blindly install packages suggested by AI. Verify that packages exist, are actively maintained, and come from legitimate sources. AI hallucinating package names is a known supply-chain vector. An attacker registers a plausible-sounding package the AI invents, and any vibe coder who runs the install command ships the attacker's code.
Network isolation. Vibe-coded projects should not run on production infrastructure or have access to internal networks without explicit approval. If a vibe-coded prototype graduates to something that's actually going to be used, the graduation is the right moment to re-author it under the rules of production.
Security review before deployment. If a vibe-coded project will be accessible to users, even internally, it gets a basic security review from an engineer covering authentication, data handling, and exposed endpoints before that happens. "Claude said it was secure" is not clearance.
These aren't rules against the mode. They're rules for containing where the mode goes wrong, so the mode itself can be used freely inside the container.
The Failure I Keep Seeing
The most common breakdown I see, across studios and teams, isn't engineers vibe-coding production work. Engineers tend to be calibrated about this. They know the difference between exploring and committing, and they instinctively re-author the parts they are going to commit. The breakdown I see is non-engineers vibe-coding things that became production without ever crossing the line back into AI-assisted.
The sequence is familiar. A producer or designer prototypes a tool for their own use. The tool turns out to be useful. Other people start using it. It accretes features. At some point it stops being a prototype and becomes part of the production workflow, but nothing in the journey flagged the crossover, so the code never went through the re-authoring step. Now there's a piece of production infrastructure whose author can't explain it, whose code has had no security review, and whose dependency choices were never audited.
This is what the distinction is for. It gives the team a vocabulary to flag the crossover. "This is becoming central, it needs to graduate." Without that vocabulary, the crossover happens silently and the team only notices when the prototype breaks in a way no one knows how to fix.
The Standard That Scales
The single test that does the most work is this. Could the author defend this code in a room?
Not "did the AI write it." Not "is it well-commented." The question is whether the human author can sit in a code review or a fifteen-person meeting and walk through what the code does, why each significant choice was made, and where it can break. If the answer is yes, the mode was AI-assisted, regardless of how much of the typing the AI did. If the answer is no, the mode was vibe, regardless of how much the human typed.
That standard scales because it doesn't try to regulate the tool. It regulates the outcome. Whatever models look like in five years, whatever new categories of generated content emerge, "can the author defend it in a room?" keeps applying.
What the distinction gave us wasn't a policy clause. It was a shared question the team could put to each other, "which one are you doing right now?", and a reason to care about the answer before the code ships rather than after it breaks.