What Vibe Coding Is, and Where It Breaks

Vibe coding is building software by describing what you want to an AI model and accepting the code it writes without reading it closely. It works well for prototypes and throwaway tools. It breaks when the software handles real users, real data, or real money, because nobody has checked what the code actually does.

Key facts (as of October 2026)

The term comes from a post by Andrej Karpathy on February 2, 2025, describing coding where you “forget that the code even exists” (Andrej Karpathy on X).

In the same post, Karpathy called it “not too bad for throwaway weekend projects”. He did not pitch it as a way to build production software.

Anthropic’s Claude Code security page says: “You’re responsible for reviewing proposed code and commands for safety before approval” (Claude Code Docs).

The OWASP Top 10:2025 lists Broken Access Control as the number one web application risk (OWASP).

Where does the term “vibe coding” come from?

Andrej Karpathy coined the phrase in a post on X in February 2025. He wrote: “There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists” (Andrej Karpathy on X).

The rest of the post describes the method in detail. He talks to the AI by voice. He clicks “Accept All” and says, “I don’t read the diffs anymore.” When an error appears, he pastes it back in “with no comment”. When the AI can’t fix a bug, he will “work around it or ask for random changes until it goes away.”

He also set the scope himself. The approach, he wrote, is “not too bad for throwaway weekend projects”. That line is easy to skip, but it is the most useful part of the definition.

What does vibe coding mean in practice?

The word now gets used loosely. Some people use it for any coding with AI help. That stretches it too far. A more useful definition sticks close to the original post:

You describe outcomes, not code. “Make the button blue and move it under the form.”
You don’t read the code. You judge the result by whether the app seems to work.
You fix errors by pasting them back. The AI makes the next guess.

Using an AI assistant is not the same as vibe coding. A developer who asks an AI for code, reads every line, runs tests, and rejects bad suggestions is doing AI-assisted programming. The difference is review. If you want a longer take on why that review skill matters for your career, see Is It Still Worth Learning to Code in 2026?.

What is vibe coding good for?

Vibe coding is a good fit when a mistake costs little and the code won’t live long. These are the main cases:

Use case	Why it works	Watch out for
Prototypes and mockups	You need something to click, not something to maintain	Treating the prototype as the product later
Personal or internal tools	A small, trusted group uses it, and you can fix it when it breaks	Pasting real customer data into it
Small static sites	No login, no database, no payments	Forms that collect personal data
Learning and exploring	You see quickly whether an idea is possible	Thinking you learned the code because it runs
One-off scripts	You run it once, check the output, and delete it	Running it against live data with no backup

The common thread is that you can see the whole result and judge it yourself. A landing page either looks right or it doesn’t. A script that renames files either did it or didn’t.

Where does vibe coding break?

Vibe coding breaks wherever “it seems to work” is not enough proof. Four areas cause most of the trouble.

Security

Security bugs don’t show up when you click around. A page can look perfect while any logged-in user can read another user’s records. That is the classic Broken Access Control problem, which OWASP ranks first in its 2025 list (OWASP). The same list includes Injection, Authentication Failures, and Software Supply Chain Failures. None of these appear in a quick visual check.

Prompt injection is a newer risk. Anthropic describes it as “a technique where an attacker attempts to override or manipulate an AI assistant’s instructions by inserting malicious text” (Claude Code Docs). If your coding agent reads web pages or files you didn’t write, that text can steer what it does.

Data

AI-written code often runs commands that change data: database migrations, file moves, bulk updates. If you accept every change without reading it, you may not know what was deleted until it’s gone.

Claude Code’s checkpoints help, but Anthropic is clear about their limits. Checkpoints “only track changes made through Claude’s file editing tools”. Changes made through shell commands or other processes are not captured, and the docs say plainly: “This isn’t a replacement for git” (Claude Code Docs).

Maintainability

