How to fix AI-generated code that broke in production

AI codegen made the first version cheap. A founder describes a feature, the model writes it, it runs, the demo lands, the product ships. For a while that speed feels like a superpower. Then the app hits real users, real data, and real load, and the same speed starts working against you: something breaks in production, and nobody on the team can fully explain why, because nobody actually wrote the code.

2026 has been widely called the year the bill came due on that speed — industry commentators keep describing a wave of technical debt from a year of shipping code faster than anyone could review it. The pattern we see when these codebases land on our desk is remarkably consistent. It is almost never one exotic bug. It is a handful of the same failure modes, repeated across the whole app, because the model made the same reasonable-looking mistake every time it was asked a similar question. This is a field guide to those patterns and to how a senior team gets a vibe-coded codebase back under control.

The failure patterns a senior team keeps fixing

AI-generated code is usually not wrong in the way a beginner's code is wrong. It compiles, it is tidy, it follows conventions, and the happy path works. What it lacks is everything that only matters when reality stops cooperating — and that is exactly the part a model can't feel the absence of. Here is what we find, in rough order of how often it hurts.

• Security holes. Missing authorization checks are the big one — an endpoint that trusts the user ID in the request instead of the session, so anyone can read anyone's data. Alongside them: secrets committed straight into the repo, SQL built by string concatenation, unvalidated input, and other OWASP Top-10 staples. Industry reviews of AI-generated code keep finding a meaningful share of it carries at least one of these, because the model optimises for code that works, not code that resists an attacker.
• No tests, so nothing is safe to change. Vibe-coded apps almost always arrive with zero real test coverage. Every fix becomes a gamble, because there is no way to prove you didn't break something three files away. This is usually the single biggest reason the codebase feels stuck.
• Nothing handles the unhappy path. The API call that fails, the payment that times out after it succeeded, the empty list, the malformed upload — the code assumes none of these happen. In a demo they never do. In production they happen hourly, and each one is an unhandled exception or a silent corruption.
• N+1 queries and other performance cliffs. The model writes a loop that queries the database once per item because that reads cleanly. With ten rows it's invisible; with ten thousand it's a timeout. Missing indexes, refetching the same data, and loading entire tables into memory are the usual companions.
• Tangled architecture that blocks the next feature. Logic copied inline instead of shared, business rules smeared across controllers and components, no clear boundaries. Each AI-generated feature was locally sensible and globally inconsistent, so adding anything new means touching ten places and hoping.
• No observability. When something breaks in production there are no logs worth reading, no error tracking, no metrics. You find out from a customer, and then you're debugging blind because the system never recorded what it was doing when it fell over.

How a rescue actually runs

Panic-fixing a vibe-coded app one bug at a time is how you spend a month and end up with a codebase that's just as fragile and now also half-rewritten in a second style. A rescue has an order to it, and the order matters more than the speed. Here is the sequence we run.

1. Audit. Before touching anything, map what exists: the real architecture (not the intended one), where the data lives, which paths handle money or personal data, and where the security and stability landmines are. The output is a prioritised list — what will hurt you soonest, ranked ahead of what merely offends good taste.
2. Stabilise the bleeding. Fix the issues that are actively dangerous or actively down first — the missing auth check, the committed secret, the query that's timing out under load. Add error tracking and basic logging early, even before the deeper fixes, so you stop debugging blind and start seeing what production is actually doing.
3. Make it safe to change. Add a test harness and CI. You don't chase 100% coverage — you write tests around the critical paths and the parts you're about to touch, so every subsequent change is verified instead of hoped. This is the step that converts a frozen codebase back into one you can move in.
4. Refactor behind the tests. Now that changes are provable, collapse the repeated patterns: pull duplicated logic into shared code, fix the N+1s, introduce the boundaries the architecture was missing. Because the model repeated itself, fixing one pattern well fixes it everywhere — this is where a tangled app starts feeling like software again.
5. Harden and hand back. Close the remaining performance cliffs, finish observability, document what changed and why, and leave the team able to keep building on it — not dependent on us to touch it. A rescue that ends with you needing the rescuer forever isn't finished.

Refactor or rebuild?

This is the question every rescue turns on, and the honest answer is that it depends on how much of the code is worth keeping. The instinct to throw it all away and start clean is usually wrong — a full rewrite discards the working parts along with the broken ones, and rewrites have their own well-documented graveyard. But sometimes the foundation genuinely can't bear weight. Here is roughly how we call it.

What a rescue engagement looks like

Rescues price on the state of the code, not on a line count, because two apps of the same size can be a week apart or a quarter apart depending on how deep the problems go. That's why we start with the audit as a small, fixed piece of work: it's the only honest way to quote the rest. Broadly, engagements land in three shapes.

Why work with Duskel

We've been a founder-led software studio since 2021, with 40-plus builds shipped and our own products in production — which means we've lived the failure modes in this post from the inside, not just cleaned them up for other people. That's the relevant experience for a rescue: knowing which missing auth check, which N+1, which untested path is the one that actually bites, so you're not paying us to rediscover it.

A rescue is full-stack web development at its least glamorous and most valuable — it's senior work, and we keep the team senior, so you deal with the people fixing the code rather than an account manager relaying to a sub-contractor. And we'll tell you honestly when a refactor beats a rebuild, because talking you out of the more expensive option is part of being worth hiring. If your AI-built app is breaking under real users, send us the codebase and what's going wrong and we'll tell you straight what it needs.

FAQ

AI-built app breaking in production? Send it over and we'll tell you what it needs.

Send the problem. You get one fixed number and a plan back within a business day.