Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Vibe Coding

Antipattern

A recurring trap that causes harm — learn to recognize and escape it.

“I just see things, say things, run things, and copy-paste things, and it mostly works.” — Andrej Karpathy

Generating code through natural language prompts without reading, understanding, or verifying the output, then shipping it anyway.

Understand This First

  • Verification Loop – the feedback cycle that catches mistakes before they compound.
  • Local Reasoning – the ability to understand a piece of code without loading the whole system into your head.

Symptoms

  • You accept the agent’s output without reading it. The code works when you run it, and that’s enough.
  • When something breaks, you paste the error message back into the agent and accept the next suggestion. You never look at what changed.
  • You can’t explain what your code does to a colleague. You know what you asked for, but not what you got.
  • The project has no tests. You’ve never asked the agent to write any, and you wouldn’t know what to test if you did.
  • Dependencies multiply because each prompt brings in whatever library the model reaches for first. Nobody audited the choices.
  • The commit history is a sequence of “fix bug” and “try again” messages with no description of what was actually wrong.

Why It Happens

Andrej Karpathy coined the term in February 2025. He described a workflow where you “fully give in to the vibes, embrace exponentials, and forget that the code even exists.” For his use case, throwaway weekend projects, the approach made sense. The problem started when people applied it to software that matters.

Vibe coding is seductive because it removes the hardest part of programming: understanding the problem domain well enough to write correct code. You describe what you want in plain English, the model produces something that runs, and the gap between “I had an idea” and “I have a working prototype” shrinks to minutes. That feedback loop is addictive.

But producing code and understanding code are different activities. When you skip understanding, you accumulate what security researchers now call comprehension debt: the growing gap between what your system does and what you think it does. You can’t reason about edge cases you’ve never seen. You can’t fix bugs you can’t locate. Every prompt that generates code you don’t read adds another black box, and the compound effect is an application that works until it doesn’t, with nobody who understands why.

There’s a social dimension too. Vibe coding lowers the bar for producing software, which means more people can produce it. That’s genuinely good. But it also means more software ships without anyone in the loop who can evaluate whether it’s correct, secure, or maintainable.

The Harm

The numbers are stark. A 2026 Trend Micro study found that 45% of AI-generated code fails basic security tests. AI co-authored code shows 2.74 times the rate of security vulnerabilities and 75% more misconfigurations than human-written code. By March 2026, researchers had tracked 35 CVEs directly attributed to AI-generated code, up from 6 in January. An Anthropic study of 52 professional developers found that those using AI assistance scored 17% lower on code comprehension tests, with the steepest drops in debugging and code reading.

The harm goes beyond security. When you don’t understand your code, you can’t maintain it. Every change becomes a gamble because you don’t know which parts depend on which other parts. The only tool you have is “run it and see,” which catches surface-level failures but misses the subtle ones: data corruption, race conditions, silent logic errors that produce wrong answers without throwing exceptions.

Ownership fragments too. The person who typed the prompt didn’t write the code. The model that generated the code has no memory of it and no stake in its correctness. The reviewer, if there is one, faces a PR full of code that nobody in the room wrote or can explain. Software without an author is software without accountability.

The Moltbook breach in 2026 showed what happens at scale. The entirely vibe-coded application exposed 1.5 million API tokens and 35,000 email addresses within three days of launch. Nobody involved could identify the vulnerability because nobody had read the deployment code the model produced.

The Way Out

Vibe coding isn’t a disease with a single cure. It’s a cluster of missing practices, and the fix is to add them back.

Read what the agent writes. This is the minimum viable intervention. You don’t need to understand every line at the level of the person who wrote it, but you do need to understand the structure: what functions exist, what they call, what data flows where. If you can’t summarize a file’s purpose in one sentence, you don’t understand it well enough to ship it.

Close the Verification Loop. Don’t accept code that hasn’t been tested. Ask the agent to write tests alongside the implementation. Run them. Read the test names. They tell you what the agent thinks the code should do, which reveals misunderstandings faster than reading the implementation alone. Use the Red/Green TDD cycle: write a failing test for the behavior you want, then let the agent make it pass.

