Everyone has seen the demos. You describe what you want, the AI writes your app, and you ship in a weekend. It looks like magic.
But “vibe coding” - using prompts instead of planning, design, or structure - produces fragile code that does not survive production. It often creates more work for engineers than it saves.
Studies show experienced developers are around 19% slower with AI tools than without1. The promise of faster development hides slower iteration, heavy review overhead, and uncertainty about what is actually being shipped.
What “Vibe Coding” Really Means
Vibe coding is when developers skip architecture, planning, and reasoning, and instead let AI generate large blocks of code. There is no design, no testing plan, and often no real understanding of the output. The process feels productive because something appears on screen quickly. “Appearing” is not the same as “working,” and “working” once is not the same as being maintainable.
Many developers who tried it describe the same frustration, like these threads discuss2. “It looked clean, but the logic was nonsense. It took longer to fix than writing it myself.” Projects start as experiments and end as cleanup jobs.
Vibe coding might work for quick demos or rapid prototypes. It breaks down for production-grade software - the kind that must stay online, pass audits, and users will scream at you about if it fails.
The Data Behind the Illusion of Speed
Developers often believe AI makes them faster. Measured results tell a different story.
In a large 2025 study, experienced open-source developers completed tasks 19% slower with AI1. They felt faster, but they were not.
Most AI-generated code works only at a surface level. When teams extend it or try to debug it, time saved in typing is lost in validation and rework. The 2025 Stack Overflow survey found that 45% of developers said debugging AI-generated code takes longer than writing it from scratch, and only 3% said they fully trust the output3.
The initial speed from AI generation looks good in isolation. But if you measure total delivery time, including review, fixes, and testing, the illusion collapses. AI makes teams feel faster while slowing them down.
Why Vibe Coding Fails in Real Teams
You do not own the code you do not understand
AI code might run, but that does not mean the team understands it. When a bug appears, the developer who generated the code often cannot explain why it behaves a certain way. Senior engineers describe the urge to rewrite large parts of AI-generated code because it feels unreliable.
The moment you lose understanding, you lose control of the system.
Maintainability
AI often produces code that is technically valid but structurally weak. It tends to be verbose, inefficient, or inconsistent. Developers report that AI refactors can look elegant but hide deeper problems. Code that passes an initial test becomes hard to maintain over time. Vibe-coded systems age fast and quickly become unmanageable without heavy rewriting.
Cleanup has become its own market
There is now a market of developers who specialize in fixing AI-coded projects. Companies that believed they shipped fast end up hiring experts to refactor and stabilize the product4. The apparent short-term savings vanish. The prototype becomes a costly rebuild.
Even early advocates backed away
Greg Brockman from OpenAI mentioned that AI tools move human effort toward debugging and review instead of reducing it5. Andrej Karpathy, who popularized “vibe coding,” ended up hand-writing over 8,000 lines for his Nanochat project after finding AI tools unhelpful67.
When the originator of the concept avoids it for real work, that usually says enough.
The PR pileup problem
Generative AI gives junior engineers the ability to propose full rewrites with a few prompts. Pull requests now arrive faster and larger than ever. They often lack rationale or proper testing. Review queues grow. Senior engineers spend more time parsing huge diffs than solving problems.
This is both a training issue and a leadership problem. AI does not produce value unless work is structured. Real progress comes from small, reviewable, and tested changes with clear intent. Without discipline, AI inflates the number of PRs without improving output. Teams appear busy but ship less usable work.
The Trust Problem
Imagine working at a company that builds software for cars, rockets, or medical equipment. Would you trust AI-generated code to run inside a braking system or flight computer. These systems demand traceability, human accountability, and predictable behavior. A model that predicts text cannot provide that.
AI does not reason. It predicts. It repeats what it has seen, good and bad. The internet is full of poor examples and broken practices. Senior engineers already spend time reviewing and correcting junior code. Now they must review AI output from developers who may not understand what they are submitting. This expands review load instead of reducing it.
Without human judgment and structure, quality drops.
The Bubble of Expectations
The idea that AI allows ten developers to do the work of one hundred sounds attractive. It is also misleading. Companies that tried to replace engineers with AI tools often end up hiring back senior developers to fix broken systems4.
Code generation is easy. Sustainable engineering is not.
Vibe coding amplifies the illusion of speed. It looks efficient but leads to slower release cycles, higher failure rates, and more time spent in triage. When you measure the full cycle - build, review, test, and deploy - the gains disappear.
Visibility Over Gen AI
Most engineering leaders cannot confidently answer three questions:
- What exactly changed this week
- Why was it done
- How does it connect to product goals or incidents
The problem is not writing code faster. The problem is understanding the story behind the code. Without visibility into intent and reasoning, review becomes archaeology. People spend time guessing at the purpose of changes instead of improving them.
Solutions like One Horizon help teams close that visibility gap. It connects commits, pull requests, and discussions with goals and outcomes, so teams can see what changed and why. This context helps leaders control review load, manage PR sizes, and improve decisions without adding more meetings or manual tracking.
How to Use AI Without Losing Control
Plan before you prompt
Start with design. Define interfaces, data flows, and constraints. Use AI to fill in predictable parts of the work, not to define the architecture. Good output depends on strong input.
Measure results, not feelings
Track review load, rework, and deployment stability. Compare actual cycle time before and after adopting AI. Real impact shows up in delivery metrics, not in how fast code appears.
Maintain ownership
Each change should have a clear owner and reason. Require PR descriptions that explain the goal, risks, and test plan. Code without ownership creates confusion and slows review.
Use AI for repetitive work
Let it handle boilerplate, migrations, or test scaffolding. Keep the core logic and architecture human-designed and reviewed. Avoid large automated refactors unless isolated and verified.
Train and supervise junior engineers
Teach critical use of AI. Limit broad “rewrite everything” prompts. Keep pull requests small. Make reviews about design and reasoning rather than cleanup. Use AI as a helper, not a replacement.
Contain the PR flood
Set PR size limits. Define change budgets. Require review checklists. Gate merges with tests and benchmarks. Monitor reviewer load so senior engineers can focus on high-value work.
Bottom Line
Vibe coding feels fast. It is not. AI can write code, but it cannot understand the system it is writing for.
The real advantage comes from clarity and visibility. Teams that understand what changed, why it changed, and how it connects to goals move faster and make fewer mistakes.
Tools like One Horizon help close that gap by linking work to intent. Fewer pull requests, better reviews, and fewer surprises when it counts.
Footnotes
-
METR (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↩ ↩2
-
Reddit discussions (2025). “Vibe coding is a horrible experience” and “Vibe coding sucks.” https://www.reddit.com/r/webdev/comments/1mbcnzm/vibe_coding_is_a_horrible_experience/ and https://www.reddit.com/r/webdev/comments/1l1agmo/vibe_coding_sucks/ ↩
-
Stack Overflow (2025). “Developer Survey 2025.” https://survey.stackoverflow.co/2025/ ↩
-
Gizmodo (2025). “Coders Are Being Hired to Fix ‘Vibe-Coded’ Screwups.” https://gizmodo.com/coders-hired-fix-vibe-coded-ai-projects-1851730896 ↩ ↩2
-
Business Insider (2025). “OpenAI’s Greg Brockman on how AI shifts the coding experience.” https://www.businessinsider.com/greg-brockman-ai-coding-changes-programming-2025-6 ↩
-
Gizmodo (2025). “Even the Inventor of ‘Vibe Coding’ Says It Can’t Cut It.” https://gizmodo.com/andrej-karpathy-vibe-coding-falls-short-1851742259 ↩
-
Andrej Karpathy (2025). Nanochat repo and commentary on hand-coding approach. https://github.com/karpathy/nanochat ↩
