Vibe Coding, Honestly: What It Is, What It Isn't, and Where It Breaks
Vibe coding has gone from a Karpathy post to a full cultural moment in under a year. Here is what it actually is, where it works well, and the specific places it quietly falls apart.
The term "vibe coding" was coined by Andrej Karpathy in February 2025. The original description was deliberately loose: you describe what you want, the model writes the code, you accept the diff without reading it too carefully, and you iterate on vibes. That looseness is probably why the term stuck. It named something a lot of people were already doing quietly and did not quite have a word for.
A year on, vibe coding has become a cultural moment. It is in job ads. It is in pitch decks. It is the subject of increasingly heated debate between people who think it is the end of software engineering and people who think it is a toy. Both of those positions are wrong in instructive ways.
Here is what we actually think, after using these tools heavily across client projects, internal tooling, and our own products — an opinionated companion to our earlier, broader honest assessment of LLMs as a development tool.
It Is a Spectrum, Not a Style
The most useful thing to notice is that "vibe coding" describes a spectrum, not a single practice.
At one end, there is pure vibe coding: describe the thing, accept the diff, run it, describe what is still wrong, accept the next diff. No reading. No reviewing. Get it working by iterating against the output.
In the middle, there is what most working engineers actually do: the model writes a first draft, you skim it, you tweak it, you run it, you make it yours. The word "vibe" still applies in the sense that the model did the typing, but the engineer is in the loop at each step.
At the other end, there is what often gets called "AI-assisted coding": the engineer drives, the model auto-completes, suggests, and occasionally drafts, but the engineer is reading every line and would be perfectly capable of writing it without help.
Lumping these three together is how the debate gets so confused. Pure vibe coding is a reasonable technique for a small set of problems and a poor technique for most. Assisted coding is now close to baseline for working engineers. The interesting question is when each one is appropriate.
Where It Actually Works
Prototypes. If the purpose of the code is to find out whether an idea works at all, vibe coding is excellent. You do not care about the internals of something you might throw away tomorrow. The value is in getting to "does this concept hold water" as cheaply as possible, and pure prompting gets you there faster than careful design.
One-off scripts. A data cleaning script, a migration that runs once, a throwaway command-line tool — the kind of code that nobody will ever own, maintain, or extend. There is no long-term cost to absorb, so the short-term savings are real.
Exploratory UI. Sketching an interface to react to, iterating on layout and interaction patterns, finding out what feels right. The code itself is almost incidental to the design exercise.
Learning unfamiliar libraries. Asking a model to show you how to do a specific thing with a library you have never used is often faster than reading docs, particularly when the docs are inconsistent or sparse.
In all of these, the common thread is that the code is either disposable or the learning is the point.
Where It Quietly Falls Apart
Authorisation logic. Code that decides who can do what needs to be read, understood, and reasoned about line by line. Vibe-coded permission systems tend to look correct on the happy path and fail silently on the edges — a field that gets set without the ownership check, a role whose permissions overlap with another role in an unanticipated way. Nobody notices until an incident. The OWASP Top 10 is weighted heavily towards access-control failures for a reason.
Concurrency and race conditions. Models are poor at reasoning about state that moves underneath them. They will happily produce code that works when there is one user and falls over at any kind of scale, and the symptoms will not look like concurrency bugs. They will look like flakiness.
Data migrations. Writing a migration is not hard. Writing a migration that will not lose data on a production table with thirty million rows is hard. The model does not know your locking behaviour, your replication topology, or the fact that the users table is referenced by seven other tables you have not mentioned. This is the class of bug where "it worked in my environment" is the most expensive sentence in software.
Performance at scale. Code that runs fine on the test dataset and collapses at production volume is a classic vibe-coded failure mode. N+1 queries, unindexed lookups, in-memory operations on unbounded lists. GitClear's research on AI-assisted code has found measurably higher rates of churn and duplicated logic in AI-heavy codebases compared to hand-written baselines, which is a reasonable signal that this kind of drift is happening broadly, not just in codebases we have looked at.
Anything with an audit trail. Code that goes into regulated environments, or that handles money, or that has to be defensible to an auditor six months from now, needs to be traceable to decisions someone actually made. "The model suggested it" is not a good answer.
The Honest Framing
Vibe coding is a technique, not an identity. Treating it as either the future of all software or a moral failing misses the point. It is a tool with a specific shape, and using it well means knowing when that shape fits your problem and when it does not.
We vibe code regularly. We also read every line of code that ships in anything that matters. These are not contradictions — they are different modes for different kinds of work. When it does go wrong in production — as it does — the failure patterns are remarkably consistent.
The engineers who will do best over the next few years are the ones who can move fluidly along the spectrum: pure vibe for exploration and throwaway work, careful review for production systems, and a clear sense of which is which.
Building something where it is not obvious which mode is appropriate? Get in touch — or see our AI & Automation services for how we approach this on client work.