The Definitive Guide · 2025
Vibe
Coding
How intent, intuition, and AI collaboration are reshaping the way software gets built
Vibe coding is a new mode of programming where you describe what you want in natural language, and AI handles most of the implementation — while you steer, critique, and refine the result.
It's less about knowing syntax and more about knowing what you want. Part craft, part instinct, part conversation.
10×
Faster prototyping
Creative ceiling
0
Barriers to entry
The systems that should be solving the world's biggest problems aren't. This is the definitive guide to building the solutions yourself.
THE COMPLETE SERIES Included in The Complete Series ($29).
— 01

What Is Vibe Coding?

Vibe coding is the practice of building software by communicating intent — in plain language, sketches, or examples — and iterating with an AI that writes, edits, and explains the code.
— Emerging practice, coined ~2024

The term was popularized by Andrej Karpathy in early 2025, who described it as surrendering to the AI and not really reading the code — just describing problems, pasting errors, and asking for fixes. But vibe coding has already evolved past that pure definition.

In practice, it exists on a spectrum. At one end: complete novices building things they couldn't code before. At the other: experienced engineers dramatically compressing their development cycle by speaking instead of typing.

What unifies both is the shift from implementation-first thinking to intent-first thinking. You describe the destination; the AI finds the path.

The Core Shift
Traditional coding: you think in code.
Vibe coding: you think in outcomes.

The AI becomes your translator — converting your mental model of what software should do into actual working implementation.
What it's not
Vibe coding isn't magic, and it isn't a replacement for all thinking. You still need judgment, taste, domain knowledge, and the ability to evaluate whether what the AI produced actually solves your problem.
— 02

The Six Principles

01
Intent Over Implementation
Start with what you want the software to do, not how it should do it. The AI handles syntax, patterns, and boilerplate. You handle vision.
02
Iterate Relentlessly
The first output is rarely the final one. Treat every response as a draft to critique. The best results come from rapid back-and-forth refinement cycles.
03
Context is Everything
The richer the context you give — purpose, constraints, audience, examples — the better the output. Garbage in, garbage out applies doubly to natural language prompts.
04
Verify What Matters
You don't need to read every line, but you do need to run the code, test the behavior, and understand enough to know when something is subtly wrong.
05
Own the Architecture
Let the AI write components; own the high-level structure yourself. The most dangerous vibe coding mistake is delegating the overall design to something that can't hold your whole problem in mind.
06
Use Your Taste
Taste is the skill that doesn't transfer to AI. Knowing when code feels bloated, overly complex, or going in the wrong direction is purely human. Protect and use it.
— 03

The Workflow

1. Define the Destination
Before touching a prompt, write down — even roughly — what success looks like. What will this do? Who uses it? What does the happy path feel like? This clarity will shape everything that follows.
2. Scaffold with a High-Level Prompt
Start big. Give the AI the full picture: tech stack, purpose, key features, constraints. Ask for the structure first, not the details. A good skeleton makes everything else easier.
3. Run It Immediately
Don't wait until everything looks perfect to test. Run what you have. Seeing it fail in a concrete way gives you real feedback to work with. Errors are information.
4. Refine in Focused Loops
Work on one problem at a time. Don't try to fix everything in one prompt. Focused, specific requests consistently outperform sprawling multi-part asks.
5. Pause and Review Architecture
Every few significant changes, step back. Read the structure — not every line, but the shape. Is it growing in the right direction? Would adding the next feature be painful or natural?
6. Harden What Survives
Once something works and you want to keep it, understand it. Add tests. Add comments. Make it yours. Vibe-coded output that you haven't internalized is a liability.
"The bottleneck isn't typing speed or knowing APIs. It's knowing what you want clearly enough to ask for it."
Example: Opening Prompt Structure
# Context I'm building a task management web app for a small dev team (5-10 people). Stack: React + TypeScript + Tailwind. # Goal (this session) Create the core data model and a basic kanban board UI with 3 columns: Todo, In Progress, Done. # Constraints - No backend yet, use localStorage - Mobile-responsive - Keep it simple — we'll add features later # Output format Give me the full component structure first, then implement Board.tsx.
Pro Tip
Always tell the AI what not to do. Constraints are as powerful as instructions. "Don't add a backend," "keep this under 100 lines," and "don't introduce new dependencies" save you enormous amounts of cleanup.
— 04

The Art of Prompting

