There is nothing wrong with using AI to write code. We use it every day. The problem starts when nobody owns the thinking. A quick prototype can turn into a business risk: neat demo, weak foundations, expensive cleanup.
More businesses are turning up with exactly this. The app looked finished. Then came the outages, the security scare, the missing data, or the fear that changing anything will break everything else. We come in, stabilise it, fix what is worth fixing, and tell you what is salvageable.
Why AI-built code so often breaks
This isn’t a hunch. The evidence has been stacking up.
- Veracode’s Spring 2026 review of more than 150 AI models found that, with no security guidance, 45% of the code they generated introduced a known security vulnerability. Bigger and newer models were barely safer, and for Java fewer than a third of the samples came out secure. The weakness is baked into how these tools work, not a bug the next release will fix by itself.
- Stanford researchers showed the trap that makes this worse: developers using an AI assistant not only wrote less secure code, they were more confident it was secure. The holes ship because nobody thinks to look for them.
- GitClear, analysing hundreds of millions of lines of code, found that “churn” (code rewritten or reverted within a fortnight) climbed as AI tools spread, while genuine refactoring fell. Output goes up; understanding goes down.
- Google’s 2025 DORA report, the largest ongoing study of how software actually gets delivered, again found AI adoption linked to lower delivery stability. Its blunt framing: AI is an amplifier. Strong teams get stronger, and teams without solid testing and review just ship their problems faster.
The pattern is consistent. AI raises output and lowers the floor on quality at the same time. In experienced hands, with review and testing wrapped around it, that trade is manageable. Without those guardrails, you’re shipping code whose risks nobody has counted.
What it costs when it fails
The bill doesn’t arrive as a line item called “bad code”. It arrives as downtime, lost trust and lost revenue.
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 around six hours. Another wiped roughly 6.3 million orders in a single day. The response was a company-wide mandate for two-person review on hundreds of customer-facing systems. If it can happen there, with all their engineering depth, it can happen to a business running an app built in a hurry.
Outages are expensive even when nothing is malicious. Independent surveys put an hour of downtime at around US$100,000 for a small business and above US$300,000 for most larger organisations (ITIC). You don’t need enterprise numbers to feel it. A checkout that fails over a weekend, a portal customers stop trusting, or a data leak you have to disclose all cost far more than the rushed build ever saved. Trust is the slowest thing to win back.
We are vibe-coding cleanup specialists
We take on the projects other people would rather restart. A typical rescue runs in four stages, and you get a clear answer at the end of the first one:
- Audit. We read the code, map the architecture and find the real risks: the security holes, the parts with no tests, the spots where one change breaks five others. You get an honest written picture of the state it’s in.
- Stabilise. We put out the fires first: the reliability traps and security issues that could take you down or expose data. Stop the bleeding before anything else.
- Repair. We fix, test and document what’s worth keeping, and bring the codebase up to a standard your team or ours can safely maintain. It’s the same engineering discipline we bring to every web and app build.
- Plan. We set out what to finish, what to rebuild and what to retire, with the cost of each, so you can decide with eyes open.
Security isn’t a bolt-on at the end of this. It shapes the whole job, the same way it shapes our approach to security generally.
AI is a tool, not the whole job
Our position is simple. AI is genuinely useful for writing code, and we won’t pretend otherwise. What it can’t do is own the outcome: decide what should be built, judge whether an answer is safe, or carry the responsibility when it’s wrong. Treated as an assistant to a person who knows what they’re doing, it makes good engineers faster. Treated as the engineer, it produces software that looks right until production exposes the gaps, a point we make in prompts are not an AI strategy and when not to use AI.
The hardest part of any AI-assisted project is the same as it has always been: the unglamorous middle, where a working demo has to become something dependable. We wrote about that crossing in from proof of concept to production.
When a rescue isn’t the right call
Sometimes the honest answer is that a rebuild is cheaper than the repair, and we’ll say so rather than bill you to keep patching something that should be replaced. We help weigh that the same way we help clients choose between buying, building and integrating in buy, build or integrate, and we stay upfront about what custom software actually costs either way.
If you’ve got a build that’s wobbling, a vibe-coded app that outgrew its foundations, or code nobody trusts, book a discovery call and tell us what’s going wrong. The first thing you’ll get is a straight answer.