The vibe-coding hangover: who owns the app the AI built?

Somewhere in your organisation there is an application that nobody on the payroll wrote. A manager built it in Cursor over a weekend. A contractor shipped it from Lovable before their contract ended. A founder prompted it into existence in ChatGPT and, because it worked, it quietly became the thing the warehouse uses every morning. It is now running part of your business, and the honest answer to "who supports it?" is a shrug.

That shrug is what people are talking about this autumn, and it has a name: the vibe-coding hangover.

The numbers behind the hangover

The speed is real. Ask any team that has tried it: describing a feature in plain English and watching working code appear is genuinely faster than typing it by hand. The problem is what comes after the demo.

• Researchers studying vibe coding in practice describe a "flow-debt trade-off": the same seamless code generation that makes the first version fast leads to "the accumulation of technical debt through architectural inconsistencies, security vulnerabilities, and increased maintenance overhead", driven partly by "a lack of explicit design rationale" and "a tendency to prioritize quick code generation over human-driven iterative development" (Waseem et al., Vibe Coding in Practice, December 2025).
• GitClear's analysis of 211 million changed lines of code found a rise in duplicated blocks and short-term churn alongside a continued decline in code reuse: more code, less structure (summarised by Exadel).
• Stack Overflow's 2025 developer survey found more developers actively distrust the accuracy of AI tool output than trust it, and DORA's 2025 report on AI-assisted development concluded that AI "acts as an amplifier of an organization's existing strengths and weaknesses". If there was no review process before, there is still none now, only faster.
• Forrester has predicted that three quarters of technology decision-makers will face moderate to severe technical debt this year, and several industry commentators have simply called 2026 "the year of technical debt".

None of this means the tools are bad. It means the tools have moved the hard part. Writing the first version was never the expensive bit of software. Owning it for five years is.

What the hangover looks like on a Monday

We see the same handful of symptoms in almost every AI-built application that reaches us, and they are worth recognising early:

1. The integration that "just stops". The accounts sync, the payment gateway, the CRM feed. AI-generated integration code rarely handles token expiry, rate limits, or partial failure, so the first time a provider rotates a credential the sync dies silently.
2. No tests, so every change is a gamble. The generated code may be fine. Nobody can prove it, so nobody dares touch it.
3. Secrets in the code. API keys pasted into source because that is what the prompt produced. Often in a public repository.
4. One person holds it in their head. Usually the person who prompted it. Usually not a developer. Usually about to be busy with something else.
5. No environment but production. Every fix is tested on real customers.
6. Nobody knows what it costs. Cloud spend that nobody set a budget on, growing quietly.

If two or more of those describe an application you rely on, you already have a maintenance problem. It just has not had its incident yet.

Rescue or rebuild? Usually rescue

The instinctive reaction is to throw it away and "do it properly". That is expensive and, more often than not, wrong. The business already validated the idea. The workflow is right. What is missing is engineering: structure, tests, security, observability, and a named team.

Our approach is the same one we use for any system we did not build, whether it came from an outgoing supplier, an in-house developer who has moved on, or a chatbot:

Most AI-built applications come out of that first phase with a clear answer: keep the product, rebuild the plumbing. Occasionally the honest answer is "start again, and here is exactly why". Either way you decide with evidence, not with a shrug.

Using AI without the hangover

We use AI every day. It reads logs, traces, and unfamiliar code faster than any of us, clusters incidents, and drafts root-cause summaries. The difference is the guard-rails:

• Every AI insight is reviewed by a named engineer before it becomes an action.
• Secrets never enter a prompt, and your data is not sent to third-party AI services without your agreement.
• Generated code goes through the same pipeline as everything else: review, unit and regression tests, a staging slot, then a swap into production that can be rolled back in seconds.
• Infrastructure and deployments are code, so every change is traceable and the whole estate can be rebuilt from the repository.

That is the version of "AI-assisted development" that survives contact with a Monday morning.

What to do this week

You do not need a project to start. Three things you can do in an afternoon:

1. Make a list. Every application your business depends on that nobody currently supports under a written agreement. Include the ones built with AI tools, especially the ones that "just work".
2. Find the keys. For each one: where is the source code, who has the cloud login, where do the API keys live? If the answer to any of those is a single person, that is your first risk.
3. Ask for an independent look. A maintainability review or a codebase assessment is a short, fixed-cost piece of work that tells you honestly whether to rescue, rebuild, or leave well alone, and what each option costs. The report is yours either way.

Assemblysoft is a senior UK .NET, Blazor, and Azure team that has been taking ownership of other people's systems since 2009, under a published managed application support model with a written SLA, a named team, and everything kept in your name. If there is an AI-built application somewhere in your business that has quietly become important, we would rather hear about it before its first incident than after.