What Is Vibe Coding, and What It Costs Your Team Later

What is vibe coding? It is the practice of building software by describing what you want in plain language, then letting an AI model write the code with minimal line-by-line review from you. Andrej Karpathy coined the term in February 2025. By mid-2026, 92% of US developers use AI coding tools daily, and 41% of all code written globally is now AI-generated. The question is no longer whether vibe coding works. It is what happens to a codebase six months after your team started vibing.

The Original Definition, Without the Hype

Karpathy described vibe coding as a workflow where you "see stuff, say stuff, run stuff, and copy paste stuff." You type a description into Cursor or Claude Code, accept the generated block, run the tests, fix what breaks with another prompt. You are not reading every line. You are directing.

That is a reasonable description of how a lot of prototyping works in 2026. Where it gets complicated is the implicit assumption that understanding the code is optional. For a throwaway weekend project, maybe. For a codebase that will be in production at 2 AM on a Tuesday, that assumption breaks.

Karpathy himself acknowledged this. In December 2025, he noted that 80% of his personal code was AI-generated, and he identified that month as a turning point for agentic coding, when AI-generated chunks became large enough that the practical question shifted from whether the agent could handle a task to how to verify its output at the scale he was delegating.

How It Actually Works in Practice

A vibe coding session has a recognizable shape. You describe the intent in plain language: "Add an endpoint that returns the last 10 commits for a repo, paginated with cursor-based pagination, returning 401 if the caller is not authenticated." The more specific the brief, the less work the review has to do.

The AI generates a code block. You read it, or more often skim it. You run the tests. If something breaks, you paste the error message back into the chat and iterate. If it passes, you ship.

The time savings are real. Teams report cutting first-draft time for new features by 40 to 60 percent for greenfield work. For boilerplate generation, scaffolding, and repetitive patterns, the gains are significant enough that any team not using AI tooling is effectively competing with teams that have an additional engineer on every PR.

The Part Nobody Talks About: Reading AI-Generated Code

Here is what the productivity statistics miss. Writing code is roughly 30 to 40 percent of a senior developer's time. The other 60 to 70 percent is reading code: understanding how the authentication system is wired in a repo of 80,000 lines, figuring out why a background job started failing, untangling a three-way data dependency before you can safely add a feature.

When 41 percent of the codebase was written by an AI that nobody deeply reviewed, reading that code becomes harder. AI-generated code tends to be verbose. It adds abstraction layers that look clean at first glance but obscure the actual data flow. It sometimes introduces patterns that are idiomatic in its training data but not in your team's stack.

You can grep for a function name. You can run git blame on a file. But neither tells you why the code is structured the way it is, or what the adjacent systems expect from it. That is the gap that matters when you are three levels deep in a debugging session at midnight.

Where Vibe Coding Works Well

The research is consistent on the use cases where vibe coding adds genuine value, and where it creates downstream problems.

Strong use cases:

• Greenfield prototypes and MVPs where speed matters more than long-term maintainability

• Throwaway scripts and one-off data transforms

• Boilerplate generation (database migrations, CRUD endpoints, test stubs) in a well-understood stack

• Exploratory coding to validate whether an approach is feasible before committing engineering hours

Use cases where it creates problems later:

• Security-sensitive code paths: authentication, authorization, payment processing, session management

• Code that interfaces with external APIs that have compliance requirements or rate-limit consequences

• Systems maintained by multiple engineers over more than 12 months

• Any logic where a silently failing edge case could cause data loss or incorrect billing

The 45 percent vulnerability rate in AI-generated code is not a statistical anomaly. It is what happens when you ask a model to generate code that "works" without providing explicit context about your threat model. The model optimizes for the happy path you described. It does not know what you did not tell it.

The Technical Debt Accumulation Pattern

Vibe-coded codebases accumulate debt in a specific and predictable way. Test coverage drops, often to 12 percent or lower, from an industry baseline closer to 68 percent. The code passes the tests you ran, but edge cases go uncovered because you did not prompt for them. Error handling is shallow. The 300 percent increase in maintenance costs within 18 months, reported consistently across 2026 research, is not surprising once you have seen this pattern play out.

The warning signs appear early if you know what to look for:

• git log shows repeated "fix for [something that just broke]" commits within two to three weeks of a vibe-coded feature merging

• Pull requests that touch a vibe-coded module take longer to review because no one is confident about its surface area

• Oncall incidents that trace back to edge cases never tested because the original author assumed the AI output was correct

The problem is not that AI wrote the code. The problem is that the review discipline that normally catches these issues was skipped because the code worked on first run.

What Changes When You Use a Codebase Chat Tool

The productivity gap above is specifically a reading problem. Vibe coding improved writing speed. It did not improve reading speed.

When a new engineer joins a team that has been vibe coding for six months, their first two weeks are harder than they used to be. The code lacks the contextual comments a human would have added when working through a design decision. The tests do not cover the cases where the AI got something subtly wrong. The architecture document, if one exists, was written before 40 percent of the codebase changed.

Tooling that lets you ask questions about a codebase in natural language fills this gap directly. "How is the auth token validated on this route?" "What functions call this method and from where?" "Is there anything between this service and the payment processor that could retry on failure?" You are not replacing grep or git blame. You are adding a layer that answers structural questions across multiple files at once, grounded in the actual code rather than whatever the documentation says.

This matters more when onboarding to a vibe-coded repo than to a traditionally written one. The contextual intent that a human author bakes into variable names, comments, and function signatures is thinner in AI-generated code. A tool that can synthesize answers from the actual code graph fills that gap without requiring someone to manually document what an AI generated.

Vibe Coding and Code Review

One practical change that serious engineering teams are making in 2026: AI-generated code gets more rigorous code review, not less. This is the correct response.

The logic is direct. When a senior engineer writes a function, there is an implicit assumption that they understood the context and made deliberate tradeoffs. When an AI writes it, that assumption does not apply. The code may be correct. It may be subtly wrong in a way that only surfaces under load, with an unusual input, or after a dependency update six months later.

The teams reviewing vibe-coded PRs well ask questions the AI was not prompted with: What happens here if the input is null? If the upstream service is slow? If this function is called concurrently by three threads? These are questions the model did not have in scope when it generated the code.

The better practice is to front-load those constraints into the original prompt. "Write an endpoint for X. It must handle concurrent requests safely. It must not log request bodies. It must return 429 if the caller exceeds 10 requests per second. It must treat an empty array as a validation error, not a server error." The more specific the brief, the less the review has to catch.

The Honest State of Vibe Coding in 2026

Vibe coding is not a trend that will reverse. By mid-2026, the tooling is good enough that any team not using it is accepting a structural speed disadvantage. The 40 to 60 percent first-draft acceleration is real. The question is not adoption. The question is the review discipline that accompanies it.

Developer favorability toward AI coding tools dropped from 77 percent in 2023 to 60 percent in 2026. Only 33 percent of developers trust the accuracy of AI-generated code, down from 43 percent in 2024. But 92 percent use these tools daily, and the majority verify output manually before shipping. The developers getting value from vibe coding are not skipping verification. They are using AI to write faster and human judgment to ship safely.

Vibe coding works as a development methodology when it includes a reading discipline. The developers producing solid work with it are not the ones who see stuff, say stuff, run stuff. They are the ones who also ask: is this code I could explain to a teammate? Is this code I could debug at 2 AM without the original chat session open?

If the answer is no, the code is not done yet.