Vibe coding broke in production. Now what?

By the middle of 2026 the pattern is everywhere. Software gets built fast, usually by someone prompting an AI tool rather than an engineer, and it looks finished. Then it meets actual users and messy data and starts falling over. An outage one week. A security disclosure the next. A database that will not come back the way it went down. People are calling it vibe coding: you describe what you want and accept whatever the model hands back. Fine for poking at an idea on a weekend. A bad way to run a business.

We are not anti-AI. We use it every day. The argument here is narrower and pretty hard to argue with. Code that no experienced person has read or tested does not belong in production, no matter who or what wrote it. When it ends up there anyway, somebody has to clean it up. More and more, that somebody is us.

What vibe coding leaves behind

A vibe-coded app can demo beautifully. The trouble is everything a demo never shows you.

You get security holes. The login that almost checks permissions. The database left open to the internet. The API key pasted into the front end where anyone with a browser can read it. You get logic that works only for the happy path and falls apart the second a user does something slightly odd, which users do constantly. There are no tests, so every change is a guess about whether you just broke something else. And the code itself is a black box, often to the person who prompted it. When the AI wrote it and no human took it in, there is nobody to ask how it works.

None of that is hypothetical. 2026 has handed us the receipts.

The 2026 numbers are not subtle

The security picture comes straight from the tools. Veracode’s Spring 2026 study ran more than 150 AI models through a battery of coding tasks and found that, given no security guidance, 45% of the code they generated carried a known vulnerability. Bigger, newer models barely moved the needle. For Java, fewer than a third of the samples came out secure. Do not bank on the next model release fixing this for you. Plan around the tools you actually have.

Add people and it gets worse. Stanford researchers found that developers using an AI assistant wrote less secure code and were more confident it was secure. More flaws, more certainty. That is precisely how a vulnerability slips into production with nobody worried about it.

The instability shows up at the delivery level too. Google’s 2025 DORA report, the biggest ongoing study of how software actually gets shipped, again tied AI adoption to lower delivery stability and said it plainly: AI is an amplifier. Teams with solid testing and review go faster. Teams without it just ship their problems sooner. GitClear looked at hundreds of millions of lines of code and found the same fingerprint. Code churn, the share rewritten or reverted within a fortnight, climbed while genuine refactoring fell. More code, less understanding.

When this fails in production it costs real money. In March 2026 a run of incidents at one of the world’s largest online retailers was traced internally to novel GenAI usage and unsafe change practices. One change took checkout down for about six hours. Another wiped roughly 6.3 million orders in a single day. Their fix was a company-wide rule that two people have to review any change to customer-facing systems. If a company with that much engineering muscle can get knocked over by unreviewed AI changes, a small business running a rushed app is a soft target. ITIC’s surveys already put an hour of downtime at around US$100,000 for a small business and north of US$300,000 for most larger ones. The shortcut rarely saves that much.

Why experienced hands change the outcome

Hold onto the DORA line: AI is an amplifier. The same tool in two different sets of hands gives you opposite results.

An experienced engineer uses AI to write code faster, then does the bits the AI cannot. They decide what should actually be built, read what came back, test it against the awkward cases, and refuse to ship the parts that are not safe. The AI assists. A person owns the result.

Vibe coding takes that person out. The model writes and its output goes straight to production with nobody’s judgement in the way. A power tool is handy when a tradie is holding it. Left running on the bench, it’s just a hazard. We have made the same point about AI in general in when not to use AI, and about the gap between a clever prompt and a working system in prompts are not an AI strategy.

How to tell if your build needs a cleanup

You don’t need to read a line of code to spot the warning signs. Ask yourself a few things. Does anyone on your side actually understand how the app works, or did an AI tool build most of it? Are there automated tests, or do you only find out something is broken when a customer emails you? Has a qualified person done a security review, or is “it seems fine” the whole story? Do small changes tend to break unrelated things? Is it already throwing outages, weird bugs or data problems nobody can fully explain?

If two or three of those land, take it seriously, especially if the app touches customer data, payments, or anything you would legally have to disclose after a leak.

What a cleanup actually involves

A rescue does not have to mean a rewrite, and nobody should sell it to you as one. It is disciplined engineering applied to someone else’s mess. Our code cleanup and project rescue work runs in four stages.

First we audit. We read the code, map the architecture and find the risks: the security holes, the untested parts, the places where one change breaks five others. You get a plain-language picture of the state, usually quickly. Then we stabilise, putting out the fires first, the reliability traps and security issues that could take you down or expose data. After that we repair: fix, test and document what is worth keeping, and bring it up to a standard a team can safely maintain, the same discipline we apply to any web or app build. Last, we plan. We lay out what to finish, rebuild or retire, with the cost of each, so you can decide with the full picture in front of you.

Security is not a line item at the bottom of that list. It runs through all of it, the same way it runs through our approach to security generally.

When a rebuild is the honest answer

Sometimes the foundations are too weak to build on and a targeted rebuild costs less over a year than patching forever. We will tell you that rather than bill you to keep a doomed codebase limping along. We make the same call with clients in buy, build or integrate, and we stay upfront about what custom software actually costs either way. The crossing that catches most AI-built projects is the one from a working demo to something dependable, which we covered in proof of concept to production.

If you have a vibe-coded app that outgrew its foundations, a build that is wobbling, or code nobody trusts, get in touch and walk us through what is going wrong. The first thing you will get back is a straight answer on whether it can be saved, what it would take, and whether it is even worth doing. If you’re earlier than that and still shaping the idea, our from idea to prototype work is the safer place to start, and the free AI readiness assessment is a quick way to see where you stand.