Good prompting for code is a skill. It's not about magic words — it's about communicating your mental model clearly enough that the AI can reconstruct it.

The anatomy of a great prompt

[CONTEXT] I have an Express.js API with user auth via JWT stored in httpOnly cookies. [TASK] Add a rate-limiting middleware that allows 100 requests/min per IP, with stricter limits (10/min) on auth endpoints specifically. [CONSTRAINTS] Use in-memory storage (no Redis yet). Don't touch existing middleware order. TypeScript, Express 4.x. [FORMAT] Give me the middleware file and show me exactly where to insert app.use() calls.
Context — what already exists
Task — exactly what you want added or changed
Constraints — what to avoid or preserve
Format — how you want the output shaped

Prompt patterns that work

The Before/After
"Here's what I have: [code]. Make it do [X] instead. Keep the same overall structure."
The Error Whisperer
"I'm getting this error: [paste full error]. Here's the relevant code: [code]. What's wrong and how do I fix it?"
The Rubber Duck
"I want to do X. I'm thinking of approaching it by doing Y. Does that make sense, or is there a cleaner way?"
The Explain-Back
"Before you write the code, explain the approach you'd take. I want to make sure we're aligned."
The Constraint Setter
"Do not add new dependencies. Do not change the function signature. Do not use classes. Only modify the logic inside [function name]."
— 05

The Toolkit

Tool
What it's for
Best for
Cursor
AI-native code editor. Has full codebase context, inline editing, chat sidebar. The flagship vibe coding environment.
Most popular
Claude
Long-context reasoning and code generation. Excellent for architecting, explaining, and complex multi-file changes. Can produce full working apps in artifacts.
Deep reasoning
GitHub Copilot
Inline autocomplete inside VS Code and JetBrains IDEs. Lower friction for line-by-line assistance during traditional coding flow.
IDE native
Claude Code
Terminal-based agentic coding. Can autonomously read your codebase, run commands, write and edit multiple files, and complete complex tasks end-to-end.
Agentic
v0 by Vercel
Generates full UI components with React + Tailwind from text or image descriptions. Instantly deployable to Vercel.
UI/frontend
Bolt / Replit
Browser-based full-stack app builders. Describe the app, get a running preview in seconds. Good for prototyping without a local dev setup.
No setup
Windsurf
Agentic code editor that can plan and execute multi-step tasks across your codebase. Competitor to Cursor with different UX philosophy.
Agentic
Stack Recommendation
For most people starting out: use Claude for planning, architecture, and complex reasoning — then use Cursor for in-editor iteration. For fast throw-away prototypes, Bolt or v0 can get you to something clickable in minutes.
— 06

The Pitfalls

🪤
The Vibe Debt Spiral
Moving too fast without understanding what's been built. Each patch makes the codebase more fragile, until changes start breaking unrelated things. The fix: periodic review and refactor sessions.
🎭
Hallucinated APIs
AI models confidently use methods, packages, or configuration options that don't exist. Always verify anything unfamiliar against actual documentation before trusting it in production.
📦
Dependency Bloat
AI loves adding packages. Left unchecked, it'll add 5 libraries to solve a problem you could fix in 10 lines. Always ask: "Can we solve this without adding a dependency?"
🔒
Security Blind Spots
Vibe-coded apps often skip input validation, expose sensitive data, or use insecure patterns. Security doesn't naturally emerge from speed. Build a checklist and apply it before shipping anything user-facing.
🔁
The Edit-Undo Loop
Asking for change A, then change B that undoes A, then asking for A again. Happens when you don't checkpoint working states. Use git commits aggressively — before every significant AI-generated change.
🌫️
Context Drift
In long conversations, the AI forgets earlier decisions and starts contradicting itself. When a session gets long, start a fresh one with a summary of what's been built and the decisions made.
— 07

The Philosophy

You are still the engineer
Vibe coding doesn't remove the need for engineering judgment — it moves where that judgment is applied. Instead of thinking about syntax and APIs, you think about architecture, user needs, tradeoffs, and quality.
The skill floor dropped. The ceiling didn't.
Beginners can now build things that would have taken months to learn. But expert engineers with deep taste and domain knowledge still produce dramatically better results than novices who just prompt. The gap between good and great hasn't closed.
Taste is the new typing speed
In the old paradigm, typing fast and knowing syntax mattered a lot. In the vibe coding paradigm, the scarce resource is judgment: knowing what good looks like, recognizing when something is subtly wrong, and having the taste to push past "works" to "elegant."
Understanding still compounds
The engineers who get the most out of vibe coding are those who understand what's underneath. Every concept you truly grasp makes you a better prompter, a sharper reviewer, and someone who can catch the subtle bugs that only surface under load or edge cases.
"The question isn't whether to use AI to code. It's how deeply to understand what it builds for you — and where understanding matters enough to demand it."
Why this matters beyond speed

