Vibe coding, and the four rungs above it

Vibe coding was named for throwaway weekend projects by the person who named it. It is now being used to build systems that answer business phones and hold customer records. Those are different activities, and the distance between them is four rungs of a ladder worth being able to see, whether or not you ever climb it.

What he actually said

On 2 February 2025, Andrej Karpathy — formerly of OpenAI and Tesla — posted the sentence that named a practice: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

Everyone quotes that line. Almost nobody quotes the rest of the post, which is where the useful part is. He describes accepting every suggestion without reading it: “I ‘Accept All’ always, I don’t read the diffs anymore.” He describes losing track of what he had built: “The code grows beyond my usual comprehension, I’d have to really read through it for a while.” He describes his debugging method: “Sometimes the LLMs can’t fix a bug so I just work around it or ask for random changes until it goes away.”

And then the qualifier that the industry dropped on the floor: “It’s not too bad for throwaway weekend projects.”

That is not a criticism of him. It is an accurate description of a genuinely useful mode of working, correctly scoped by the person doing it. The problem is what happened to the phrase afterwards. A term coined for weekend throwaways became a way of describing how production systems get built, and the qualifier did not travel with it.

The ladder

There are roughly four rungs between that post and being able to build something a business should depend on.

Vibe coding. Describe what you want, let the model build it, look at whether it seems to work. Fast, genuinely useful, and the code is not understood by anybody including its author.

Structured vibe coding. The same, with the work defined first. What is this for, what data does it hold, what are the steps, what should happen when each one fails. Then build, then test against the definition rather than against a feeling.

AI-assisted engineering. The person directing the work understands what is underneath: how the page a customer sees talks to the machinery behind it, what the store of records is doing, what one service has promised another it will always send, how the system knows who somebody is, how a change gets tracked so it can be undone, how work gets from a laptop to the live site, where somebody could get in, and what a test actually proves. The model does most of the typing. The human knows what is being typed and can tell when it is wrong.

Software engineering. You can reason about the whole system without the model at all.

Those rungs are not a moral ranking. Rung one is the right tool for a prototype you will throw away on Sunday night. The mistake is not using it. The mistake is using it and then leaving the result answering a customer’s call on a Tuesday.

The gap between feeling fast and being fast

There is one piece of evidence here that is worth more than any argument, and it is uncomfortable in both directions.

In July 2025, METR ran a randomised controlled trial on sixteen experienced open-source developers working on their own repositories, across 246 real tasks. Before starting, the developers expected AI tools to make them 24% faster. Afterwards, they believed the tools had made them about 20% faster. Measured, they were 19% slower.

Sit with the shape of that rather than the number. It is not that the tools did nothing. It is that the people using them could not tell which direction they had moved in, and were confidently wrong by roughly forty points about their own work.

Now the caveats, because this study is quoted badly in both directions. METR itself is explicit that its results do not show “that AI systems do not currently speed up many or most software developers,” nor that there are no better ways of using them. Sixteen people is a small sample, they were working in codebases they already knew well, and the tools were those of early 2025. METR has since said plainly: “These results are out of date. We have released results that are current as of early 2026, in a continuation of this study.”

So do not carry it as AI makes people slower. Carry the finding that survives all of those caveats, which is that the feeling of speed is not evidence of speed. That applies to whoever built your system, and it applies to you when you look at what they produced and it seems fine.

Where a business actually needs to sit

Nobody running a winery or a clinic needs a software engineer on staff, and the fourth rung is not the target.

What a business needs is that somebody in the room can recognise when a generated system is fragile, insecure, badly shaped, or quietly missing a rule the business actually runs on. That is the third rung, and it is a lower bar than it sounds: not the ability to write everything, but the ability to read what was written and know what is missing.

It matters because the failures are not dramatic. A system built on rung one usually works in the demo. It falls over the first time two things happen at once, or a service is unavailable, or somebody does something the builder never pictured. By then it is holding customer records and answering the phone, and the person who built it cannot say what it does, because the code grew beyond their comprehension in exactly the way the original post described.

How to tell which rung yours was built on

You do not need to read code. Four questions do it.

Ask what happens when something it relies on stops working. Every system leans on other people’s services — the calendar it books into, the phone network carrying the call, the software holding your customer list. Any of them can be down for an hour, and none of them will warn you first. Ask what the system does in that hour. Someone on the first rung has no answer, because the question was never tested. Someone on the third answers immediately and specifically.

Ask what the tests cover. If the answer is that it was checked by using it, that is testing by vibe. It catches the paths somebody thought to try.

Ask who can change it in six months. If the honest answer is that it would be rebuilt rather than modified, it is a prototype in production, whatever it cost.

Ask to see what happened on a specific day. If nothing was logged, nobody can tell you what the system did, which means nobody can improve it and nobody can defend it.

None of this is an argument against building quickly with these tools. We use them, and the speed is real. It is an argument that the thing a business is buying is not the speed, it is the judgement about what the speed produced. Which is the same argument as the system behind the agent, and the same one as writing the process down first, arriving from a third direction: the visible part was never the work.

Questions people ask