Andrej Karpathy coined "vibe coding" on 6 February 2025, describing a way of working where you accept the AI's changes without reading the diffs and "forget that the code even exists". He also called it fine for throwaway weekend projects, a qualifier that tends to get lost. The comparison of vibe coding vs traditional development comes down to one question: does a human understand the code that ships?
What counts as vibe coding
Developer Simon Willison defines vibe coding as building software with an LLM without reviewing the code it writes. That definition draws the line in a useful place.
If you prompt an AI, then read, test and can explain what it produced, Willison says you're doing software development, and the LLM is incidental. His own rule is that he won't commit code he couldn't explain to someone else.
So the real contrast isn't human typing against machine typing. It's reviewed code against unreviewed code, and everything below follows from that.
Vibe coding vs traditional development: what actually differs
Traditional development puts checkpoints between an idea and a user: someone reads the change, tests run, and a person owns the result. Vibe coding removes the reading, which is exactly why it's fast and exactly why it's risky.
| Question | Vibe coding | Traditional development |
|---|---|---|
| Who has read the code? | Nobody, by definition | The author and a reviewer |
| Who can fix it at 2am? | Whoever can re-prompt the tool | The team that wrote it |
| Where it works best | Demos, mockups, internal one-offs | Anything customers or regulators touch |
| Where it breaks | Security, edge cases, later changes | Slower first version, higher upfront cost |
The table is our own summary of the trade-off, not a measurement. The measurements are below, and they're less kind to vibe coding than the marketing is.
Is vibe coding actually faster?
For a first demo, almost certainly. For finished, maintained software, the evidence is murkier than most people assume.
In a randomized trial run by the non-profit METR, 16 experienced developers worked through 246 real issues in mature open-source projects, with each issue randomly assigned to allow or forbid AI tools. The Register's report on the study says allowing AI increased completion time by 19%, even though the developers expected a 24% speedup and still believed afterwards that they'd been about 20% faster.
Read the caveats before you quote that number. The authors say the slowdown doesn't mean AI tools fail to improve productivity in general. The developers knew their repositories well, and those repositories were large, which left the AI little to add.
Even so, one finding transfers to any project: time moved from writing code to prompting, waiting and reviewing. Reviewing is the step vibe coding skips, so a team that skips it saves that time and picks up a different bill later.
What the security research says
Working code and safe code are different things, and the gap between them is where vibe coding hurts.
Researchers at Carnegie Mellon built a benchmark of 200 feature requests taken from real open-source Python projects, then let coding agents implement them. In their December 2025 preprint, the best-performing agent setup produced functionally correct code 61.0% of the time but code that was both correct and secure only 10.5% of the time.
Telling the agent to watch for security flaws, or even naming the specific weakness, didn't fix it. The authors flag that the benchmark is Python-focused and uses test results as a proxy for security, so treat it as a warning about direction rather than a precise failure rate for your app.
Field data points the same way. A Cloud Security Alliance research note from April 2026 counts 74 vulnerabilities (CVEs) linked to AI coding tools through March 2026, and the monthly count climbed from 6 in January to 35 in March. The same note leans on secondary sources for several of its figures and says results vary by tool and test method, so it's best read as a pattern, not a verdict.
Why does unreviewed code fail this way? Because a person who never reads the authentication logic never notices that it's missing a check. The tool optimises for something that runs, and "runs" is what the demo proves.
Where vibe coding earns its place
Photo by DS stories on Pexels
Used for the right job, it's genuinely useful. A throwaway prototype to test whether anyone wants the idea, a mockup to settle an argument about layout, a one-off script only you will run: none of these carry the risks above, because nothing sensitive is exposed and nothing has to last.
We cover the practical side of that in our guides to building an MVP with vibe coding and the tools non-technical founders try first.
The trouble starts when the prototype quietly becomes the product. Real users bring real data, and at that point an app nobody has read becomes an app nobody can safely change.
Where traditional development wins
Anything that holds customer data, takes payments, connects to other systems or has to survive several years of changes belongs in a reviewed codebase. The upfront cost is higher, and that's the honest price of having people who understand what they've built.
Traditional doesn't mean AI-free. Engineers use AI assistants constantly, and by Willison's definition that's still software development as long as the code is reviewed, tested and understood. The METR result suggests it won't always make a mature codebase faster, but the review habit is what keeps the quality.
That's the work our apps and SaaS team does, and where we use AI inside a reviewed process, it's through our AI and automation practice.
A verdict by project type
Our recommendation is simple: vibe code to learn, and build properly to launch. Match the approach to what happens if the code is wrong.
- Idea validation or demo: vibe coding is a sensible fit, as long as it never touches real customer data.
- Internal tool with a handful of users: vibe coding can work if someone with security training reviews anything involving login, permissions or stored data.
- Customer-facing product: build it with a reviewed process from the start.
- Anything regulated or payment-related: traditional development, with no exceptions.
If a vibe-coded prototype has already found users, the Cloud Security Alliance note offers a sensible order of work: treat the AI's output as untrusted, run automated security scans on every change, check that database access rules exist, and look for secrets left in client-side code. Have someone with security training read the authentication and data-handling code before anything else.
Frequently asked questions
Is vibe coding safe for a production app?
The research says to be careful. In the Carnegie Mellon benchmark, agents wrote working code far more often than working and secure code, and prompting for security didn't close the gap.
Is AI-assisted coding the same as vibe coding?
No. Simon Willison's distinction is that vibe coding means not reviewing the generated code. If you review, test and can explain it, it's regular software development with an AI helping.
Do AI tools make experienced developers faster?
Not always. In METR's 2025 trial, experienced developers on large, familiar codebases took 19% longer with AI allowed, though the authors caution that this doesn't apply to every setting.
Cover photo by Daniil Komov on Pexels
Sources
- Not all AI-assisted programming is vibe coding — Simon Willison's Weblog
- AI coding tools make developers slower but they think they're faster, study finds — The Register
