The Limits of Vibe-Coding

Describe what you want, let the AI generate it, glance, ship.
It feels like magic — until day 90, when you open a bug and realize nobody, not even the AI, understands the code you're running.
What vibe-coding actually costs, and where it still genuinely shines.

Ninety days after a team ships its first vibe-coded product, the same scene tends to play out.

Someone opens a function to fix a small bug.
The function is 300 lines long.
It handles form validation, a database write, an email notification, and a piece of business logic that depends on a constant defined five files away.
There's no comment explaining why the email only goes out under certain conditions.
The commit message says "add user flow."

And here's the part that turns a nuisance into a crisis: you can't ask the AI why it wrote it this way, because the AI has no memory of the decision.
Neither does anyone on your team, because no one made it.

That's the 90-day reckoning, and in 2026 it's arriving at companies everywhere.
It's the moment the magic of vibe-coding reveals its price.

What vibe-coding is — and why it's so seductive

The term, coined by Andrej Karpathy in early 2025, describes a genuinely new way of building software: you describe your intent to an AI in plain language, it generates the code, you glance at whether it seems to work, and you ship it — often without fully reading or understanding what it produced.
Prompt, generate, glance, commit.

And it is, at its best, extraordinary.

Roughly 84% of professional developers now use AI coding tools at least weekly, and for good reason: for prototypes, experiments, throwaway scripts, and exploring an idea, vibe-coding compresses hours into minutes.
When the stakes are low, "does it seem to work?" is a perfectly reasonable bar.
Nobody sensible is arguing you should hand-write a weekend prototype.

The problem isn't the tool.
It's what happens when the weekend-prototype workflow quietly becomes the way you build the production software that paying customers depend on.

There's a revealing tension buried in the adoption numbers: while about 84% of developers now use these tools, only around 29% say they actually trust the output.

Most engineers already sense the gap between "it generated something" and "this is right."
The danger is the workflow that encourages them to ship anyway.

The speed is front-loaded. The cost compounds.

Here's the trap in one sentence: vibe-coding front-loads the speed and defers the cost — and the cost doesn't accumulate in a straight line, it compounds.

The early days feel spectacular.
Features ship in hours.
Velocity looks incredible on a chart.

Then the inconsistencies start to surface — architecture that doesn't hold together, duplicated logic, subtle bugs — and each new change gets a little harder because developers can't trust the code beneath them.
Studies tracking this find that by around day 90, teams are spending 20% to 30% of every sprint just fixing bugs that trace back to AI-generated code.

Left unchecked, the arc ends in what engineers call velocity collapse: the point where the accumulated mess makes every change so slow that the early speed gains are erased — and then some.
The cost of unwinding the debt can exceed the entire value of the features that created it.

Salesforce analysts went so far as to name 2026 "the year of technical debt," specifically because of vibe-coding adoption.
The bill, it turns out, always comes.

One study of roughly 800 developers captured the whole illusion in a single finding: after adopting an AI coding assistant, their initial speed gains were almost entirely neutralized by a 41% increase in bug rates.
They felt faster.
The data said otherwise.

Problem one: the security you can't see

Start with the most alarming finding, because it hasn't budged.

Veracode tested over 100 large language models on security-sensitive coding tasks and found that around 45% of AI-generated code introduces an OWASP Top 10 vulnerability — and, critically, that number has stayed flat from 2025 into early 2026 even as the models got better at writing working code.
Bigger, smarter models did not produce safer code.
Coding ability improved; security did not.

It shows up in the wild.

AI-assisted commits leak hardcoded secrets — passwords, API keys — at roughly double the rate of human-only commits, contributing to a record 28.65 million new exposed secrets on public GitHub in a single year.
CVEs formally attributed to AI-generated code climbed from 6 in January 2026 to 35 by March, and researchers believe the true number is five to ten times higher because most AI tools leave no fingerprint.

The most insidious part is psychological.

A Stanford study found that developers using AI assistants not only introduced more security vulnerabilities — they were more confident their insecure code was secure.
The tool doesn't just make mistakes; it makes you trust the mistakes.

That combination — more flaws, more confidence — is exactly how serious breaches happen.

Problem two: the debt you can't pay down

Ordinary technical debt is manageable because you understand it.
You wrote the quick-and-dirty solution, you know why it's quick, and you know how to fix it later.

Vibe-coded debt is a different, nastier species: nobody understands it, because nobody wrote it in the deliberate sense — and the AI that did has no memory of its own reasoning.

The measurements are stark.

Code duplication runs about 4x higher in AI-heavy codebases.
Refactoring — the healthy act of consolidating and cleaning up — collapsed from a quarter of changed lines a few years ago to under 10%, because generating new code is always easier than fixing old code.
An analysis of 8.1 million pull requests found technical debt rising 30% to 41% after AI-tool adoption.

A review of AI-coauthored pull requests found 1.7x more major issues, a 75% jump in logic flaws, and maintainability problems that tripled.
You end up with a codebase that grows and grows but never consolidates — a house that keeps adding rooms and never fixes the wiring.

Problem three: the skill you're quietly not building

There's a longer-term cost that's easy to miss.

The judgment required to fix AI-generated debt — to look at a tangle of code and know what's wrong and why — is precisely the judgment that engineers develop over years of writing, breaking, and repairing code themselves.
It's a craft learned by doing.

Yet more than half of engineering leaders say they plan to hire fewer junior developers because AI handles the grunt work.

The result is a "hollowed-out career ladder": senior engineers at the top, AI doing the bottom rungs, and fewer and fewer people in the middle actually learning the craft.
You can borrow speed from AI today, but you may be borrowing it against your own future capacity to understand and maintain what it builds.

The real distinction: a tool, not an author

None of this is an argument against AI.
We use these tools every single day, and they're remarkable — pretending otherwise would be foolish.

The failure mode isn't using AI to write code.
It's letting AI be the unsupervised author of code that no human understands or is accountable for.

That's the line, and it's the same one we keep returning to across everything we build: AI is a phenomenal power tool, but it is not the architect.

A human engineer has to own the design, comprehend the output, and stand behind every line that reaches production.
The moment "I don't fully understand this, but it seems to work" becomes acceptable for code that handles real money, real data, or real users, you've stopped engineering and started gambling — and the house, as day 90 reveals, always collects.

What discipline actually looks like

The teams using AI well aren't slower.
They're just deliberate.
In practice that means:

• Design the architecture before you generate. Data models, service boundaries, and API contracts are human decisions; let the AI fill in the implementation inside a structure you defined.
• Keep AI-generated functions small and single-purpose — the opposite of the 300-line monster.
• Review every AI-authored change like you would a stranger's — because that's exactly what it is — with specific attention to duplication and security.
• Put security scanning and test-coverage gates in your pipeline, and draw a hard line: no unreviewed AI code on security-critical paths.
• Audit for debt regularly rather than discovering it at day 90.
• Vibe for prototypes; engineer for production. Match the rigor to the stakes.

None of that sacrifices the speed.
It just keeps a human in the seat where comprehension and accountability have to live.

How we think about it at BuonaLabs

We ship fast, and we use AI heavily to do it — but a human engineer owns the architecture and understands every line that reaches your production systems.

We treat generated code as a first draft from a fast, talented, slightly reckless junior: enormously useful, never merged unread.
The result is the speed of modern tooling with the comprehension and accountability that keep a product maintainable a year later, not just impressive on launch day.

Vibe-coding can feel like it removed the need to understand your own software.
It didn't.
It just moved the moment you discover you don't — from the day you write it to the day it breaks, when understanding is most expensive and least available.

Build like you'll have to maintain it.

Because you will.
Around day 90, usually.