Vibe coding

Vibe coding is building software by describing what you want to an AI model and accepting what it writes without reading it closely. Andrej Karpathy coined the term on 2 February 2025, describing a way of working where "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." He later called it a throwaway post. It went on to become Collins Dictionary's word of the year for 2025, after Merriam-Webster added it as slang and trending that March.

The definition drifted almost immediately. Most people now use "vibe coding" to mean any use of AI to write code, which loses the thing that made the term interesting. Simon Willison drew the line back where Karpathy put it in "Not all AI-assisted programming is vibe coding": the defining feature is not reviewing the output. If you read, test and can explain every line the model produced, you are doing AI-assisted programming. His rule is a good one to keep — never commit code to a repository that you could not explain to another person.

That distinction is not pedantry. Nearly every claim made about vibe coding — that it is ten times faster, that it produces insecure code, that it will replace developers — is true of one of those two practices and false of the other.

The advice that survives contact with a real project is unglamorous.

Describe the outcome, not the implementation. "Users should be able to reset their password by email, and the link should expire after an hour" produces better results than "add a reset_token column." The model is better at choosing the mechanism than you are at specifying it, and worse at guessing what you actually wanted.

One change per request. A prompt asking for five things gets you five half-implementations that interact badly, and when something breaks you cannot tell which of the five did it.

Run it every time. The failure mode that wastes whole afternoons is stacking ten prompts without executing anything, then discovering the third one broke the build. Generated code compounds errors quietly.

Read the risky parts anyway. Skim the UI if you like. Read anything that touches authentication, payments, file uploads or a database query built from user input. That is roughly 5% of a typical application and it is where essentially all of the damage lives.

Commit from the start. The fastest fix for a bad generation is discarding it, and that only works if you have something to go back to. This is also the difference between a bad afternoon and a lost project.

There is real research here, and it is less flattering than the marketing and less damning than the backlash.

Security is the strongest finding. Veracode's 2025 GenAI Code Security Report tested more than 100 models across 80 coding tasks and found AI-generated code introduced a security vulnerability in about 45% of them; its cross-site scripting tasks failed about 86% of the time. This is not new. A Stanford and NYU study published at ACM CCS in 2023 found that participants with an AI assistant wrote less secure code than those without — and were more confident it was secure. The confidence gap is the part worth internalising.

Speed is genuinely contested. The most rigorous measurement is a randomised controlled trial run by METR in July 2025: 16 experienced open-source developers, 246 real issues from their own repositories, AI access randomly assigned. They were 19% slower with the tools, having predicted a 24% speedup and still believing afterwards that they had been 20% faster. Two honest caveats: METR has since said those specific 2025 results are out of date as the tools improved, and the study measured experienced developers working in codebases they knew well — close to the worst case for AI assistance, and the opposite of someone building something new.

The public failures share a shape. In July 2025 an AI agent deleted a production database during a founder's Replit trial, then reported that its tests had passed and that a rollback was impossible, which was untrue. In May 2025, a scan of 1,645 apps built on Lovable found around 170 of them leaking personal data because row-level security policies were missing. Neither is a story about bad code generation. Both are stories about missing scaffolding — backups, access policies, review on the parts that handle credentials.

The fair conclusion: vibe coding is very good at producing something that works and unreliable at producing something safe. If nothing in your app touches user data, money or authentication, the risk is genuinely low. As soon as something does, the generated code needs the same review any code would get.

Two categories get lumped together under the same label, and choosing well starts with knowing which one you want.

Coding assistants — Cursor, Claude Code, GitHub Copilot, Windsurf — write code inside a project you are already managing. You keep the repository, the deployment and the responsibility. They are the right choice if you can read the output, and the wrong one if you cannot, because nothing else in the loop will catch a mistake.

AI app builders — Lovable, Bolt.new, Replit, v0, Base44, Rork, Appifex — generate the whole application, including the parts most people would not think to ask for: a database schema, authentication, hosting, store submission. They are the right choice if you want a working product rather than a codebase, and the question to ask each one is what you are left holding. Some hand you a repository you own and can host anywhere. Others hand you an app that exists only while you are paying.

Note who is telling you this: Appifex is in the second list. We have written up all sixteen tools side by side, with each one's capabilities quoted from its own documentation and the case for choosing it over us stated in its own terms. Take the comparison over the recommendation.

"Vibe coding jobs" is a search with almost nothing real behind it. The job boards that rank for it are search-engine content rather than employers, and no recognised job title matches — actual postings say product engineer or AI-first developer.

The measured picture is narrower than either the hype or the panic. Stack Overflow's 2025 developer survey asked all respondents whether vibe coding was part of their professional development work. About 15% said yes in some form — 11.9% plain yes, 2.8% somewhat, 0.4% emphatically — against 72.2% no and a further 5.3% emphatically no. Adoption of AI tools generally is far higher; adoption of the practice in its strict sense is not.

On employment, the serious work is Stanford's Digital Economy Lab research on AI and early-career employment, which documents a real relative decline for workers aged 22 to 25 in AI-exposed occupations while employment for experienced workers held up. That is about exposure to AI tooling across occupations, not about vibe coding as a practice, and it should not be quoted as if it were.