What vibe coding means
Vibe coding is building software by describing what you want and accepting what the model produces, without reading most of the code. The term was coined by Andrej Karpathy in early 2025 to describe a way of working he characterised as giving in to the vibes and forgetting that the code exists.
It caught on because it named something people were already doing. It is now used loosely for any AI-assisted development, which muddies a distinction worth keeping:
| Vibe coding | AI-assisted development | |
|---|---|---|
| Do you read the code? | Mostly not | Yes |
| Who decides the architecture? | The model | You |
| How do you know it works? | You try it | Tests, checks, verification |
| What happens when it breaks? | Describe the bug, hope | Read, diagnose, fix |
| Good for | Prototypes, throwaways, learning | Anything with users |
Both are legitimate. The failure is not choosing vibe coding; it is choosing it for something that later needs to be maintained, and not noticing the moment it stopped being a prototype.
The three categories of tool
"Vibe coding tools" covers three groups that work differently enough that comparing them directly is a category error.
| Category | What it does | You get |
|---|---|---|
| Prompt-to-app platforms | Describe an app; it builds and hosts one | A running app, often on their infrastructure |
| Agentic coding tools | Work in your repository with real tools | Commits in your own codebase |
| In-editor assistants | Complete and edit as you type | Faster typing, you stay in control |
The question is not which is best. It is which stage you are at and whether you intend to own the result.
Prompt-to-app platforms
You describe an application in a browser and get a working one, usually deployed, often with a database and auth wired up. Lovable, Bolt, Base44, Replit and v0 sit here, along with a steady stream of newcomers.
What they are genuinely good at: going from nothing to something clickable in minutes. For validating an idea, showing a stakeholder a real interface instead of a mockup, or building an internal tool that ten people will use, they are excellent and hard to beat.
The trade you are making: the platform chooses the stack, the structure, and often the hosting. That is precisely why it is fast. It also means the exit is the thing to check before you commit — can you export the code, and is what you get something a developer would want to maintain? Some produce a clean repository. Others produce something that runs and nobody wants to touch.
The honest failure mode: the second month. The first version arrives startlingly fast. Then you need a specific integration, or a permissions model that does not fit the pattern, or a performance fix, and progress slows sharply — because the parts you did not read are now the parts you need to change.
Agentic coding tools
These work in your actual repository. They read files, run commands, execute tests, and commit. Claude Code is one; Codex CLI, Cursor's agent mode, Aider and Gemini CLI occupy the same space.
What they are good at: real projects with existing code. They follow your conventions, work inside your architecture, and produce commits in your repository. Nothing about the output is proprietary to the tool — it is just your codebase.
The trade: you need a repository, and you need enough judgement to review what comes back. There is no browser preview that makes a bad decision look fine.
Where they beat prompt-to-app: everything after the prototype. Adding a feature to a real system, refactoring, debugging, migrations, audits. And critically — they scale with your discipline. Give one a good CLAUDE.md, real constraints, and a finishing procedure, and output quality goes up substantially. Prompt-to-app platforms have no equivalent lever.
In-editor assistants
Autocomplete on a longer leash — GitHub Copilot, Cursor's inline mode, and the assistants now built into most editors. You are writing; they finish lines and blocks.
This is barely vibe coding, because you read everything as it appears. It is also the lowest-risk of the three, and the easiest to adopt: nothing changes about how you work except speed.
Worth noting that these compose with agentic tools rather than competing. Plenty of people use an in-editor assistant for the typing and an agent for the multi-file work.
How to choose
| If you... | Use |
|---|---|
| Need something clickable today, to validate an idea | Prompt-to-app |
| Have a repository and real requirements | Agentic |
| Write code daily and want it faster | In-editor |
| Are building something with users and money attached | Agentic, with real verification |
| Cannot read the language you are generating | Prompt-to-app, and keep the scope small |
| Need to hand this to a developer later | Agentic, or check the export first |
Three questions settle most cases: Will anyone else maintain this? Does it touch money or personal data? Will it exist in a year? Any yes points toward owning the code in your own repository.
Where vibe coding genuinely works
The critique of vibe coding is often overdone. It is the right tool for a real set of jobs:
- Throwaway prototypes. Building it properly would cost more than the answer is worth.
- Learning. Seeing a working example of something unfamiliar is a fast way in, as long as you then read it.
- Internal tools with a handful of users. The blast radius is small and the alternative is usually a spreadsheet.
- Scripts and one-offs. Data transformations, migrations you run once, glue.
- Exploring an approach before committing to it. Three rough versions tells you more than a week of design.
The common thread: the cost of it being wrong is low, and you will find out quickly. That is the actual test — not the size of the project.
Where it fails, predictably
These are not hypothetical risks. They are the recurring ones.
Security. The commonest serious flaw in generated applications is missing authorisation — checking that a user is logged in, but not that this particular record belongs to them. It is invisible in testing because you are testing as yourself. Change an ID in a URL and you find it.
Accessibility. Clickable divs, placeholders used as labels, focus states removed because they looked untidy, contrast that fails at a glance nobody took. Generated interfaces look fine and lock people out.
The states nobody described. Loading, empty, and error. You asked for a feature and got the happy path, because that is what you described.
Silent duplication. Ask for four things across four sessions and get four ways of doing the same thing. Nothing errors; the codebase just becomes harder to change every week.
Debugging what you did not read. The moment a bug arrives in code you never looked at, the speed advantage inverts. You are now reading it under pressure instead of at leisure.
The wall, and how to avoid hitting it
Most vibe coding projects that fail follow the same arc. Fast start, real progress, genuine delight — then a change that requires understanding the whole thing, and a stop.
The wall is not a limit of the tools. It is the accumulated cost of decisions nobody made deliberately. Every unread file is a decision that got made by default, and the bill arrives when you need to change one.
Three habits push it a long way out, and none of them cost much:
Read the structure, even if not every line. You do not need to review every function. You do need to know what the files are, how data moves, and where the boundaries are. Ten minutes.
Verify the things that fail silently. Change an ID in a URL and confirm you get a 403. Tab through the interface. Check contrast. Load it at 320px. These take minutes and catch the failures that testing-as-yourself never will.
Write down the decisions once you have them. The moment a project outlives the afternoon, the constraints belong in a file rather than in your memory of what you typed.
Vibe coding with a seatbelt
The most useful reframing: vibe coding and disciplined development are not opposites, they are a dial. You can move it per task.
Prototyping a layout? All the way to vibes. Touching authentication? All the way to disciplined. Most work sits between, and the skill worth developing is noticing which one you are on.
Four things let you keep most of the speed while removing most of the risk:
- A file of constraints the tool reads every session, so conventions are stated once rather than re-guessed. That is what CLAUDE.md is.
- A finishing procedure — checks that run, output you see — so "done" is a procedure rather than a claim.
- Review in a fresh context. A session that wrote the code will defend it; a subagent with no memory of writing it will not.
- One automated check that fails the build on a regression. Break it once deliberately to confirm it works.
That is perhaps an hour of setup. It is the difference between a prototype that becomes a product and one that becomes a rewrite.
If you are weighing formal training as a way to build that judgement, is there a Claude Code certification? covers what exists and whether it is the shortest path.
Where to go next
If you have decided the project is worth owning properly, the complete website workflow is the disciplined end of the dial, start to finish. The prompt library covers directing an agent so you get fewer surprises, CLAUDE.md covers the constraints file, and the SEO workflow covers what generated sites almost always get wrong. Building a store rather than a site? See building a Shopify store with Claude Code.
Sources and further reading
- Claude Code documentation
- OWASP Top Ten — the risk categories behind the security failures above
- W3C: WCAG 2.2 — the accessibility criteria generated interfaces most often miss
- Google: people-first content — relevant if the generated site is meant to be found