Vibe Coding: When AI Writes Your Apps

After thirty years of writing software for a living, I wasn’t sure I needed a new way to build it. Then I tried describing what I wanted instead of coding it. What surprised me was not the output. It was the kind of software I bothered to build.

What I wasn’t prepared for was the vertigo. If a prompt and twenty minutes could produce what used to take me a week, what exactly had I been selling all that time? The question wasn’t whether the tools worked. The question was what they made of me.

A subscription bundle gave me access to Lovable, Replit, Bolt, v0. I’d been writing code since the nineties. I was sceptical, frankly. My first attempt produced a periodic table that was functional, technically correct, and completely without soul. I was burning credits on vague prompts and getting vague apps back. Thirty years of engineering instincts counted for nothing. This was a different skill, and I was starting from zero.

The difference looks like this. My first prompt: “Build me an interactive periodic table.” What I got back was generic. Months later, I’d learned to write something closer to: “An interactive periodic table. 118 elements, color-coded by category. Glassmorphic UI with frosted glass cards and backdrop blur. Click for detail dialog with electron configuration. Hover tooltip that repositions near screen edges. Dual-thumb range sliders for filtering by atomic mass, electronegativity, density. Responsive sidebar that collapses to a drawer on mobile.” Every sentence in that second prompt is a constraint that removes one more place for the tool to improvise badly.

Vibe coding is not conventional programming. It is not plain English either. It sits somewhere between the two: a compressed requirements document delivered as conversation. Knowing what to ask for is easier when you’ve built it by hand before. Knowing how to ask? That took months.

Five experiments

The way I used to read a book a week, I now build an app a week. Dozens of them over the past year, most variations on the same themes, explorations more than products. I picked five for this series because each one landed a different lesson. A drill app, a reference tool, two personal utilities, a trip planner. Different tools, different scales, different kinds of friction. What they share is the same question: what happens to the developer when the tool does the building?

Why this series exists

For me, the economics of personal software changed. Personal tools still existed, of course, but the build-and-upkeep cost usually killed anything more ambitious than a spreadsheet.

That constraint is different now. I know people building weekend tools for personal use, for small groups, for moments that will not come again. Not startups. Not products. Something the old economics had no room for. The same compression that caused the vertigo created the space.