What is Vibe Coding?

Vibe coding is a fast growing trend where developers use AI tools to generate functional code by simply describing what they need in plain language. Instead of manually writing every line, they rely on AI to translate natural language into executable code.

The term Vibe coding originates from a post on X by Andrej Karpathy, an influential AI expert known for his work at Tesla and OpenAI, where he explains the concept as:

This approach has gained so much traction because vibe coding offers some real advantages – especially for solo developers and fast-moving teams when the right ai tool is used.

The main benefits of vibe coding include:

1. Speed – Vibe coding automates repetitive tasks like setting up files, writing boilerplate, and handling basic data logic.
2. Creativity – With routine coding out of the way, you can focus on design, user experience, and solving real problems.
3. Accessible for beginners – No need to learn syntax first — just describe what you want, and the AI builds it.
4. Easy to iterate – Quickly test changes by tweaking your prompts instead of rewriting code manually.
5. Fast prototyping – Great for turning ideas into working demos without getting stuck in the technical details.

This all sounds great, so what's the problem?

To be clear, vibe coding is great, but it's not entirely as straight forward as some think. People tend to think they can just open up an IDE such as VS Code (with copilot agent or the Continue extension), cursor, windsurf or Zed (among others but these are my favorites to use, mostly Windsurf lately) and ask it to build something but that's not how to achieve success with it.

The biggest problem is relying on the IDE to do all the work while not giving it clear instructions.

Instead, the process I find works best is if I look at the IDE as my junior developer and use the following steps to build out projects, not unlike planning out a project for a team to work on, but in this case, the team is myself and my IDE.

Step 1: The PRD

Before doing anything else, we need to create a Product Requirements Document (PRD), this will help tell the IDE what we are building, this is the same as if you were planning a software project with a team.

We will create a PRD that explains what you’re building, why, the user flows, in-scope / out-of-scope items, and a short tech-stack overview.

For the first step, I don't even open my IDE, I go straight to chatGPT (using gpt-4o or gpt-4.1) or Claude and use the following prompt:

I am building a [describe your product, the more detail the better]. 

Use Astro for frontend, Supabase for DB and auth. 

We are going to create the Product Requirements Document.

Give me the full architecture:
- File + folder structure
- What each part does
- Where state lives, how services connect

Format this entire document in markdown

After the AI has generated the necessary info, I save the response as prd.md and throw it in the folder where I want my project to live.

Step 2: The Tasks

Next, we need our tasks, just like if I were planning this project out with a team to work on, I need to break the project down into smaller tasks.

With that in mind, in the same window, I type:

Using that architecture, write a granular step-by-step plan to build the MVP.

Each task should:
- Be incredibly small and easily testable
- Have a clear start and end
- Focus on one concern to a time

I'll be passing this off to an engineering LLM that will be told to complete one task at a time, allowing me to test in between.

I then save that response as tasks.md, and throw it in the same folder I used in step 1.

Step 3: The Actual Work Begins

Now that we've got our prd and our tasks, then the work can begin.

Now I finally open Cursor or Windsurf in that same folder and use this prompt:

You are an engineer building this codebase. You have been given docs/prd.md and docs/tasks.md.
- Read both carefully. There should be no ambiguity about what we are building.
- Follow tasks.md and complete on tasks at a time.
- After each step, stop. I'll test it. If it works, commit to GitHub and move on to the next.

As context, I include the prd.md and tasks.md files, along with any screenshots, designs, etc that might be needed, the more info the IDE has, the better.

I also include these instructions as well - this is a critical step!:

### CODING PROTOCOL ###
Coding instructions

- Write the absolute minimum code required
- No sweeping changes
- No unrelated edits: focus on just the task you are on
- Make code precise, modular, testable
- Do not break existing functionality
- If I need to take any action (for example: Supabase, Stripe, AWS config, vercel config), tell me as clearly as possible what I need to do.

Now it will start work and you'll see your app get created step by step.

A Note About IDE AI Rules:

If I find myself needing to add more .md files, such as testing, schema, etc then I usually create a docs folder inside the project folder and move all .md files in there.

Then I add a rule to .cursor/rules or .windsurfrules, encouraging the AI agent to "always read the docs folder before writing any code":

Refer to all documents in the /docs directory for context before proceeding with code generation.

Final thoughts

That's it, these 3 simple steps are what I use to vibe code and in my humble opinion, this system fixes the biggest problem with vibe coding:

1. You are not dumping everything into the IDE and praying.
2. You are giving it a roadmap to follow.
3. You are keeping it on rails.
4. You are still in control.

This workflow lets you ship clean, testable AI-assisted code - without the spiral.

Bonus Feature: AI IDE rules (.cursor/rules or .windsurfrules)

One of the highest-leverage moves you can make when working with AI coding agents like Cursor or Windsurf is to define clear, project-specific rules.

Think of rules as your agent’s operating manual: the clearer it is, the better your results.

At the start of every project, create a concise rules file: .cursor/rules or .windsurfrules, that guides how your AI pair programmer should behave. These rules act as a standing context layer that supplements every prompt, saving you from endless re-explaining and firefighting.

Here’s what great rules include:

• Your project-specific guidelines such as “Always prefer strict types over 'any' in TypeScript”
• Tech stack details: tell your agent what you're using: Astro, Supabase, etc. so it stops making incorrect assumptions
• Known pitfalls and fixes: add proactive corrections here if you notice recurring errors (e.g., Cursor defaulting to the wrong Nodejs version)
• High-level project overview: summarize the purpose, major functionalities, and key files (you can link to your prd.md here, see previous section).

Use .md reference files alongside rules for better modularity. For instance, we once spent a full day as a team designing our testing philosophy, captured it in testing.md, and added a simple rule: Refer to testing.md when writing tests.

Another rule that dramatically boosted my high-stakes coding sessions:

For any complex or critical task, ask any and all clarification questions needed before proceeding.

Cursor recently introduced a /Generate Cursor Rules command, allowing you to instantly create new rules based on the current chat context, which is particularly useful after a significant architecture change or a project refactor.

Extra resources:

• Browse and reuse existing community rules: Cursor Directory, and Playbooks Rules
• Build your own rules easily: Playbooks Rule Builder