The systems we've relied on — healthcare, education, community infrastructure, civic participation — are failing faster than institutions can fix them. For most of history, building the tools to address that required a team, capital, and years. That window has closed.

The person who has lived closest to the problem is now the person best placed to build the solution. Not a startup. Not a product roadmap. A tool — built with whatever time you have, for the people who need it most.

Vibe coding is not interesting because it makes software development faster. It's interesting because it makes it possible for people who have never been able to do it before. That's the change worth building toward.

— 08

Start Today

The best way to understand vibe coding is to do it. Here's a minimal path to your first real session — starting not with the tool, but with the thing that matters:

01
Pick something that needs to exist
The best first project is something you've wished existed — for yourself, your community, or people you know. Motivation from a real problem outlasts curiosity every time.
02
Write down what success looks like
2–3 sentences. What does the finished thing do? Who uses it? What's the simplest version that would be useful?
03
Open Claude or Cursor and ask for the structure
Not the implementation. The shape. Ask: "What would the file structure and component breakdown look like for this?"
04
Build one piece at a time, running as you go
Commit working states. Don't accumulate changes without testing.
05
Finish something
Ship the small version. The loop from idea → working thing is the skill to build. Speed and quality come from repeating it.
Before the code prompt — the intent prompt
The most important prompt you write isn't the one that starts the build. It's the one that defines what you're building and why. Answer these before you open any AI tool:
1What is the problem you're solving? Describe it in one sentence starting with "Currently, [who] struggle to [do what] because [why]."
2Who specifically needs this? Not "users" — a real person or group you can picture.
3What does "working" look like? Write the 3-step journey a real person takes through your tool.
Once you can answer all three, you're ready for the technical prompt below. The build will go faster, the output will be more focused, and when things go wrong you'll know what you're trying to get back to.
Your First Vibe Coding Prompt
# Copy this as a template I want to build [describe your project in 1-2 sentences]. Tech stack: [e.g. React, vanilla JS, Python Flask — or "you decide"] Core features for v1: - [feature 1] - [feature 2] - [feature 3 max] Constraints: Keep it simple. No auth needed yet. Should work in a browser without a backend if possible. Start by: showing me the recommended file structure and main components, then implement the entry point.
Fill in the brackets, remove the comments, and paste this into Claude or Cursor. That's your starting point.
Not sure what to put in the brackets?
Use the interactive prompt builder — answer five plain-language questions and get a complete, ready-to-paste prompt without needing to know any technical terms.
Build my prompt →
— 09

Scoping Your V1

The gap that kills most first-time builds isn't technical. It's the distance between a real idea and a buildable brief. Most people open an AI tool too early — before they've made the three decisions that determine whether the build will succeed.

The Three Decisions
01
Who is this for, exactly?
Not "people who want to track their habits." A specific person: your neighbour who runs a small catering business and loses track of which clients owe her money. The more specific, the better the build.
02
What is the one thing it must do?
Not five features. One. The feature without which the tool is useless. Everything else is version two. If you can't name the one thing, you're not ready to build yet.
03
What does "working" look like in 60 seconds?
Describe the exact journey a real person takes to accomplish that one thing. What do they see first? What do they do? What's the result? If you can walk someone through it out loud in a minute, you can build it.

Once you can answer all three with one sentence each, you have a v1 spec. Anything beyond that is scope creep. Cut it. Build the one thing first. Every feature you defer from v1 is a feature you'll build better in v2, with real user feedback to guide you.

