How to Vibe Code (Seriously)

You've heard about it. You've seen the tweets, the YouTube videos, the LinkedIn posts from people who built an app over the weekend without writing a single line of code. You know the AI tools exist — ChatGPT, Claude, Cursor, Gemini. You've maybe even used them for work or to answer questions. But you haven't built anything. And there's a gap between knowing these tools exist and actually sitting down and creating something from scratch.

This piece is about closing that gap.

I've vibe coded a personal portfolio site, a party game app, a civic engagement platform, and a product development tool. I'm not an engineer. I'm a sales guy who stays curious. And I've learned enough through trial and failure to walk you through the whole process — from the moment an idea hits you to the moment someone else can use what you built.

Fair warning: this is longer than my other Field Notes. Vibe coding has a lot of moving parts, and I'd rather give you the full picture once than leave you stranded halfway through your first project.

Before You Touch a Computer

Most people's first instinct is to open a tool and start prompting. That's the fastest way to build something that breaks on the first hiccup.

Here's what I've learned: AI is extraordinary at executing a plan. It's terrible at creating one from nothing. It's all-knowing and knowing nothing at all at the same time. You have to bring the plan. AI brings the execution. If you skip the planning, you'll spend ten hours untangling a mess that could've been avoided with one hour of thinking.

But before you even plan, you need to know whether your idea is something you can actually vibe code. I use three checks.

Check one: problem sensitivity. You need a real problem. Not a startup idea. Not a billion-dollar market. A real problem you encounter in your daily life — or one that the people around you encounter. Your plants are dying and you want to track watering schedules. You're tired of eating the same meals and want a system that suggests new ones based on what's in your kitchen. You want a personal website but every template feels generic. The problems can be absurdly niche. They should be. Because niche problems are the ones you understand deeply enough to solve.

Check two: differentiation. You need to believe — even a little — that your solution would be different from what already exists. Not better, necessarily. Different. Because that belief is what will push you to actually create something instead of just using someone else's tool. If you want to track your meals and MyFitnessPal does it fine, you probably won't have the drive to build your own version. But if you want to track meals your way — with your categories, your interface, your logic — that's differentiation. That's agency. You have to want to create.

Check three: a tight feedback loop. This is the one most people miss. Vibe coded projects are messy. AI might write 400 lines for something that could be 100. Features break. Things look wrong. The only way to navigate that is constant feedback — and the fastest feedback comes from yourself and the people immediately around you. If you're building a personal website, you're the user. The feedback loop is instant. If you're building something for your friends or family, you can show them and get reactions the same day. If you're building for a million strangers, you have no feedback loop, and the project will stall before it gets anywhere.

These three checks — problem sensitivity, differentiation, tight feedback — narrow your scope to projects you can actually finish. That's the point. The goal isn't to build something massive. The goal is to build something real.

The Planning Phase

You've got an idea that passes all three checks. Now it's time to plan. And the planning happens in a specific sequence that I've refined across every project I've built.

Step one: speak your vision. Open a voice recorder — your phone works fine — or use talk-to-text directly in Claude or ChatGPT. Close your eyes. And describe what you want to build. Not the technical details. The feeling. What does someone experience when they land on your site? What do they see first? How does it flow? What makes it feel like yours?

You close your eyes because you're trying to access imagination, not logic. Speak what you see. Describe the colors, the layout, the vibe. Be as specific or as abstract as you want. The AI will structure it later. Right now you're capturing the essence — the raw source material that every subsequent step builds on.

Before you close out the prompt, add one more thing: ask the AI to search the web for inspiration. Is there anything out there that resembles what you described? Any open-source projects on GitHub that could serve as a starting point?

Step two: sample. Musicians don't create every sound from scratch. They sample. Beats from the '50s get reborn in tracks from the 2020s. Vibe coding works the same way. Go look at websites, apps, and GitHub repositories that do something close to what you're building. Take screenshots. Fork repos. Grab anything that captures the look, feel, or structure you're going for.

Your sample doesn't have to be code. Screenshots are fine. Design references are fine. If you can't find exactly what you're picturing, draw it — open Procreate on an iPad, grab an Apple Pencil, or just sketch it on paper and take a photo. A rough wireframe drawn by hand tells AI more than a paragraph of description. You're trying to build your idea in as many mediums as possible — voice for the concept, visuals for the design, and if you can find actual code on GitHub that's close to your vision, even better. That's a head start, not a shortcut.

Step three: get your tech stack. Take your transcript and your samples, feed them both into Claude or ChatGPT, and ask: "Given what I want to build, what technologies should I use?" Tell it your priorities — do you want it to be fast? Easy to build? Scalable? The AI will recommend a combination of tools.

