What Is Vibe Coding, and Where Does It Stop?

Vibe coding means building software by describing in plain language what should exist, and not reading the code that comes back. Andrej Karpathy coined the term on 2 February 2025, and Collins made it word of the year in November 2025.

The term promises that work disappears. It does not disappear, it moves. Typing code turns into writing an order and checking a result. That is something we can count in our own order: in the one we use to build a working page in front of an audience, 25 of 179 words are the goal. The other 154 are context, limits and one worked example. Anyone who believes it is enough to say what you want has mistaken the shortest of the four blocks for the whole order.

What is vibe coding?

Vibe coding is a way of working in which a person describes in natural language what a piece of software should do, a language model produces the code, and the person does not read that code but judges only the result. Leaving out the review is the core of it, not the use of AI.

Karpathy described it on 2 February 2025 as a new kind of coding "where you fully give in to the vibes, embrace exponentials, and forget that the code even exists" (Andrej Karpathy on X).

Collins took the term as its word of the year the same year and defines it as "the use of artificial intelligence prompted by natural language to write computer code" (Collins Dictionary, 6 November 2025).

The sharpest distinction comes from Simon Willison, and it is the one most explainers walk past: "If an LLM wrote the code for you, and you then reviewed it, tested it thoroughly and made sure you could explain how it works, that's not vibe coding, it's software development" (simonwillison.net, 19 March 2025).

Something uncomfortable follows from that. Most of what gets described as vibe coding is not vibe coding by the original definition. If you check the result, you are developing software with a very fast tool. That is not hair-splitting. It is the difference between a way of working that holds and one that holds only until something breaks.

Does the language you write the order in matter?

Not for whether it works. We write our orders in German, including the one printed in full below, the one we type live in front of an audience.

The language you describe things in is separate from the language the code and its identifiers end up in. Both belong in the order if you care about either, and then the matter is settled. What you do give up outside English is the volume of worked examples: when you get stuck searching, the answer is nearly always in English. Which settings actually follow another language, from the reply to the documentation, is worked through in Using Claude Code in German.

What actually happens when someone describes only the vibe?

They do not describe only the vibe. That is the empirical finding, and it is not ours.

Advait Sarkar (University of Cambridge and University College London) and Ian Drosos (Microsoft Research) analysed five recorded vibe coding sessions, 8 hours and 27 minutes in total, with the participants thinking aloud (arXiv:2506.23253, 29 June 2025). What they observed is not surrender to the vibes but steering: participants mix vague high-level direction with detailed technical specification, name individual pieces of code, structure instructions into lists, paste in error messages and refer back to earlier output.

The authors also describe an effect anyone who has done this will recognise: context momentum. Early choices in a session narrow the later ones. What gets fixed in the first few minutes helps decide what stays easy to change afterwards. Which is exactly why the start of an order is not the place to be brief.

The left lane feels faster because its first step takes ten seconds. It spends the time at the back, in rounds nobody planned for. The right lane spends the time at the front, once.

What does an order that holds look like?

It has four blocks, always the same ones: goal, context, limits, example. That is the structure we teach in the course and the one we type ourselves, including on stage. An order that settles all four needs no follow-up question and usually no second round. You can fill in the four blocks in our prompt generator, which assembles them into one order.

What belongs in each block:

1. Goal. The result, not the route. A page where somebody gets a ballpark price in five questions, not "build me a form".
2. Context. What the agent has to know and must not guess: what already exists technically, how the business calculates, which prices apply. The block almost everyone keeps too short.
3. Limits. What explicitly must not happen. No database, no sign-in, mobile first. Limits keep the rounds short, and with them the bill.
4. Example. One case, worked through, with the result that should come out. The agent checks itself against it, and writing it is how you find out whether your own logic holds.

Here is what that looks like written out. This is not a reconstructed sample, it is the order from our live build, verbatim, for an invented example business with a made-up price list. It is German because that is how we type it:

Ziel: Eine öffentliche Seite /preisrechner, auf der ein Brautpaar in fünf Fragen
einen unverbindlichen Richtpreis für einen Hochzeitsfotografen bekommt und
danach eine Anfrage abschicken kann.

Kontext: Next.js App Router mit Tailwind, steht schon. Das Geschäft ist ein
Solo-Fotograf in Köln. Preisliste: Grundpaket sechs Stunden 1.400 Euro, jede
weitere Stunde 150 Euro, zweiter Fotograf 450 Euro, Album 390 Euro, Anfahrt ab
50 Kilometer 50 Cent pro Kilometer, und auf die Summe 20 Prozent Aufschlag,
wenn es ein Samstag zwischen Mai und September ist.

