Vibe Coding Has the Same Problem as Self-Driving Cars

Everyone now wants to ‘vibe code’. The barriers that once prevented non-technical users from building software have largely disappeared. 

Yet, vibe coding today runs into the same core problem as self-driving cars.

Stewart Lynch, the creator of 10x Editor, an integrated development environment, drew this analogy in a post on X. “The driver who’s supposed to be monitoring the situation falls asleep at the wheel,” he says.

“I do my best work when I know every line intimately and can catch the rare edge case bugs before they even happen. Ideas often come to me when I’m in the shower, eating lunch, out for a walk, or not even at my desk,” he writes, explaining that he can continue programming in his head because he remembers what he has written.

When he is no longer directly writing the code, that continuity breaks. “Reading code that someone (something) else has written is incredibly boring and hard to get to grips with,” he says.

“Programming without editing code is unnatural.” But why?

When Speed Outruns Understanding

Tools such as Cursor, Claude Code and Lovable are seeing rapid adoption, allowing developers to generate code far faster than before. The problem is not speed itself, but what is lost as speed increases.

“But then, you find out that in trying to move faster, developers tend to lose awareness about the different capabilities in their system and codebases,” says Amar Goel, CEO and founder of Bito AI, in an interaction with AIM.

Vibe coding is not inherently harmful. The issue is that the unreviewed surface area of a codebase can grow faster than a human’s capacity to review it as the volume of generated code increases. 

One developer on Hacker News compared large agent-generated code drops to inheriting a 20,000-line codebase written by an intern—except it arrives instantly, and the reviewer is now responsible for understanding every edge case.

This loss of authorship becomes most visible when something breaks. 

Engineers often report that when AI-generated changes introduce subtle bugs, the usual debugging loop collapses. In several cases, the author of the code was unable to explain why a change had been made because the decision originated with an AI agent rather than human intent.

Why Review and System Context Became the Bottleneck

To address these limitations, an adjacent ecosystem is emerging around AI coding platforms.

Alongside code-generation tools, startups such as CodeRabbit, Greptile, Qodo, and CodeAnt AI focus on automated, context-aware code review and pull request analysis. Their role is to act as guardrails, compensating for the lack of system awareness in general-purpose AI coding assistants.

Even the platforms themselves are adding review layers. Cursor and Devin now include automated bug detection and review features. In January, Devin launched the Devin Review agent, which organises diffs, detects moved code and flags potential bugs.

“If you’re going to write thousands of lines of code a day, compared with writing hundreds of lines of code in a day previously, you need a really robust code review process,” Goel said.

At scale, relying purely on human reviewers becomes impractical.

“I had one of the most famous tech startups in India, where code review takes six days on average,” says Goel. 

“They told us, ‘We have two human reviewers. Can we replace one of them with AI and reduce review time by 50%?’”

According to Goel, customers using Bito AI and its AI Architect feature are seeing a 50% reduction in bugs. 

Rather than generating code, the system models an organisation’s existing codebase as a structured system graph, capturing services, endpoints, dependencies and implementation patterns, and feeds targeted system-specific context into coding and review agents.

“Normally, the coding agent either doesn’t know anything about the system, or it tries to read a little bit of the repository and misses most of it,” he said. “The architect shows the coding agent: ‘Here’s 3,000 or 10,000 tokens of targeted information about this specific system.’”

The Production Reality Check

Goel argues that this lack of deep system understanding is why AI coding tools struggle in real production environments. 

While models perform well on prototypes or greenfield applications, they often break down inside large, established systems. 

Production codebases can contain hundreds or even thousands of microservices, each following internal conventions that are rarely documented end-to-end.

“That’s where these models don’t have that full context and understanding,” he says.

Without that shared understanding, developers often avoid integration altogether. “A lot of times an engineer would say, ‘If I want to interact with some microservice, I have to go find the engineer who knows about that and learn about it,’” Goel said. “So I’d rather just rewrite the service myself.”

In the short term, rewriting is often faster. In large systems with hundreds or thousands of microservices, understanding an existing service can take hours or days, requiring engineers to locate the right code, trace undocumented dependencies, and track down domain experts.

Under delivery pressure, rewriting a small piece of functionality is usually faster and more predictable. Over time, however, this behaviour leads to duplicated logic and inconsistent behaviour across services.

This is why system-aware review and architecture tools are becoming necessary complements to AI coding platforms rather than optional add-ons.

Goel notes that enterprises building software for millions of users typically follow structured pipelines, moving from product requirement documents to technical designs and low-level designs before implementation. AI-generated code is only useful if it fits cleanly into that process.

With a clearer system context, tasks that previously required hours of onboarding and back-and-forth can be completed much faster. “We’ve seen some three- to five-hour coding tasks come down to eight or 10 minutes,” he says.

The larger risk emerges when AI-generated code becomes too tempting, particularly for companies building software as part of a product rather than operating as technology companies by design. 

In such environments, speed often takes precedence over understanding.

“When people have something that works really well, they want to be proud of that moment, and say ‘I just vibe coded this!’” Aravind Putrevu, director of developer marketing at Code Rabbit, tells AIM. “But one of the biggest problems for non-technical users is not just hallucination, but not having control over the choices these tools are making.”

Putrevu adds that technical teams face similar pressure. “The business is pressurising them to use AI more, and they turn to vibe coding,” he said, often accepting less control than they would have when writing code manually.

Ultimately, organisations face a trade-off. They can accept longer, more complex review cycles as AI increases the volume of code being written, or—if they want sustained productivity gains — invest in system-aware review agents and architectural tools designed to catch issues before they surface in production.

“Code review is weird because 99% of it is pointless and slows down development by [50%] or more,” Nick Dobos, a software engineer wrote on X. “But then 1% of the time it stops a bad architectural decision that saves months to years of work or catches a critical issue that would cost over $1 million and nuke the company.”