Vibe coding is building software by describing what you want to an AI model in plain language and accepting the code it writes without reading it closely. This guide explains where the term came from, what vibe coding is good and bad at, and a workflow that keeps the speed while avoiding the usual mess.
- Andrej Karpathy coined vibe coding in February 2025 for prompting an AI, accepting its changes, and not reading the code.
- Vibe coding is great for prototypes, personal tools and learning what is possible. It is a poor fit for anything that stores other people's data or money.
- The main risks are security holes, leaked secrets, surprise API bills and code nobody can maintain.
- Keep the speed by adding a few habits: git commits after each working step, a short spec, tests, and a review before anyone else uses it.
- Once real users depend on the code, switch from vibe coding to reviewed AI-assisted development.
What is vibe coding?
Vibe coding is a way of building software where you describe what you want to an AI model in plain language, accept whatever code it produces, and judge the result only by running it. You do not read the diffs. If something breaks, you paste the error back into the chat and ask for a fix.
The defining trait is that you stop looking at the code. Typing prompts into an AI tool does not by itself make it vibe coding. Developer Simon Willison put the line clearly in his March 2025 post: if you have reviewed, tested and understood every line, you are doing AI-assisted programming, not vibe coding.
A typical vibe coding session looks like this:
- You type "Build me a habit tracker with a calendar view and streaks."
- The AI writes a few hundred lines across several files.
- You open the app, see that streaks reset at the wrong time, and type "streaks reset at midnight UTC, I want my local time."
- The AI changes something. It works now. You move on without checking what it changed.
Where did the term vibe coding come from?
Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla, coined the term in a post on X on February 2, 2025. He described a new kind of coding where you "fully give in to the vibes" and "forget that the code even exists," clicking "Accept All" and no longer reading diffs. He also said it was "not too bad for throwaway weekend projects."
That last part often gets lost. Karpathy was describing a fun way to build disposable things, not a method for production software.
The phrase spread fast, and Collins Dictionary named "vibe coding" its Word of the Year for 2025, defining it as "the use of artificial intelligence prompted by natural language to write computer code." A year after the original post, Karpathy described the more supervised, professional version of this work as "agentic engineering," where you direct and oversee coding agents instead of ignoring what they write.
What is vibe coding good for?
Vibe coding is good for anything where a bug costs you a few minutes and nobody else is affected. In those cases the speed is worth far more than code quality.
Strong use cases:
- Prototypes and demos. Show a client or teammate a clickable idea in an afternoon instead of a slide deck.
- Personal tools. A script that renames your photos, a dashboard for your own spending, a tiny site for a family event.
- Learning what is possible. Non-programmers can find out whether an idea is buildable before paying anyone. Developers can try a framework they have never used.
- One-off data jobs. Converting a messy CSV, scraping your own exported data, generating a chart for a report.
- Throwaway experiments. Testing a UI layout or an API before you commit to building it properly.
If you are a beginner and want a structured route from idea to working product, the guide on how to build an app with AI covers stack choice and deployment in more detail.
What are the risks of vibe coding?
The risks of vibe coding come from the same thing that makes it fast: nobody reads the code. Problems that a quick review would catch go straight to whoever uses the app.
| Risk | What it looks like | Who gets hurt |
|---|---|---|
| Security holes | Database rules left open, missing auth checks on API routes, SQL built from user input | Your users, whose data leaks |
| Leaked secrets | API keys hard-coded in frontend code or committed to a public repo | You, through stolen credits |
| Surprise bills | A loop that calls a paid API thousands of times, no spending limit set | You |
| Unmaintainable code | Five versions of the same function, dead files, nothing named consistently | Whoever touches it next, often you |
| Silent data loss | A "fix" that rewrites a migration or drops a table | Everyone |
| False confidence | The app works in the happy path, fails on real input | Your users |
Most of these are classic web security problems, the kind listed in the OWASP Top 10. The AI did not invent new failure modes. It made it easy to ship old ones without noticing.
There is also a perception problem. In METR's 2025 study of experienced open-source developers, participants expected AI tools to make them about 24% faster and still believed afterward they had been sped up, while the measured result was that they took 19% longer. METR notes the study is small, specific to that setting, and dated for today's tools. The lesson still holds: feeling fast and being fast are different things, so measure by working results.
For a full checklist of what to review in machine-written code, see is AI-generated code safe.
Vibe coding vs AI-assisted development: what is the difference?
The difference is review. In vibe coding you trust the output because it runs. In AI-assisted development you trust it because you, or a reviewer, read it, tested it and understood it.
| Vibe coding | AI-assisted development | |
|---|---|---|
| Reads the code | No | Yes, every diff |
| Tests | Clicks around until it works | Automated tests that run on every change |
| Version control | Optional | Small commits, branches, pull requests |
| Specs | A one-line wish | Clear task with acceptance criteria |
| Good for | Prototypes, personal tools | Anything with users, money or private data |
| Who can do it | Anyone | Someone who can read and judge code |
You do not have to pick one forever. A common path is to vibe code a prototype, decide the idea is worth keeping, then switch modes: read through what exists, add tests, and continue with reviewed changes. The guide to AI pair programming shows what that reviewed workflow looks like day to day.
How do you vibe code without shipping a mess?
You keep most of the speed by adding a handful of cheap habits that make mistakes reversible and visible. None of them require you to become an expert programmer.
1. Start with a short spec
Before the first prompt, write five to ten lines: what the app does, who uses it, what data it stores, and what is out of scope. Paste it into the first message and keep it in a file such as SPEC.md in the project. Agents that read project files will pick it up on every session.
Build a single-page habit tracker.- Users: only me, no login.- Data: stored in the browser (localStorage), nothing on a server.- Features: add a habit, tick it off per day, show a 30-day calendar and current streak.- Streaks use my local timezone.- Out of scope: accounts, sync, notifications.Ask me questions before you start if anything is unclear.Compare that with "make me a habit app," which leaves the AI to guess about logins, storage and timezones, and it will guess differently every time.
2. Commit after every working step
Put the project in git from the first minute and commit each time something works. When the AI breaks the app three prompts later, you roll back in seconds instead of asking it to undo changes it no longer remembers.
git initgit add -A && git commit -m "calendar view works"git restore . # later: throw away uncommitted changes that broke the app3. Ask for one change at a time
"Add dark mode, fix the streak bug and make it work offline" produces a large, tangled change. Three separate prompts produce three small changes you can test and roll back independently.
4. Make the AI write tests
Ask for tests for the core logic, such as streak calculation or price totals, and ask the AI to run them after each change. Tests are how you check code you are not reading. They catch the "fix" that quietly breaks something else.
Write unit tests for the streak calculation, including: a habit ticked every day for 5 days,a missed day in the middle, ticks across a daylight saving change, and an empty history.Run them and show me the output. Do not change the tests to make them pass.5. Keep secrets out of the code
Never paste API keys into prompts that end up in frontend code. Keep them in environment variables or the platform's secrets settings, and set a monthly spending limit on every paid API account before you connect it.
6. Ask the AI to review its own work, then get a human
Before you share anything, ask: "Review this codebase for security problems. List every place user input reaches the database, every API route without an auth check, and every secret in the code." It will not catch everything, but it catches a lot. Then get someone who can read code to look before real users arrive.
When should you stop vibe coding?
Stop vibe coding the moment other people depend on the software or trust it with something. That includes their data, their money, their time, or their login.
Concrete signals that it is time to switch to reviewed development:
- You are adding user accounts or payments.
- The app stores personal data, health data or anything covered by privacy law.
- Someone other than you will use it regularly.
- The AI keeps "fixing" the same bug and it keeps coming back.
- You are afraid to change anything because you do not know what will break.
Switching does not mean throwing the code away. Ask the AI to explain the structure, write down how it works, add tests for the main flows, and then continue with smaller, reviewed changes. Writing precise tasks matters more at this stage; the guide on how to write tasks for AI coding agents has templates.
If you want to use vibe coding to learn programming rather than skip it, ask the AI to explain each change and try writing small parts yourself. The post on how to learn to code with AI has a weekly plan for that.
Which tools fit which kind of vibe coding?
The right tool depends on how much code you want to see. Browser app builders hide almost all of it, while coding agents show every change and suit people who plan to review later.
| Tool type | Examples | Good for | Trade-off |
|---|---|---|---|
| Browser app builders | Lovable, Bolt, v0, Replit | Non-programmers, quick demos with hosting included | Harder to move off the platform, less control |
| AI code editors | Cursor, VS Code with Copilot | People who want to see files as they change | You need a local setup |
| Terminal coding agents | Claude Code, Codex | Larger projects, real repositories, scripted work | Assumes comfort with a terminal |
Coding agents also run longer tasks on their own, which is where vibe coding blends into delegating work. If you start handing an agent bigger jobs and do not want it to stop when your laptop sleeps, Orkio runs agents like Claude Code on an always-on cloud box and lets you review the pull requests from your phone later.
How to start vibe coding today
Pick a small, personal project where a bug costs nothing, and follow this checklist:
- Choose a tool from the table above that matches how much code you want to see.
- Write a 5 to 10 line spec, including what is out of scope.
- Create a git repository and commit after every step that works.
- Ask for one change per prompt.
- Have the AI write and run tests for the core logic.
- Keep API keys in environment variables and set spending limits.
- Before anyone else uses it, run a security review prompt and get a human to read the code.
Vibe coding is a fast way to find out what you want to build. Treat what it produces as a draft, and give it a real review before it becomes something other people rely on.
Frequently asked questions
Who invented the term vibe coding?
Andrej Karpathy, a founding member of OpenAI and former director of AI at Tesla, used it in a post on X on February 2, 2025. He described giving in to the vibes, accepting all changes and forgetting that the code exists. Collins Dictionary later named it Word of the Year for 2025.
Can you vibe code with no programming experience?
Yes, you can build small working apps without knowing how to code, and many beginners do. The limit shows up when something breaks in a way the AI cannot fix, or when the app needs logins, payments or private data. At that point you need someone who can read the code, or you need to learn enough to do it yourself.
Is vibe coding bad?
Vibe coding is fine for throwaway projects, prototypes and tools only you use. It becomes a problem when unreviewed code reaches real users, because nobody has checked it for security holes, data leaks or costly bugs. The risk comes from shipping code nobody has read.
What is the difference between vibe coding and AI-assisted programming?
In vibe coding you do not review the code the AI produces. In AI-assisted programming you still read, test and understand the code before you commit it, so you could explain how it works. Most professional developers who use AI daily do the second.
What tools do people use for vibe coding?
Common choices are browser app builders such as Lovable, Bolt, v0 and Replit, AI editors such as Cursor, and terminal coding agents such as Claude Code and Codex. App builders hide the most code from you, while agents and editors show every change and suit people who want to learn or review.