Grenzen: Keine Datenbank, keine Anmeldung. Das Ergebnis erscheint sofort im
Browser, ohne dass jemand seine E-Mail hinterlässt. Die E-Mail kommt erst beim
Absenden der Anfrage. Unter dem Formular ein Satz zum Datenschutz mit Link auf
/datenschutz und eine Checkbox, die gesetzt sein muss. Mobil zuerst, die Seite
wird auf dem Handy benutzt.

Beispiel für ein gutes Ergebnis: acht Stunden, zweiter Fotograf, Samstag im
Juni, 30 Kilometer Anfahrt, kein Album ergibt 2.580 bis 2.970 Euro, und die
Rechnung steht aufgeschlüsselt darunter, damit der Preis nicht wie geraten
wirkt.

Now count the blocks. The result is the reason this article exists.

The goal is the shortest block, at 25 of 179 words, or 14 percent. Context and limits together come to 119 words, or 66 percent. The longest block is the one that says what must not happen.

That is the whole lesson in one number. Vibe coding is sold as "just say what you want". In an order that actually works, what you want is the smallest part. The rest is the work nobody used to see, because it happened inside a programmer's head.

How do you know when it is done?

By a counter-check that runs without you doing it. This is where it gets decided whether you have handed something over or only appear to have.

Karpathy's own description ends at the result. He wrote that he sees stuff, says stuff, runs stuff and copy-pastes stuff, "and it mostly works" (Andrej Karpathy on X, 2 February 2025). "Mostly" is fine for a weekend project and not fine for a page that takes enquiries from strangers.

What this looks like here can be counted. This website carries 163 automated tests across seven files, run on 21.09.2026 before this article went out. On top of that are the rules that bite at build time: the check on blog posts alone knows 15 conditions under which the build stops instead of publishing the page. A missing source line, a date in the wrong format, an internal link to a post that does not exist, a meta description over 155 characters: each of those breaks the build, and nobody has to remember them.

From this follows the practical rule, and it holds whatever tool you use. You can hand over exactly as much as your counter-check carries. If you have tests, you can hand over a lot. If you have none, you hand over the typing and still review everything afterwards, and the promised time saving is gone.

It does not have to be a test suite at the start. A counter-check can also be the worked example from block four, a second person who uses the result, or simply the rule that nothing goes online that you have not clicked through once yourself from start to finish.

Where does vibe coding stop?

At anything that can do damage when it is wrong. That is not a posture, it is the line its advocates draw too.

Willison names it in the same post in which he defends vibe coding. His test is how much harm the code could cause if it has bugs or security holes. Specifically he advises against it where billing runs on usage, and he holds that with secrets and private data you have to understand how the code works (simonwillison.net).

Fraunhofer IESE places the same point from the engineering side: vibe coding is not a hype but a new development approach meeting classical software engineering, and the risks sit where nobody has an overview of what has been produced any more (Fraunhofer IESE, 27 November 2025).

For us that has one very concrete consequence in the order above. The data-protection sentence under the form and the checkbox that has to be ticked sit in the limits block, not the goal block. That is the part we explicitly do not leave to the vibes, because it is where strangers' personal data gets taken in. Everything else on that page may come into being however it comes into being.

A workable rule of thumb for your own case: if you cannot answer "what happens in the worst case" in one sentence, the thing is too big for this way of working.

Where do you start?

With something that harms nobody if it is wrong and that you need this week anyway. A calculator, an overview, a small tool only for you.

Three steps, no more:

1. Write the four blocks before you open the tool. If you cannot fill the context block, the agent cannot either.
2. Work your example out yourself. A wrong example in the order costs more than none, because the agent aligns itself to it.
3. Decide up front how you will know it is right. Before the first run, not after.

Which tool you use for it is the smaller question. If you do have to choose, we answered it along the lines of how you work in Claude Code vs Cursor, and what really drives the monthly bill is covered in our German article on Claude Code costs.

The layer above all this is what turns one good first run into a way of working: the four blocks, the file holding your rules, the counter-check, and eventually tasks that finish without you. That is what we teach in The Claude Code System, four weeks with weekly live sessions. If you would rather first watch an order like this being typed live and see what happens, come to a free live webinar. All courses are listed under Courses, and the people behind them on About.