What is vibe coding

Vibe coding is a way to build software without writing code. The idea and the decisions are yours. The building belongs to the agent. You describe what you want and why. He builds it. Usually not on the first try, but that’s what the work is. You read what came out and decide what stays and what gets thrown away.

I have one way of thinking about it that works for me. I’m the driver and I run this show. The agents are a team of mechanics who take care of the engine and everything under the hood. I don’t build a car to know how to take apart a motor. I build it to win the race. I can have five mechanics at once, but I’m the only one holding the wheel.

It’s not magic or a shortcut. It’s a way of working. I’m not the one writing lines—I’m the one giving tasks, reading the output, and saying “not like that, again, and this time differently”. A huge part of the work is being able to describe exactly what should come out, and then reading it critically. Anyone who can do that doesn’t need to know syntax.

Important detail so you get the picture right. I’m not sitting at some black terminal typing commands. I have a normal app on my computer and I type into it like a chat. I say what I want, and Claude handles the rest on his own. I give tasks and I check.

And one more thing, so it doesn’t sound like an ad. I know I’ll sound enthusiastic at times. It’s really not paid. This way of working just saved me real time in the last few months and I want to share it. If you hit a sentence that reads like a miracle, something’s off—take it that way here too.

If you want one ladder to get your bearings on, I split it into three tiers. The bottom tier is vibe coding itself: I describe the vibe and the goal, the agent works through it, I mostly look at the result. The middle tier is working with AI as a smart helper, where I understand more about what’s being built. The top tier is agent engineering, where I build whole teams of agents working together. I move around the top, but I started at the bottom. You can start anywhere.

Installation

The beginning is boring and that’s good. No server setup, no installing ten things. You download one app and log in.

I run Claude Code, which is a tool from Anthropic. It exists as a desktop app for Windows and Mac. Not on Linux yet. You download it from claude.com/download. I work in the Windows version because I live on Windows normally. The whole thing works like a regular program in a window.

To get started, you need an account and a subscription. A cheap way in is the Pro plan at 20 dollars a month. Claude Code and Cowork come straight in. I myself run on the Max plan for heavier use, that comes to about 100 dollars a month. You don’t need it to get your bearings though. You don’t have to pay for the most expensive plan right away. You can start cheap and move up when you hit a limit.

You don’t have to think about hardware. Any regular PC will do, as long as the internet and office stuff work on it. All the heavy work runs at Anthropic on their machines, not on your computer. You just see the window on your screen where you type.

Recommended setup

Here’s the most common mistake you can make right at the start. You want to get everything perfectly set up before you even build anything. Don’t do that. You don’t need your own rules right away, ten connected services and smart automations. You add those when you know what you need them for.

The first thing I’d think about is the model. The model is the brain under the hood and it comes in a few sizes. For hard and long work I run on the biggest one, it’s called Opus. It can handle the most, but it’s also the slowest and the most expensive. But you can start with a faster and cheaper model when you’re getting your bearings. When a task is too much for it, you switch up. Surprisingly often it’s enough.

The second thing is even nicer. You don’t have to set much up yourself. You tell Claude what you want and he sets it up himself. For example there’s a file with rules for a project—it’s called CLAUDE.md—where Claude makes notes on how to act in that project. You don’t write it by hand. Either it’s already there, or you tell Claude “look through this project and set up rules for yourself” and he does it. Same way he keeps his own notes so he doesn’t forget between sessions where you left off.

For a complete start this is plenty: the app, logging in, the model, and letting Claude set the basics himself. When you want to go deeper—your own rules, connected services, hooks—I have a whole section on My setup where I show you how I actually have it all put together.

First project

The best first project is small and yours. Something you’d actually use. A small tool that saves you tedious manual work. A simple page. A script that rearranges a table. Don’t start by building a plane.

How it works in practice: you tell Claude in human language what should be built. He builds it. You look at the result and tell him what’s wrong. He fixes it. This loop—I describe, I read, I send back for rework—is the whole heart of vibe coding. You’re not hunting for bugs in code. You’re looking for the difference between what you wanted and what you see.

I won’t pretend it works on the first try every time. Sometimes the agent thinks of something a little different than what you meant and it goes off the rails. It happens to me all the time. What works: break the task into smaller steps and look at the result after each one. If you give one big instruction and it breaks, you don’t know where. If you give five small ones and the third breaks, you know exactly what to fix.

And one more habit worth having from the start. Everything that gets made is versioned—saved so you can go back to any earlier version. If something goes wrong, it’s not the end of the world, just go back one step. Because of that you don’t have to be afraid to try things. A bad attempt can be thrown away.

This is just the beginning. Try building one small thing and see if it clicks for you. When you want to know how I have it all set up in depth, go on to What I use and How I work.