Apply Local Reasoning. Can you look at one function, one module, one file and understand what it does without tracing through the rest of the system? If not, the code needs restructuring before it needs new features. Ask the agent to break large functions into smaller ones with clear names.

Treat AI-generated code as untrusted input. Run static analysis. Run dependency audits. Review the permissions and network calls. The agent generates code that looks right but doesn’t reason about attack surfaces. You have to be the one who does.

Tip

When using an AI agent, set a personal rule: never commit code you couldn’t debug without the agent’s help. If the agent disappeared tomorrow, would you be able to find and fix a bug in what it wrote? If the answer is no, you don’t understand it well enough to ship it.

How It Plays Out

A startup founder uses an agent to build a SaaS application in a weekend. The agent handles authentication, payment integration, database schema, and a React frontend. The founder tests each feature by clicking through the UI. Everything works. She launches on Monday, gets 200 signups, and celebrates.

On Wednesday, a user reports being charged twice. The founder pastes the error into the agent and deploys the suggested fix. On Thursday, a different user reports seeing another user’s dashboard data. The founder looks at the database queries for the first time and discovers there’s no row-level access control — the agent built a system where any authenticated user can read any row. She doesn’t know how to add access control because she doesn’t understand the ORM layer the agent chose. She pastes the problem back into the agent, which restructures the queries, but the fix breaks the payment flow because the payment webhook handler assumed a different data model. Three days later, she takes the application offline.

Six months later, she tries again. This time she reads every file the agent produces. She asks the agent to explain its authorization model before writing the queries. She writes a test that verifies User A can’t see User B’s data. She runs a security scanner on every PR. The process takes roughly twice as long. But when a user reports a bug, she can find it in the code, understand why it happened, and fix it without breaking something else.

A different team hits the problem from the other direction. Three engineers at a mid-size company adopt an agent for a greenfield microservice. They generate code fast, ship on schedule, and move to the next project. Six months later, a junior developer is assigned to add a feature. She opens the codebase and finds 40,000 lines of code that none of the original three engineers can explain. The agent that wrote it has no memory of the project. The commit history is prompt-response-deploy, with no reasoning captured. She spends two weeks reverse-engineering the data model before she can write a single new line. The speed the team gained in month one, they repaid with interest in month seven.

  • Prevented by: Verification Loop – the antidote to accepting code without checking it.
  • Violates: Local Reasoning – vibe-coded systems are full of code nobody can reason about locally.
  • Violates: Test – vibe coding skips testing because it skips understanding what to test.
  • Produces: AI Smell – unreviewed agent output is the primary source of AI smells in production.
  • Accelerates: Technical Debt – every line of code you don’t understand is debt you can’t repay.
  • Ignores: Happy Path – vibe coding tests only the happy path (run it once, see if it works).
  • Prevented by: Red/Green TDD – writing a failing test before asking the agent to implement forces you to define what “correct” means.

Sources

  • Andrej Karpathy introduced the term “vibe coding” in a post on X (February 2025), describing a workflow where you “fully give in to the vibes” and accept AI-generated code without reading it. He scoped it to throwaway projects, but the term quickly became shorthand for the broader practice.

  • Trend Micro, “The Real Risk of Vibecoding” (March 2026). Provided the core security data: 45% of AI-generated code fails security tests, with elevated rates of injection flaws, missing validation, and hardcoded secrets. Also tracked CVE attribution to AI-generated code (35 in March 2026, up from 6 in January).

  • The Anthropic developer study (2026) measured the comprehension cost: AI-assisted developers scored 17% lower on code understanding, with the largest declines in debugging and code reading.

  • The UK National Cyber Security Centre (NCSC) urged the industry to develop safeguards for vibe coding practices at RSAC 2026, lending institutional weight to the concern that unchecked AI code generation poses systemic security risks.