"Vibe coding" started as a joke about prompting an AI, glancing at whatever it produced, and shipping it without really reading the code. It stopped being a joke fast, and now it shows up in job descriptions and interview questions as something employers are actively screening against. Worth understanding what it actually is, where it is genuinely fine, and where it quietly wrecks things.
What it actually means
Vibe coding, in the sense people now use the term, is not "using an AI agent to write code." Almost everyone does that now, and it is not the problem. Vibe coding specifically means accepting what the agent produced without reading it closely enough to be able to explain it, then moving on the moment it appears to run. The code works, in the sense that nothing crashed during the thirty seconds you looked at it. Whether it works in every other sense is a question nobody asked.
Where this is genuinely fine
There are real situations where vibe coding is a completely reasonable way to work, and pretending otherwise is not useful. A one-off script that reformats a spreadsheet you will use once. A throwaway prototype built to test whether an idea is worth pursuing at all, where the code itself gets deleted either way. A personal tool that only you will ever run, where the cost of a bug is you noticing it yourself and fixing it later, alone, with nobody downstream depending on the number being right. In all of these, the code has no users, holds no money, and needs no maintenance. Reading every line closely would be effort spent on the wrong thing, and the honest move is to ship it, see if it works, and move on.
Where it actually fails
The failures show up once the code has stakes: real users, real money, or someone other than you who has to maintain it later. That is the actual line, not "was AI involved," and it tends to be quiet rather than dramatic.
- Silent data bugs. A calculation that is subtly wrong, a filter that drops a category of records nobody thought to check, a date handled correctly for most rows and wrong for a specific edge case. Nothing crashes. The number is just wrong, and it stays wrong until someone downstream notices it does not add up, by which point it may have fed into a decision.
- Security holes. Unvalidated input passed somewhere it should not be, a permission check that looks present but does not actually cover the path someone will use, a secret left in a place that gets committed. An agent that was not told to think about security will not necessarily think about it, and code nobody read closely will not catch that it did not.
- Unmaintainable code. Six months later, someone, possibly you, needs to change this. If nobody understood it when it was written, the person changing it is starting from zero, on code that already runs in production and that they are now afraid to touch.
None of these show up in the first thirty seconds. That is exactly why they are dangerous: the code that fails immediately gets caught immediately, and the code that fails quietly is the code nobody read.
The failure mode of vibe coding is never the crash. It is the wrong number nobody checked.
What employers are actually screening for
Not "do you use AI to write code." Almost every candidate does. What is actually being tested, sometimes directly in an interview, sometimes indirectly through a take-home task, is whether you can read a piece of generated code and say something true and specific about what it does, question a decision in it that looks off, and fix it when it is wrong. That is a different skill from writing code from scratch, and it is a different skill from prompting well. It is closer to code review, and it is the one that vibe coding, by definition, never exercises.
How to build evidence you have it
Claiming "I review AI code carefully" on a CV is exactly the kind of unprovable line that recruiters have learned to discount. Verifiable projects beat self-claimed skills precisely because a claim like that cannot be checked, and a graded project can be. The Legacy Fix is built around that exact gap: reading, questioning and fixing generated code, with a scorecard at the end that says whether you actually did it.
Next time an agent hands you something that runs, resist the urge to call it done. Read it, ask what it would do at the edges, and only then decide whether it is finished.