For most projects, you'll land somewhere near this: Cursor as your AI code editor ($20/month), Next.js or Astro as your framework (free), Supabase for your database if you need one (free tier), Vercel to host it (free tier), and GitHub to store and version your code (free). Total cost to start: $20-40 a month. This stack dominates for a few reasons — the tools integrate seamlessly, they all have generous free tiers, and AI models have been trained extensively on this exact combination, so they produce better code when you use them together.

Step four: build the blueprint. Now you take all three pieces — your voice transcript, your samples, your tech stack — and you feed them into a new AI chat. You say: "With these three inputs, create a comprehensive blueprint for this project." The AI synthesizes everything into one document — a markdown file or PDF that covers the structure, the features, the technical approach, and the sequence of what gets built when. This is your project's foundation.

Step five: harden the blueprint. This is the step that separates projects that survive from projects that collapse. Open a fresh chat — you want clean context, no memory from the previous conversation muddying things. Use the best model you can access (Claude Opus, GPT-5, whatever's at the top). Feed it the blueprint and your original voice transcript. And say: "Before we start building, I want you to review this blueprint and make it bulletproof. Identify everything that could go wrong. Find the gaps. Harden it."

The AI will come back with a refined blueprint — version two. Read it. If something's off, iterate. Get a version three. Keep going until you're confident. This is your skyscraper's foundation. Months of planning before shovel hits dirt. You haven't written a single line of code yet, and that's exactly right.

The Build

Now you're ready. Almost.

Before you dive in, take an hour and get familiar with the tools you're about to use. Cursor has a getting-started guide. GitHub Skills offers a free interactive course that covers the basics in under an hour. Vercel's docs walk you through your first deployment step by step. You don't need to master any of these — you just need enough orientation that the first time the AI tells you to "push to GitHub," you're not staring at the screen wondering what that means. Think of it like glancing at a map before a road trip. You'll still use GPS, but it helps to know the general terrain.

Now you're ready.

Set up your workspace. Download Cursor from cursor.com. Create an empty folder on your desktop — that's your project. Open the folder in Cursor. That's it. An application, at its core, is just a hierarchy of files in a folder. The compiler and the browser turn those files into what you see on screen, but what you're building is documents in a directory.

Split your screen: Cursor on one side, Claude on the other. You're going to use them as a team.

Get your playbooks. In Claude, open a new chat. Upload your blueprint, your original transcript, and any critical documents the AI generated during planning. Then say: "I have Cursor open on an empty folder. Provide me a series of playbooks that get me from an empty project to the final vision. The first playbook should cover all prerequisites — everything I need to do before my first prompt in Cursor."

Claude will break your build into phases — playbook one, two, three, four, however many it takes. Think of each playbook as a sprint with a focused scope: playbook one might be prerequisites and project setup, playbook two the core layout and navigation, playbook three the main feature, playbook four the polish and deployment. Together, this first series of playbooks is your initial build cycle. Download them. Put them in your project's root folder. Now Cursor can see them too.

Run the dual-AI loop. This is the core mechanic. Go to playbook two (playbook one was your prerequisites), take the first prompt, and enter it in Cursor. Cursor writes the code, creates files, installs dependencies. When it's done, it gives you a summary of what changed. Copy that summary. Paste it into Claude. Claude reads it, confirms it's tracking with the plan, and gives you the next prompt. You take that prompt back to Cursor. And you cycle.

You are the orchestrator. Claude is the architect. Cursor is the construction crew. You're passing context between them, making sure the architect's vision matches what the crew is building. This dual-AI pattern is how experienced vibe coders work — it's been documented by Stormy AI, Stark Insider, and others as a recognized professional workflow.

Be intentional between every playbook. This is where the human element matters most. After finishing a playbook — not the whole series, each individual playbook — stop. Open your terminal in Cursor (Ctrl + backtick) and type npm run dev. This launches a local development server — your project, running on your own computer at localhost:3000. Open that in your browser. You're looking at what you just built.

This is where two screens help. One screen for your split between Claude and Cursor. The other for your localhost. Now take a screenshot. Throw it into Claude. Say: "We just finished playbook two. Here's what it looks like. Here's what needs to change before we move on." Be specific. Not "it looks wrong" — more like "the text in the hero section is too large on mobile" or "the navigation menu isn't collapsing into a hamburger on smaller screens."

That vocabulary matters, by the way. A carousel is a sliding image gallery. A modal is a popup overlay. A skeleton component is a loading placeholder. A toast is a brief notification that appears and auto-dismisses. A hamburger menu is those three horizontal lines. Learning the correct names for UI components makes your prompts dramatically more precise — and precise prompts produce better code. Sites like component.gallery catalog every common component with its standard name.

And when the issue isn't vocabulary but quality — when your project works but just doesn't look polished, and you can't pinpoint why — lean on design systems. The best companies in the world publish theirs openly. Apple's Human Interface Guidelines document every design decision behind iOS and macOS — spacing, typography, color, motion, the logic behind why things feel the way they feel. Google's Material Design does the same for Android and web. The GOV.UK Design System is a masterclass in clarity and accessibility. These aren't coding resources. They're taste resources. They show you what intentional design looks like at scale, and they give you the language to describe what's off about your own project. If your app feels clunky next to Duolingo or Airbnb, it's often because those teams follow documented design principles around hierarchy, whitespace, and consistency — principles you can study and feed directly into your AI prompts. "Follow Apple's Human Interface Guidelines for spacing and typography" is a prompt that produces dramatically different results than "make it look better."

The discipline is this: do not move from playbook two to playbook three until playbook two is right. Refine it in Cursor, check it in your browser, confirm it with Claude. This is your quality gate. AI doesn't care about quality — it'll happily build on top of a broken foundation. You're the one who has to enforce standards at every step. The human element is what makes this process work. Without your intentionality between playbooks, you're just generating code. With it, you're building something.

Refine until playbook two is right. Then move to playbook three. Cycle again. After each playbook: test, screenshot, feedback, refine, confirm, then — and only then — advance.

The Critique-and-Harden Cycle

Here's what nobody tells you about vibe coding: when you finish your first series of playbooks, your project will be nowhere near where you want it to be.

This is normal. This is the process.

You'll realize coding is harder than you expected. Things will have broken. It probably took you ten hours for something you thought would take two. You'll question whether you should even keep going or start something new.

Keep going. Here's what you do.

Push your code to GitHub — now you have a public repository, a saved version of everything you've built. Then open a fresh Claude chat. Upload your code files, your original transcript, your blueprint. And be your own harshest critic. Go through every feature, every page, every interaction. Not to destroy what you've built — but to see it clearly for what it is and what it isn't yet. Call your baby ugly if you have to. The point isn't demolition. It's honest assessment. What works? What's broken? What doesn't match the vision? Where did the AI cut corners? Where did you?

Then say: "Given this feedback, create a new series of playbooks to get this project where it needs to be."

Now you have your second series of playbooks — built on everything the first series accomplished plus everything your critique revealed. Run the same process: execute each playbook through the dual-AI loop, be intentional between each one, enforce your quality gates. When this series is done, critique again. What improved? What's still off? What new issues emerged? Feed that critique back in and generate a third series if needed.

Each series of playbooks is a big sprint. Each individual playbook within the series is a small sprint. The big sprints harden the project at the macro level — overall architecture, feature completeness, design coherence. The small sprints harden it at the micro level — specific components, individual pages, particular interactions. Together, they create a cycle: build, critique honestly, harden, build better. Every pass through this cycle, the scaffolding turns a little more into concrete.

You can also bring in other AI tools at this stage. Gemini can ingest your entire GitHub repo in one conversation and review it like a senior engineer. You can ask it to find security issues, suggest architectural improvements, or critique the user experience. Different models see different things.

Start With a Penny

One last thing, and it might be the most important.

Start small. Absurdly small.

Don't start with your dream project. Start with something you can finish in a weekend while you're still learning what npm run dev means and how to push to GitHub and why your deployment failed because you forgot to add environment variables to Vercel.

Build a simple game. A single-page calculator. A personal landing page with nothing but your name, a photo, and three links. The project doesn't matter. The process matters. You're learning the workflow: empty folder → planning → playbooks → dual-AI loop → localhost → GitHub → deploy.

Once you finish that first tiny project and it's live on the internet, you'll understand the whole pipeline. Then scale up. A penny for a nickel. A nickel for a dime. A dime for a quarter. Each project gets a little more complex — maybe a database, maybe user login, maybe multiple pages, maybe an API integration.

By the time you get to the project you actually care about, you'll know the tools, the vocabulary, the workflow, and — most importantly — the feeling of shipping something. That feeling is what keeps you going when playbook three breaks everything and you're staring at error messages at midnight.

The Pattern

Vibe coding isn't magic and it isn't easy. It's a process. Identify a problem. Make sure it's niche enough, differentiated enough, and close enough to you that you can get fast feedback. Plan obsessively before you build — voice your vision, sample and sketch inspiration, get your tech stack, create a blueprint, harden it until it's bulletproof. Build with two AIs working in tandem — one thinking, one doing. Be intentional between every playbook. Critique honestly after every series. Start small and scale up.

The tools cost less than a gym membership. The real cost is time, patience, and the willingness to be bad at something before you get good at it.

But if you've got an idea — something you wish existed, something that solves a problem nobody else is solving quite the way you'd solve it — know that the only thing between you and a working version of that idea is the process I just described. The tools are ready. The open-source community is generous. The AI is better than it's ever been.

You just have to start. And if the problem is real enough and your solution is different enough, you might be surprised how far it goes. Pieter Levels vibe coded a flight simulator in three hours that hit a million dollars in revenue in seventeen days. Open-source projects built by solo developers have reached thousands of users overnight. The ceiling on what one person can build with these tools hasn't been found yet.

So start with the penny. See where it takes you.