V1 Scope Template — Fill This In First
# My V1 Scope Document The person I'm building for: [One specific person or role, not a category] The problem they have today: Currently, [person] struggles to [do what] because [why — not because tools don't exist, but the specific friction in their life]. The one thing my tool must do: [One sentence. One verb. No "and".] The 60-second walkthrough: Step 1: [User opens tool and sees...] Step 2: [User does X and the tool does Y...] Step 3: [User gets the result they came for] What I am NOT building in v1: - [Feature you want but don't need yet] - [Integration that can come later] - [Polish that doesn't affect whether it works] How I'll know it works: [One person uses it and says: "___"]
Rule of thumb
If your v1 scope document has more than six lines in the "core features" section, you have not scoped it yet. Go back and cut. The tools that change people's lives are usually very simple.
Which tool should I actually use?
If you've never coded before
Start with Bolt or v0
No setup. Open a browser, describe what you want, get a working prototype in minutes. Use this to validate the idea before investing time in a proper build.
If you want to own the code
Claude + Cursor
Use Claude to plan and architect. Use Cursor to build and iterate. This is the combination that produces the most robust results for most people building real products.
If you're on mobile or low-spec hardware
Replit
Runs entirely in the browser. No local setup. Supports most languages and frameworks. Good for simpler projects that don't require complex local environments.
— 10

Your First Build, Step by Step

This is the full loop — from blank page to something you can put in front of a real person. Follow it in order. Don't skip steps. The order matters more than the speed.

01
Fill in your V1 scope document first
Use the template from Section 09. Do not open Claude or Cursor yet. The 10 minutes you spend here will save you hours of rebuilding later. When the AI asks "what are you building?" you'll have a real answer.
02
Ask for the structure, not the code
Your first prompt should ask: "What's the recommended file structure and technology approach for this?" — not "build this for me." Review the structure before any code is written. It's much easier to change the blueprint than the building.
What to look for: Does the structure make sense to you? Are there more files than you'd expect? Ask the AI to explain any part that's unclear before proceeding. You should be able to sketch the structure on paper.
03
Build the entry point only
Ask the AI to implement just the starting point — the first screen, the main function, the landing page. One piece. Not the whole thing. Get it running. See it in a browser or terminal. That moment of first life is important — it makes the rest of the build feel real.
04
Commit working states before every change
Every time something works — even something small — run git add . && git commit -m "working: [what works]". This is your undo button. AI changes can break things unexpectedly — a committed working state means you can always get back.
Non-negotiable: Never ask the AI for a significant change without first committing the current working state. This single habit prevents the majority of painful rebuilding sessions.
05
Build one feature at a time, test immediately
Add one feature. Run it. Does it do what you expected? If yes, commit and move on. If no, ask the AI to fix the specific thing that's wrong — not to "fix everything." Focused, specific requests produce dramatically better results than broad ones.
Good prompt
"The submit button isn't doing anything when clicked. Here's the handler function: [code]. What's wrong?"
Avoid this
"It's not working properly. Can you fix everything and also add the other features we talked about?"
06
When it breaks badly — how to recover
It will break. Here is the exact recovery sequence:
A
Paste the exact error. Copy the full error message — not a summary of it — and give it to the AI with the relevant code. Exact errors produce exact fixes.
B
If the AI tries to fix it three times and fails, reset the session. Start a new conversation. Paste your scope document, your last working commit state, and the current error. Fresh context solves what a tired session can't.
C
If it's really broken, git reset to your last commit. Run git checkout . to discard all uncommitted changes and go back to the last thing that worked. Then try a different approach.
D
If you're completely stuck, ask the AI to explain the architecture rather than fix the code. Understanding often reveals a simpler path forward than the one that broke.
07
Check the architecture every 2–3 hours
Step back from the features periodically and ask: "Look at the code we've built so far. Is the structure still sound? Is anything getting messy that would make the next feature hard to add?" This is how you prevent vibe debt — the gradual accumulation of patches that eventually makes forward progress painful.
— 11

What "Shipped" Actually Means

"Ship the small version" is easy advice to give and hard advice to follow when you don't know what shipping means. Here it is concretely — the minimum bar for a v1 that counts, and the three ways to get it in front of people.

