Andrej Karpathy popularized the term "vibe coding" in 2024: a development mode where you describe what you want to an LLM, accept the generated code, and move on without reading what was written. "The vibes are good", the code works, you keep going.

For demos, experiments, and personal prototypes, this works. But there's a conversation the vibe coding hype is postponing: what are the real implications of shipping to production code the engineer didn't read, doesn't understand, and can't maintain?

What "vibe coding" captures

The idea behind vibe coding isn't new. It's the same old argument in favor of abstraction. The less you need to think about implementation, the more energy goes toward the problem that matters.

And there's truth to that. Repetitive tasks, boilerplate, well-defined transformations, generating tests for obvious cases. AI does all of this well, and there's little value in doing it manually. Accepting generated code for these tasks without reading line by line is reasonable.

The problem starts when the "vibe" extends to business logic, security, performance, and architecture decisions, the parts where being wrong has real cost.

What AI doesn't know about your context

LLMs excel at patterns. They're limited with specific context. They don't know:

  • The business invariants of your domain that a bug might violate
  • The implicit contracts between parts of the system that only exist in the team's heads
  • The performance properties the system must maintain under real load
  • The security requirements specific to your product and users
  • The history of trade-off decisions that made the system what it is

AI-generated code is correct in the context of what the model was trained on. It may be incorrect in the context of your system, and the only way to know is to understand what was generated.

The tests argument

A common counter-argument: "I don't need to understand the code if I have enough tests." The problem is that tests can also be generated by AI, with the same context gaps. Generated tests cover what the model thinks should be covered, not necessarily what you need to cover.

Additionally, code you don't understand is code you can't debug when it breaks in production. It will break. The question is whether you'll understand why.

The scale of the problem in production

In personal projects and prototypes, the cost of bugs is low. In production with real users:

  • A security bug introduced by code without adequate review may expose user data
  • A race condition in payment logic can create duplicate transactions
  • A memory leak in a generated component can bring down the service under load
  • A failure in input validation can open an injection vector

None of these scenarios are hypothetical. All of them happen with human-written code too, but code the engineer read, understood, and reviewed has a higher chance of having those problems caught before production.

The right model: AI as a pair, not a substitute

The most useful model: AI as a pair programmer, not an autonomous developer. You still make decisions, review what was generated, and are responsible for the result.

In practice, this means:

  • You describe the problem, AI generates a solution. You read and understand before accepting
  • For business logic, you review with the same rigor you'd apply to a junior's code
  • For security code, you verify what's being done, not just that it seems to work
  • You maintain the ability to explain what the code does. If you can't, you didn't review enough

Where vibe coding makes sense

To be fair: there is legitimate space for accepting generated code with less review. Internal automation scripts. Fast prototyping. Test code with simple logic. Well-scoped migrations. In these contexts, the cost of deep review is disproportionate to the risk.

The distinction that matters: the engineer knows where on the spectrum they are, and adjusts the review level accordingly. Vibe coding as the default mode for everything is the problem, not AI itself.