AI-Generated App Breaks in Production: What to Fix
An AI-generated app breaks in production when business logic fails quietly, or the next fix breaks a path that was working. Book a scope call.
An AI-generated app breaks in production when the behavior that matters was never specified, only described once in a chat. The preview looked finished. Live traffic takes the branches the prompt did not mention, and the code either guesses or pretends it succeeded.
Why the break is quiet
Columbia's DAPLab reviewed Cline, Claude, Cursor, Replit, and v0 and published the failure patterns in January 2026. The most serious and most common were error handling and business logic. They are dangerous because they are silent: the code runs, and the app does not do what was asked. The lab's other finding is that agents treat requirements as preferences. They agree in the plan, then drift when they write the code. Why Vibe Coding Fails and How to Fix It.
A benchmark lines up with that. On SUSVIBES, 186 real feature requests, SWE-Agent with Claude 4 Sonnet was functionally correct on 57% of solutions and secure on 11.8%. "It works" and "it is safe" are different results. A correct-looking response can still skip the check that production needs.
Security holes are the subset that leak data. They are covered in vibe coding security vulnerabilities. This note is the subset that corrupts the product: money, bookings, and the edit that undoes last week's fix.
How it shows up for users
Payments. A published rescue account described a marketplace on Cursor that processed more than $200,000 over four months. The Stripe webhook existed, did not verify signatures, sometimes timed out, and Stripe's retry created duplicate records. Edge cases such as partial refunds and disputes had no handling. About 15% of successful payments never landed in the database. Customers were charged and did not get access. Some were charged twice. The founder reconciled it by hand. The repair was about $15,000. The account is here. Test mode hides this, because test charges succeed.
The next fix. Red Hat, February 2026: you change one small thing and four other features break. You ask the model to fix those, and something else moves. One developer's line, quoted there: the model will fix one thing and destroy ten others. The intent behind the working version was in the chat, and the chat is gone. The code cannot explain why it did what it did.
A passed test suite that no longer tests. The ACM TechBrief on vibe coding notes that agents have been observed modifying, disabling, or removing tests rather than correcting the code. The suite is green. The bug is in production.
The pile of files that makes this loop worse is AI-generated code technical debt.
What to check when the demo worked
Walk the actions that change money or records. Ignore the landing page.
- Place a real or live-mode charge, then send the webhook twice. You should have one order.
- Refund part of it, and dispute one. The database and the provider should tell the same story.
- Do the core action as two users at once: two bookings of the last slot, two edits of the same row. One of them has to lose cleanly.
- Force a timeout on the call to Stripe, the model, or your database. The user should see a failure, and the row should not say "paid" or "sent."
- Read the tests on that path. If they were skipped, deleted, or only check that a function returns, add the assertion back before the next prompt.
Then stop prompting that path until those five are true. The full order, security included, is in fix a vibe-coded app.
If this is your app, send the repo.
A 30-minute scope call. We read what is live, name what is dangerous, and quote a fixed scope.
How Techtribe stabilizes a live app
We reproduce the wrong outcome with the inputs production actually sends: a retried webhook, a second user, a refund. The fix is that transition, plus a test that fails if it regresses. We do not regenerate the app to get there.
If the product also needs monitoring, a real auth model, and a defined architecture, that scope is a Production MVP: evals, regression tests, and cost, latency, and quality monitoring, on your cloud. The price and the boundary are on the packages page. A single broken path does not require that package. The scope call is where we say which one you are in.
Bring the URL, the repo, and one example of a user who hit the wrong outcome. Thirty minutes is enough to tell you whether we can fix it on a fixed scope.
Questions
Why does an AI-generated app work in the demo and break in production?
The demo walks the happy path. Production adds a second user, a webhook retry, a refund, a timeout, and an input the prompt never mentioned. The code often has no branch for those, and it still returns success.
What is a silent business-logic bug?
The request finishes without an error, and the outcome is wrong: a payment recorded twice, a booking that overlaps, a user who can open someone else's data. Logs stay quiet because nothing threw.
Why does fixing one bug break other features?
The agent rewrites more than the broken path. It cannot see the whole product, the original prompt is gone, and the tests on the other paths are missing or were weakened so the last change would pass.
Should I keep prompting, or stop and get it repaired?
Stop adding features on a path that moves money or user data until that path has been read by a person. Another prompt is how the last three fixes undid each other.