Vibecoding: Building Software by Describing What You Want

Vibecoding is building software mostly by describing what you want in plain language and letting an AI write the code — then running it, seeing what happens, and steering with more plain language. The term was popularized by Andrej Karpathy, who described “fully giving in to the vibes” and forgetting the code even exists. In practice, the useful version isn’t quite that hands-off — but the shift is real: for a growing class of projects, English (or Tagalog!) is becoming a programming language.

This guide is for someone who has coded a little, or not at all, and wants to actually ship something. We’ll cover the tools, the workflow that works, how to not get burned, and the honest limits.

What vibecoding is (and isn’t)

It is: prototyping an app, a script, a website, or a tool by conversation. “Build me a page that shows my expenses in a chart.” “Now let me filter by month.” “The total is wrong — fix it.” You review the result by using it more than by reading every line.

It is not: a license to ship code you don’t understand into a bank. The looser your review, the lower the stakes should be. Vibecoding a personal weekend tool? Great. Vibecoding the payment system for your business without anyone checking it? That’s how you end up with a security hole or a 3am outage.

The sweet spot: let AI handle the typing, but stay the person in charge of what “correct” means.

The tools

The landscape moves fast, but the categories are stable:

• Agentic coding tools — these don’t just autocomplete; they read your whole project, run commands, edit multiple files, and check their own work. Claude Code (Anthropic’s terminal-based coding agent) and Cursor (an AI-first code editor) are the standard-bearers. This is where serious vibecoding happens.
• In-editor assistants — GitHub Copilot and similar live inside your editor and suggest code as you type. Great for speed once you already code.
• Prompt-to-app builders — tools like v0, Bolt, Lovable, and Replit’s AI let you go from a text description to a running web app in the browser, no local setup. Lowest barrier to entry; best for front-ends and prototypes.

If you’re starting from zero, a browser-based builder gets you a win in minutes. If you want to build something real and keep it, an agentic tool like Claude Code or Cursor is worth the small learning curve. Under the hood these lean on frontier models — as of early 2026, Anthropic’s Claude Opus 4.8 and Sonnet 4.6 are among the strongest for coding.

The workflow that actually works

Vibecoding feels like magic, but the people who get good results follow a loop that looks a lot like real engineering.

1. Describe the goal, not the code

Start with intent and constraints, not implementation.

Build a simple web page where I can paste a list of names and it randomly
picks a winner. It should work on my phone. No sign-in. Keep it to one HTML file.

Notice the constraints (“one HTML file”, “works on my phone”, “no sign-in”). Constraints keep the AI from over-engineering.

2. Work in small steps

The single biggest mistake beginners make is asking for everything at once. Instead, build in slices you can verify:

1. “Get a basic page showing the input box and a button.”
2. Run it. Does it look right?
3. “Now make the button pick a random name and show it big.”
4. Run it. Does it work?
5. “Now add a fun animation when it picks.”

Each step is small enough that when something breaks, you know exactly what caused it.

3. Run it and look

Vibecoding lives or dies on the feedback loop. After every change: run the thing, click the buttons, try to break it. The AI can’t see your screen (usually) — you’re its eyes. Paste back what you see: the error message, the screenshot, “the total says 0 but it should say 40.”

4. Steer with specifics

When it’s wrong, don’t just say “it’s broken.” Say what you saw versus what you expected:

When I click Pick, nothing happens and the console shows:
"Uncaught ReferenceError: names is not defined". Fix that.

Good error reports get good fixes. This is prompting (see Prompting Basics) applied to code.

How to review AI-written code (even if you’re not a coder)

You don’t have to understand every line to stay safe. Use these checks:

• Does it do the right thing when you try to break it? Empty input, weird input, the “unhappy path.” AI code is often great on the happy path and fragile off it.
• Ask the AI to explain itself. “Explain what this code does in plain English, and point out anything risky.” A model will often flag its own shortcuts.
• Ask for the risks directly. “What could go wrong with this? What did you assume? What did you skip?”
• Watch for secrets and safety. If it’s handling passwords, payments, personal data, or anything public-facing, get a real developer to review before it goes live. Ask: “Are there any security issues here?” — but don’t treat the answer as the last word.
• Keep versions. Use version control (git) or at least save working copies, so a bad change is one undo away. Ask the AI to set this up for you.

The mantra: trust, but verify — and verify harder as the stakes rise.

Where it breaks down

Being honest about the limits is what separates people who ship from people who get stuck:

• The “almost works” trap. AI gets you 90% there fast, then the last 10% — the subtle bug, the edge case — can eat hours. Sometimes you have to actually understand the code to finish.
• It confidently invents things. Fake function names, libraries that don’t exist, APIs that were never real. Always run it; never assume.
• Big, tangled projects. As a codebase grows, the model can lose the thread, “fix” one thing and break another. Smaller, modular pieces stay vibecodeable longer.
• You can build a black box. If you never learn what the code does, you can’t maintain it, and you’re helpless when the AI can’t fix its own mess. Treat vibecoding as a way to learn faster, not to avoid learning.
• Security and cost. Public apps have real risks; cloud services have real bills. Don’t deploy something you don’t understand to the open internet without a checkpoint.

Try it this week

Pick something small and personal — a tool you would use. A tip calculator. A page that tracks your water intake. A script that renames your files. Open Claude Code, Cursor, or a browser builder, describe it, and start the loop: describe → run → look → steer.

When you find yourself wanting the AI to not just write code but keep working on its own — planning, acting, checking, retrying — you’re ready for the next level: Loop Engineering.