Vibe coding: what it is and why most builders do it wrong

Vibe coding is building software by describing what you want in plain language and letting AI turn those words into working code. Andrej Karpathy coined the term in early 2025. By year end, Collins Dictionary named it their Word of the Year. Every major tech company now has a page explaining what it is.

What none of them explain is what separates the people who ship real things with it from the people who end up with a mess.

Vibe coding vs. AI coding: the distinction nobody makes

Here is how I think about it after a year of building solo with AI.

Vibe coding, in the way most people mean it, is when you have no idea what you actually need. You describe something, the AI writes something, you accept it and move on. Repeat. At the end you have an app. Maybe. But the codebase was never planned, security was never considered, the architecture cannot scale, and fixing it means starting over. That is the vibe coding you see on social media: fifteen minutes to an app, five months to a disaster.

AI coding is different. You still describe what you want in plain language. You still let the AI write the code. But you know what questions to ask. You know what a good architecture looks like. You know where security risks live. You catch the GDPR gap before it ships. You direct the AI the way a senior developer directs a junior one: with intent and judgment, not just vibes.

The tool is the same. The domain expertise is what changes everything.

What one person can actually build

The clearest example I can give is this website. I rebuilt christianstrunk.com completely with Claude Code. Every layout decision, every piece of the blog and journal system, every pixel of the design. One person, one AI, a codebase I can explain line by line. Every visitor of this site can see the result: it is handcrafted, not generated.

The second example is the Brain: a full Postgres backend to run my entire business. The architecture planning is in Journal episode 003. What I actually shipped is in episode 006. A real backend engineer reviewed the output and said it was solid. The whole architecture, the tools I used, and every prompt I built it with live on the Brain map.

A team would have spent weeks or months on the same backend. I built it solo because I knew what I needed to build. That knowledge did not come from the AI. It came from thirteen years of product management.

The real skill floor

People say you do not need to know how to code to vibe code. That is mostly true. It is also where the conversation stops, and that is the problem.

The skill floor is not coding. It is domain expertise. Specifically:

• Knowing what questions to ask about security before anything ships
• Understanding how user authentication should work at a basic level
• Knowing what GDPR compliance means for data you collect and store
• Recognizing when an architecture decision will hurt you in three months
• Being able to read the AI's output and notice when something smells wrong

These are product questions, not engineering questions. Experienced builders catch them because they have shipped things before and know what breaks. Vibe coders without that background miss them, not out of carelessness but because they do not know what to look for.

The AI builds what you ask for. Your job is knowing what to ask for. And knowing what to ask for takes years to develop, whether you write code by hand or not.

This is also why I think most "anyone can build apps now" takes are only half right. Anyone can get an app running. Fewer people can build something that holds up, that does not leak data, that a real user can trust. That gap is where domain expertise lives.

The early refactoring habit

One concrete thing I do on every project: at the start, I open a fresh chat, paste in the codebase, and ask Claude to act as an independent senior software architect doing a code review. No context from the build session. No sunk-cost thinking. Just clean eyes on the structure.

It finds things the build session misses. A naming inconsistency, a file that needs splitting, a security assumption that wants confirming. It takes twenty minutes and it is the best use of those twenty minutes.

I do this at project setup, then on a regular cadence as the codebase grows. Not when something breaks. Regularly, on purpose, before anything breaks. This single habit separates AI-coded output that holds up from output that looks fine until it does not.

If you take one practice from this article, make it this one.

Learn to throw things away

My prototyping process: build it in an HTML file first. If I like it, I move it into the real project. If I do not, I delete the file and move on.

I throw things away all the time. This used to feel like failure. It is not. It is the method.

Before AI, prototyping was a sprint. A week of design, a week of build, a demo, a decision. By that point you were too invested to throw it away even if it was wrong. Now prototyping takes ten minutes. The cost of a bad idea is one deleted HTML file. So I prototype more, kill more ideas earlier, and the things that survive are the ones that actually work.

The best vibe coders I have seen have learned this: move fast, commit late, throw things away without grief. The AI makes the prototype cheap. Your judgment makes the product good. Both have to be present.

Vibe coding tools: what actually works

Not all AI coding tools are equal, and the choice of tool shapes the quality of what you ship.

I use Claude Code. It runs in the terminal, it has direct access to the filesystem, and it keeps context across long sessions in a way that feels like working with a junior developer who actually remembers what you agreed on last hour. For a solo builder managing a full codebase alone, that continuity matters.

For prototyping and quick experiments I sometimes start in a single chat window: describe the idea, get a working HTML file, decide if it is worth building for real. When it is, I bring it into the main project and work from there with Claude Code.

Tools I have seen others use: Cursor (IDE-native, strong for developers who want to stay in their editor), Replit (good for fast deployment without setup), GitHub Copilot (best when you are still writing a lot of the code yourself and want inline suggestions). Each has a different model of how much you direct vs. how much the AI leads. More direction = better output, which brings us back to domain expertise.

The objection worth addressing

"I am not technical enough to do this properly."

You probably are, if you have built products or run a business. The gap is not coding skill. It is product thinking: knowing what problem you are solving, who it is for, what the failure modes are, and what done looks like.

Those questions are harder than writing code. Most engineers never have to answer them. They get handed a spec. If you have spent time talking to users, defining requirements, deciding what not to build, you already have the more important half of the skill set. The AI has the other half. Put them together.

If you want to build something real, solo, with AI, alongside other people doing the same thing every Friday, you can become a Product Baker and ship your next project with the rest of us.