The Limits of Vibe Coding: Where It Stops Working

Vibe coding has limits, and you don’t hit them on day one. You hit them when the project starts to matter. The first weeks are fast: every request becomes a working feature. Then the pace drops, changes start breaking nearby things, and one day the AI spends three hours fixing a single button.

That doesn’t mean the tool is bad. It means the task has gone beyond what can be done reliably without understanding the code. Below are the five places this happens most often, and the signs that you’re already there.

Complex state

While an app is forms and lists, things are simple: data comes in, data gets shown. Trouble starts when an entity has a lifecycle. An order is created, paid, partly refunded, cancelled after delivery. A subscription is on trial, past due, paused, reactivated.

AI handles each transition well on its own and handles all of them together badly. The code ends up allowing combinations that shouldn’t exist: an order that’s both paid and cancelled, a subscription that renewed after the money was refunded. You won’t see it in a demo. Nobody in a demo cancels an order after a partial refund.

Security

AI optimises for “make it work.” Permission checks, server-side validation and rate limits aren’t needed to make it work, so they’re often missing.

The deeper problem is that security is invisible from the outside. An app with a hole in its data access behaves exactly like one without it, until someone asks for data that isn’t theirs. Vibe coding relies on judging code by its behaviour. Here, that approach fails by design.

Scale and data

With ten test records, every query is fast. With a hundred thousand, you find out the list page loads the entire table and makes another database call for every row. There are no indexes, because nobody asked for them.

The same goes for files, emails and paid APIs: with few users, inefficiency costs pennies. Later it becomes a hosting bill growing faster than revenue and pages that take ten seconds to open.

Integrations

Payment providers, CRMs, email, inventory, third-party APIs. Every integration has details the documentation example doesn’t show: repeated webhooks, rate limits, timeouts, version changes, inconsistent error formats.

AI writes the happy path: request goes out, response comes back. What happens if the response doesn’t come, comes twice or comes a minute late usually isn’t covered. While the other system behaves, you won’t notice. The first outage on the partner’s side and your data drifts out of sync, and nobody knows where.

Maintenance

The quietest limit of all. The project works, but:

nobody can explain how it’s put together;
the same thing is done in several places in different ways;
libraries are outdated, and upgrading breaks everything at once;
there are no tests, so the only way to check a change is to click through everything.

Every new feature costs more than the last. That’s technical debt, just accumulated faster than usual.

Signs you’ve hit the wall

A change in one place regularly breaks something somewhere else.
The AI “fixes” a bug and it comes back in a different form a few days later.
You’re describing the same problem in a third separate conversation.
There are parts of the app you’re afraid to touch.
Users report bugs you can’t reproduce.
Your hosting or API bill is growing faster than your user count.
You can’t answer the question “can user A see user B’s data?”

If two or three of these ring true, the problem isn’t your prompts. The project has outgrown the way it’s being built.

What to do next

These options aren’t mutually exclusive.

Shrink the vibe coding zone. Keep generating UI and standard screens, and hand payments, permissions and integrations to someone who reads the code.

Clean up the code. Remove duplication, move logic into one place, lock down data access, add tests for the main flows. After that, vibe coding works again, on a foundation you understand.

Stop and assess. Sometimes the honest answer is to rewrite the core and keep the interface. Make that call on facts, not out of frustration.

In short

The limits of vibe coding show up when the project starts to matter, not on day one.
The weak spots are complex state, security, scale, integrations and long-term maintenance.
Security is invisible in behaviour, so “it works, so it’s done” doesn’t apply.
The clearest sign of the wall is changes that break nearby things and bugs that keep coming back.
The way out is to narrow what you vibe-code, clean up the code, then carry on.

SUBXCAT works right at this boundary: we help figure out what in a project can stay and what needs to be rebuilt.