In February 2025, Andrej Karpathy fired off what he later admitted was a throwaway tweet. There is a new kind of coding, he wrote, where you "fully give in to the vibes" and "forget that the code even exists." The name stuck instantly: vibe coding. Within a year it was an industry, a meme, and a small culture war.
You have probably seen the demos. Someone types one sentence into a chat box, waits thirty seconds, and a working app appears. Applause, hot takes, someone announces the end of programmers.
I build this way every day. Everything on this site was made like this: a Danish exam coach, a generative DJ toy, a mahjong game, the site itself. So let me say two things that are both true. The name is accurate: I really do describe what I want and shape it with the machine until it's real, and I ship things I could never have built alone. And the demos are misleading, because they show the first thirty seconds of a process that actually looks like a long, opinionated argument.
This is what the argument looks like from the inside.
01The loop nobody puts in the demo
The demo shows a straight line: prompt in, app out. The real thing is a loop, and you are standing in the middle of it.
If you read my field guide to AI, you'll recognise the shape: it's the agent loop (perceive, plan, act, observe) with one crucial substitution. You are the judge. The machine perceives, plans and acts at a speed no human can match. What it cannot do is decide whether the result is any good, because "good" lives in your head, not in its training data.
So a real session goes like this. I describe a thing: "a DROP button you hold to build tension and release to slam." The machine drafts it, flawlessly formatted, plausibly structured, in seconds. I run it. The build-up works but the release sounds like a wet firecracker. I say so, specifically. It drafts again. Better, but now the bass ducks at the wrong moment. Around we go. The typing is gone from my job. The deciding has expanded to fill the space.
If that loop feels familiar, it should. It is exactly what you already do when you ask a chatbot to draft an email and it comes back too formal, then too casual, then finally right. Vibe-coding is that same conversation, pointed at software and kept going until something real ships. If you have used AI for anything at all, you have already stood in this loop. You just called it something else.
Vibe-coding deletes the typing, not the judgment. What's left of the work is almost entirely judgment.
02A true story: the drone, the siren, and the mute switch
Strøm is a toy on this site that turns anyone into a main-stage DJ. All the sound is generated live in the browser: no audio files, just code making waveforms. The machine wrote every line of it. Here is what "wrote every line" hides.
The first background pad it generated was technically correct and musically dead. It just droned. My commit history says it plainly: the fix is literally labelled "kill the drone." The next version overshot and the pad now rose and fell like a distant emergency vehicle. Next commit: "fix siren-like pad." The machine could produce a pad in seconds. It could not hear that the pad was bad. Hearing it was my whole job.
The controls got redesigned twice, because versions one and two were technically fine and felt like operating a spreadsheet. And then, after all of that, I shipped it, opened it proudly on my own phone, and heard nothing. Total silence. The code was flawless. The problem was the physical mute switch on the side of the iPhone, which browser audio quietly respects. No model suggested checking it, because no model has ever held a phone.
The mahjong game has its own version of this story. It shipped with a service worker (the code that makes it work offline) that got itself into a loop and kept reloading the page forever, in production, on real people's phones. The machine wrote a fix in one attempt once I described the symptom. But noticing the symptom required a human being watching a screen flicker and thinking: that's not right.
03Where it breaks down
These are the failure modes I hit constantly. None of them are reasons not to build this way. All of them are reasons the demos oversell it.
- It is confidently wrong, in fluent code. The same property I wrote about in the field guide applies to code: the model is a fluent guesser. Generated code compiles, reads cleanly, and sometimes does subtly the wrong thing. Wrong code that looks right is more dangerous than code that crashes.
- It cannot run your product. It couldn't hear the drone, couldn't feel the mute switch, couldn't see the reload loop. Every quality that lives in the physical, sensory, running world is invisible to it until you observe it and report back. You are its eyes and ears, permanently.
- It fixes one thing and quietly bends another. As a project grows, a change over here can un-fix something over there, and the machine will not always notice. If you don't re-test the things you already trusted, they silently stop being true.
- Its taste defaults to average. Ask for a website and you get the same rounded-corner template everyone else got. The distinctive parts of anything I've shipped exist because I rejected the first plausible answer, repeatedly. Sameness is the default setting.
- It lets you stop understanding your own product. This is the quiet one. If you accept everything without reading, you gradually become a stranger in your own codebase, and the day something breaks deep, you're debugging a haunted house you technically own.
The uncomfortable honest bit
Vibe-coding does not remove the need to understand things. It moves it. You need less syntax and more system: what a service worker is, why audio needs user permission, what should happen when the network dies. The machine handles how to write it. Whether it should be written, and whether it actually works, stays stubbornly yours.
04So what do you actually do all day?
If the machine types everything, what fills the hours? Four things, and they turn out to be the four things that were always the hard part of building anything.
You decide what to build. The machine has no opinion about whether the world needs a browser DJ for non-DJs. Every product decision, every "this feature, not that one," is yours. This sounds obvious and consumes half the day.
You set constraints, and constraints are the design. The mahjong game guarantees every board is solvable, works fully offline, and has no ads, no account, no tracking. None of those came from the machine; each one shaped hundreds of downstream decisions the machine then executed. Give it no constraints and you get the average of everything, which is nothing.
You verify like it's your name on it, because it is. Run every feature. On a real phone. With the mute switch on. This is the traffic-light rule from the field guide applied to code: the more it matters, the less you take the confident answer's word for it.
You say no. The first plausible draft is rarely the right one. The single biggest difference I've noticed between people who get real products out of this and people who get mush is the willingness to reject working code because it isn't good, and to say precisely why.
05You already do this at work
Everything above sounds like a story about programmers. It isn't. Swap "code" for anything the machine now drafts on your behalf: a slide deck, a quarterly report, a job description, a market analysis. The division of labour is identical, and so are the failure modes.
The machine can draft your deck in seconds. What it cannot know is that your CFO hates hockey-stick charts, that slide six quietly contradicts the number sales gave the board last month, or that the client reading it lost money on exactly the strategy it just recommended. That knowledge is your mute switch: invisible from inside the machine, obvious the moment the work meets a real person in a real room.
Which means the person who pastes a model's analysis straight into a board deck is shipping my silent music toy. It looks perfect, it works in the demo, and it fails on first contact with reality. The fix is also the same: run it, judge it against what you know that the machine cannot, say "not quite", and go again. The loop is the job now, whatever your job is.
06Should you try it?
Yes. Unreservedly. And I say that having just spent two thousand words on the failure modes.
Because here is the other side of the ledger: I am one curious person, and in parallel with a full life I have shipped a language-exam coach, a generative music engine, a puzzle game, and this site. A few years ago that list would have required either a team or a decade. The demos oversell the ease, but they do not oversell the power. Both things are true at once, which is exactly the kind of sentence marketing can't use.
What you need is not a computer science degree. You need three things: the ability to describe what you want precisely (vague in, vague out, same as ever), the patience to go around the loop without getting discouraged, and the discipline to test like a skeptical user rather than a proud parent. Notice that all three are learnable, and none of them is typing.
The bar for building software used to be: can you write code? The bar now is: can you tell good from bad, and can you say so clearly? That is a genuinely different skill, harder in some ways, more human in every way.
The machine types. You decide. That division of labour is the entire thing, and the deciding was never the easy half.
Related
- AI Without the Hype: the field guide this piece leans on, covering how these models actually work and the traffic-light rule for trusting their output.
- The projects mentioned: Strøm, Ocean's Mahjong, and Danish for PD3, all free, all built this way.
- Andrej Karpathy's original post: the February 2025 note that named the whole thing.
Written by Gaurav Vedi, building with AI in Copenhagen. The commit messages quoted are real; the embarrassment was too. Spotted something wrong? Tell me: I'm learning in the open.