essay
Why I vibe code
The honest version, from someone who is product, design, frontend, backend, support and QA at the same time.
I've written a lot of code by now where I can't quite remember whether the first version was mine or an AI agent's. That sounds like a confession, and it is — a little. But not in the dramatic way where you close the laptop, stare out over the Aarhus harbour and ask whether the craft is dead. More in the practical way, where you're up at 23:41 with a Firebase rule that won't do what it was told, while the editor politely offers to rewrite half your app.
Here's why I keep building this way anyway — on purpose, every day.
1. I ship alone
There's no team behind my products. No frontend department, no QA, no one whose whole job is asking "did we think about permissions?" There is me, a large cup of coffee, and an AI that never gets tired of explaining TypeScript errors. That last part is more touching than I'd like to admit.
Vibe coding is what makes the solo setup viable at all. A feature that used to be half a day of components, styling and micro-decisions is now a usable first draft in minutes — rarely elegant, rarely finished, but there. And "there" is underrated. The gap between idea and something you can touch is where most side projects die.
2. More shots on goal
Speed compounds into something more valuable than speed: attempts. In the last couple of years I've shipped Quiz Fight, HeadToHead, TaskMondo, Dolphin Beyond, Runish, Nuze and more shipped products — games, SaaS, a news product — as one person. Under the old economics, that list would be two products long, and I wouldn't yet know which ideas deserved the time.
Nobody knows in advance which product finds its users. The workflow that lets you take eight real swings instead of two isn't a productivity hack; it changes what's possible for one person to attempt.
3. It moves the work to the part I'm best at
The funny thing about AI coding: people assume it lowers the bar. My experience is closer to the opposite. When code becomes cheap to produce, judgment becomes the expensive thing. You have to see what's worth keeping, notice when a solution gets too clever, and feel the small grimace an experienced developer makes when a function starts knowing too much about the rest of the system — because the AI will not make that face for you. It just keeps going, like an intern with production access and no natural fear.
I'd rather spend my day on product decisions, data models and taste than on typing boilerplate. I have no romantic attachment to spending half a morning on a modal that closes correctly on Escape. Life is short, and The Office doesn't rewatch itself.
4. Honestly? It's also just fun
Describing a feature concretely — "a mobile-friendly overview of leads, grouped by status, with empty states and a drawer" — and watching a competent first draft appear still feels absurd. That feeling is fuel. Building alone has plenty of grind; a workflow that keeps the momentum (and the delight) is worth protecting.
What this is not
None of this means surrendering the wheel. I don't believe in the version of vibe coding where the developer becomes someone who types wishes into a text field and calls themselves an architect afterwards. I own the architecture, the mistakes, and the uncomfortable gut feeling when something works a little too easily. The workflow exists precisely to keep that ownership — and the limitations are real enough that I wrote them down separately.
Vibe coding isn't a replacement for being able to build software. It's an amplifier. If you have direction, you get absurdly far. I intend to keep going absurdly far — with Cursor, AI agents, React, Firestore, and a healthy distrust of anything that works on the first try.