The minimum bar for a v1
A real person who is not you can use the one core feature without you explaining it to them
It works consistently — the same input produces the same output every time
You can share a link, a file, or an install step — something that doesn't require you to be present
The security basics are in place — no exposed API keys, no plain-text passwords, basic auth if users log in (see Section 12)
It does not need to be beautiful, fast, or feature-complete
The test that matters
Put it in front of one real person. Watch them use it. Don't explain anything. If they complete the core task — that's your v1. Ship it.
How to actually put it online
Vercel FREE TIER
The fastest path for web apps built with React, Next.js, or similar. Connect your GitHub repo, push your code, get a live URL in 60 seconds. Automatic SSL. No server management.
Best for: web apps, dashboards, front-ends
Railway or Render FREE TIER
Deploy a full back-end with a database. Supports Python, Node, Ruby, and more. More powerful than Vercel when you need server-side logic or data persistence.
Best for: APIs, apps with databases, Python tools
Replit Deployments EASIEST
If you built in Replit, deploying is one click. Gets you a shareable URL immediately. Good enough for sharing with a small group to get early feedback.
Best for: early validation, sharing with a test group
A shared file or script OFTEN UNDERRATED
For tools that don't need to live online — a Python script, an Excel macro, a browser extension — a shareable file is a completely valid v1. Don't over-engineer the distribution for something you're validating.
Best for: internal tools, local automation, desktop tools
— 12

Safety Before You Go Live

Speed is the point of vibe coding. But shipping a product that exposes your users' data, can be exploited by attackers, or creates legal liability for you is not a success — it's a crisis you haven't discovered yet.

The people using what you build are trusting you. That trust is the most fragile thing in any product. Protect it.

Why vibe-coded apps carry extra risk

Traditional developers understand what they wrote. If something is wrong with the auth logic, they remember why they made that choice. They know which function touches which data.

In vibe coding, the AI writes code you didn't author. You know what it's supposed to do — but you may not know what it actually does in edge cases. That gap is where security vulnerabilities hide.

This is not a reason to stop. It's a reason to build a review habit that accounts for it.

The five things AI almost never gets right unprompted
01
Secret management — API keys end up in source code and get committed to GitHub
02
Authorisation checks — routes are protected by login but don't check whether the logged-in user owns the data they're requesting
03
Input validation — user-submitted data goes directly into databases or displays without being checked or sanitised
04
Rate limiting — login and registration endpoints can be hammered indefinitely by automated scripts
05
Data encryption — sensitive information is stored in plain text; a database leak immediately exposes everything
The minimum you must do before going live with real users
🔴 Never ship without
All secrets in .env, not in source code
.env added to .gitignore
No plain-text passwords stored
Auth routes actually protected end-to-end
AI security audit run on all auth + data code
Git history checked for leaked secrets
🟡 Do before launch
! Rate limiting on login and registration
! Server-side validation on all user inputs
! IDOR test: try accessing other users' data by changing IDs
! Submit <script>alert(1)</script> in every text field
! CORS not set to wildcard in production
! npm audit showing 0 critical vulnerabilities
🟢 Before significant scale
Professional security review of auth and data handling
Privacy policy in place if you collect any user data
GDPR compliance if you handle EU user data
Error monitoring (Sentry) catching unexpected failures
Data backup and recovery plan
Terms of service if users are signing up
Run this before you go live — copy, paste, send
# Security audit prompt — paste before your code Please perform a security audit of the following code. Review specifically for: 1. Hardcoded secrets or API keys in source code 2. SQL injection or unsafe database queries 3. Missing input validation on user-submitted data 4. Authentication gaps — routes that should be protected but aren't 5. Authorisation gaps — users who can access other users' data 6. Plain-text password storage 7. CORS misconfiguration (wildcard origins) 8. Missing rate limiting on login/registration endpoints 9. XSS vulnerabilities — unsanitised user content rendered in the browser 10. Insecure or outdated dependencies For each issue found: - Rate it Critical / High / Medium / Low - Explain the risk in plain language (assume I'm not a security expert) - Show the vulnerable code - Show the fixed code # Paste your code below this line
An honest note about AI security audits

Running an AI audit is not the same as a professional security review. AI is excellent at catching common patterns — the issues listed above. It is less reliable at catching architectural vulnerabilities, logic flaws in complex flows, or novel attack vectors.

For a product handling sensitive data — health information, financial data, personal identifiers, children's data — a professional security review before public launch is not optional. It's the cost of operating responsibly.

When to get professional help
Your app handles medical, financial, or children's data
You're processing payments (PCI-DSS compliance required)
You're collecting data from EU users (GDPR implications)
You're scaling past a small test group
The AI audit found issues you don't fully understand
You built auth from scratch rather than using an auth service
Go deeper
The complete safety framework — all 12 steps, all threat categories, the full audit process — is covered in the Safety Guide, included in The Complete Series.