Karpathy noted that “the code grows beyond my usual comprehension” (Andrej Karpathy on X). That is fine for a weekend project. It is a problem for anything you need to change in six months.

When nobody understands the code, every new feature becomes another round of guessing. Workarounds stack up. Fixing one thing breaks another, and you can’t tell why.

Edge cases

AI-written code usually handles the happy path: the expected input from the expected user. Real users send empty forms, very long names, odd characters, and double clicks. Anthropic’s own best-practices page calls this “the trust-then-verify gap”: Claude “produces a plausible-looking implementation that doesn’t handle edge cases.” Its fix is direct: “If you can’t verify it, don’t ship it” (Claude Code Docs).

What should you check before shipping AI-written code?

Use this checklist before anything AI-written goes live. It covers the areas where clicking around won’t reveal a problem.

1. Secrets

Search the code for API keys, passwords, and tokens. They should live in environment variables or a secrets manager, not in source files.
Check your git history too, not only the current files. GitHub’s secret scanning looks at a repository’s full history and is free for public repositories (GitHub Docs).
If a key was ever committed, rotate it. Deleting the file is not enough.

2. Authentication and access control

Log in as one test user and try to open another user’s page by changing the ID in the URL.
Confirm that admin pages check the user’s role on the server, not only by hiding a button.
Log out and try the same URLs again.

3. Input validation

Every form and API endpoint should validate input on the server. OWASP’s guidance: “Validate on the server even when the browser checks the same fields. Client-side validation is bypassable” (OWASP Cheat Sheet Series).
Define what you accept and reject everything else. OWASP advises: “Do not try to recognize every malicious string.”

4. Dependencies

List every package the AI added. Ask why each one is needed.
Check that each package name is real and spelled correctly before you install it.
If you use npm, run npm audit. It asks your registry “for a report of known vulnerabilities” in your dependencies (npm Docs).

5. Tests

Ask the AI to write tests for the behavior that matters most, then run them yourself.
Read the tests. Make sure they check real behavior and weren’t edited just to pass.
Add at least one test for an edge case: empty input, a wrong password, a missing record.

6. Backups and rollback

Use git and commit before each AI session, so you can return to a known state.
Back up any database before running AI-written migrations or bulk changes.
Know how to roll back a deploy before you need to.

In Claude Code, you can also run /security-review for “an on-demand security pass over the changes on your current branch” (Claude Code Docs). Treat it as one extra check, not a replacement for this list.

When should you bring in an engineer?

Bring in an experienced engineer before launch if any of these are true:

Users log in. Authentication and session handling are easy to get subtly wrong.
You store personal data. Names, emails, addresses, or anything covered by privacy rules.
Money moves. Payments, refunds, invoices, or pricing logic.
Other systems depend on it. An API, a webhook, or a data feed other people rely on.
It will grow. You expect to add features for months or years.
You can’t explain how it works. If you can’t describe what happens when a user clicks Submit, you can’t judge whether it’s safe.

You don’t need an engineer to write everything. A focused review of the risky parts is often enough: login, data access, payments, and deployment. Give them the checklist above and ask them to start there.

Common mistakes

Promoting a prototype to production. The prototype proved the idea. Rebuild or review it before real users arrive.
Accepting every change with no git history. You lose the ability to see or undo what changed.
Pasting real customer data into prompts while testing. Use made-up sample data instead.
Trusting “it works on my machine.” Test with a second account, an empty form, and a phone.
Asking the AI whether its own code is secure, and stopping there. A second check in a fresh session or by a person catches more. Anthropic’s docs recommend a reviewer in a fresh context because it “evaluates the result on its own terms” (Claude Code Docs).

Next steps

Decide which of your projects are throwaway and which will face real users
Put every project in git and commit before each AI session
Run the six-part checklist (secrets, auth, input, dependencies, tests, backups) before launch
Book an engineer review for anything with logins, personal data, or payments
Keep vibe coding for what it does well: fast prototypes you can see, judge, and throw away