What is vibe coding, and where does it break down?
Vibe coding means building software by describing what you want to an AI model, running what it writes, and asking for fixes when something breaks, without reading or really understanding the code. It's quick and fun for prototypes and personal tools. It breaks down wherever the software holds other people's data, money or trust.
Where the term comes from
Andrej Karpathy, an AI researcher, coined the phrase in a post on 2 February 2025. He described giving in to the model entirely: accepting every change, pasting error messages back without comment, and letting the code grow beyond his own understanding. He framed it as fine for throwaway weekend projects. The term caught on quickly and is now used loosely for any AI-assisted building, which blurs a useful distinction.
Vibe coding vs programming with AI
| Vibe coding | Programming with AI help | |
|---|---|---|
| Who reads the code | Nobody | The developer, before it ships |
| How bugs are fixed | Paste the error, accept the next attempt | Understand the cause, then fix or ask for a specific fix |
| Tests | Rarely | Written or reviewed by a person |
| Suits | Prototypes, games, personal tools, demos | Anything with users, data or payments |
| Main risk | Hidden flaws nobody knows are there | Slower, but the person is accountable |
Where it works well
- Prototypes you'll throw away. Testing whether an idea is worth building properly.
- Single-person tools. A calculator, a tracker or a script that only you use, with data that only lives on your machine.
- Games and toys. If it breaks, nobody loses anything.
- Learning what's possible. Seeing a working version can clarify what you actually want before you write a real brief.
The specific points where it breaks
- Secrets in the front end. Models often paste API keys straight into browser code to make a call work. Anything in the page is public, and keys get found and abused.
- Authorisation that only exists in the interface. A hidden button isn't access control. Without server-side checks, anyone who calls the endpoint directly can read or change other people's records.
- Database rules left open. Hosted databases often start permissive. If nobody configures row-level rules, every signed-in user may see every row.
- Input trusted as-is. Forms without server-side validation accept anything, from oversized text to injected markup.
- Dependencies nobody chose. Generated projects pull in packages, sometimes outdated, sometimes ones that don't exist and could be registered by someone malicious.
- Fixes that fix the symptom. "Make the error go away" can mean wrapping it in a try-catch that hides a real failure.
- No way back. Without version control, a fix that breaks three other things is hard to undo.
None of these show up when you click around the app. They show up when someone else does. The OWASP Top 10 lists broken access control at the top for good reason, and it's exactly what vibe-coded apps tend to miss.
Adding review without becoming a developer
- Keep every version so you can roll back.
- Search the code for keys and tokens before anything goes public; revoke any you find.
- Ask the model to list every place user data is stored and who can read it, then check the answers are enforced on the server.
- Run an automated security scan on what actually ships.
- Before real users arrive, have a developer read the authentication, authorisation and payment code.
How Anticode approaches it
Anticode lets you build interactive apps, tools and games from a description, which is close to vibe coding, but with fences around the risky parts. An app the model writes runs in a strict sandbox: no network at all, no outside scripts, no real accounts, payments or live data. Anything that would need a server is simulated with sample data and labelled as demo data, and the app can save only to the visitor's own browser. Apps get their own code gate with one automatic repair pass, and pages are checked by Sentinel's twelve security checks before publishing.
When a prototype needs to become real software, the Next.js export gives you a standard project with server routes, Postgres through Prisma, roles and two-factor sign-in for admins, ready for a developer to review and extend. The guide to exporting to Next.js covers that step, and why AI websites look the same covers the design side of unreviewed AI output.
Limits
The sandbox is what makes Anticode's apps safe to publish, and it's also their main limit: no multiplayer, no server-side database, no live third-party data inside an app. Checks catch known patterns; they don't prove an app is correct. If your idea depends on real accounts or shared data, plan for a reviewed codebase from the start.
Questions people ask
Is vibe coding bad?
Not for what it was named for: quick experiments where nothing important is at stake. It becomes a problem when the result is given real users without anyone reviewing it.
Can non-programmers build useful software this way?
Yes, for tools and prototypes. For software that stores other people's data or takes money, get the security-critical parts reviewed by someone who can read code.
Is vibe coding the same as no-code?
No. No-code tools give you fixed building blocks. Vibe coding produces real code that nobody has read, which is more flexible and less predictable.