The £400+ an Hour AI Disaster Cleanup Business

I charge £400 an hour to fix AI disasters.

Let me say that again, because it still makes me smile: £400. Per hour. And I am busy. There is a queue. I am turning down work.

This is the new gold rush, and if you are an experienced developer who actually knows what you are doing, you are currently printing money. For the first time in history, we are outearning law firms. Let that sink in. The profession that charges £400 an hour for someone to read documents slowly is now being outbilled by people who can actually fix things. The irony is delicious. For years, people told us AI would replace developers. Instead, AI has created more work for experienced developers than we have ever had, at rates we could not have charged five years ago without being laughed out of the room.

The companies calling me are not stupid. They are desperate. They hired an agency, or a junior developer, or a team of people who had never built production software before but who could prompt ChatGPT really well. The project started fast. The demos looked impressive. And then it all fell apart, slowly at first and then all at once, and now they are calling me at £400 an hour because the mess is so profound that cleaning it up requires someone who actually understands how software works.

This article is about that mess. What causes it. What it looks like. Why it costs so much to fix. And how to avoid becoming one of my clients, unless you enjoy writing very large cheques to people like me.

The Vibe Coding Revolution and Its Casualties

Let me explain what happened, because it happened fast.

AI coding tools got good. Really good. Good enough that someone with no programming experience could describe what they wanted and get working code back. Good enough that agencies could hire cheap staff, hand them Claude or GPT, and ship projects that looked functional.

The key word is "looked."

Vibe coding, as it came to be called, is the practice of building software by describing what you want to an AI and accepting whatever it produces. No architecture. No testing strategy. No understanding of why the code works, only that it appears to work right now, in this specific scenario, when you click the buttons in this specific order.

For demos, vibe coding is magic. For production systems that need to handle edge cases, scale under load, maintain data integrity, and not fall over when a user does something unexpected, vibe coding is a ticking bomb.

The bomb is now going off across the industry, and I am the bomb disposal unit. The pay is excellent.

The Testing Apocalypse: TDD and BDD Are Not Optional

Here is a conversation I have had, with variations, at least thirty times in the past year.

Me: "Where are the tests?"

Client: "The what?"

Me: "The automated tests. Unit tests. Integration tests. The things that verify the code works."

Client: "I do not think there are any. The developers said they tested it."

Me: "Manually?"

Client: "I guess? They clicked around and it worked."

Me: "And now it does not work."

Client: "No. That is why we called you."

This is the foundational disaster of vibe-coded projects: there are no tests. Not inadequate tests. Not poorly written tests. No tests at all. Zero. The test coverage is not low; it is nonexistent.

I ask the agencies and developers whose work I am fixing: do you know what TDD is? Test-Driven Development? The practice of writing tests before you write code, so that you know what the code should do and can verify that it does it?

Blank stares. They do not know. They have never heard of it. Or they have heard of it but think it is some old-fashioned practice that AI has made obsolete. It has not.

BDD? Behaviour-Driven Development? Writing specifications in plain language that become executable tests? Describing the expected behaviour of the system before building it so that everyone, developers and stakeholders alike, agrees on what "working" means?

More blank stares. They do not know what that is either.

These are not junior developers. These are agencies charging tens of thousands of pounds for projects. These are "AI-native development shops" marketing themselves as the future. And they do not know the absolute basics of professional software development.

The result is code that works until it does not, with no way to know what broke or why.

The Fix One Thing Break Three Things Problem

Without tests, every change is a gamble.

The client reports a bug. The vibe coder asks the AI to fix it. The AI produces a fix that addresses the specific symptom described. The fix is deployed. The original bug is gone.

But something else is now broken. Something that was not tested because nothing is tested. Something that depended on the behaviour that was just changed. The client reports the new bug. The vibe coder asks the AI to fix it. Another fix is deployed. The second bug is gone.

Now two more things are broken.

This is not a hypothetical. This is the actual state of the codebases I am being paid to rescue. The git history reads like a horror novel. Fix auth bug. Fix payment bug caused by auth fix. Fix inventory bug caused by payment fix. Fix auth bug that reappeared because the payment fix reverted part of the first fix. On and on, each commit making the situation worse, each fix creating new problems, nobody understanding why because nobody understands the code.

In a properly tested codebase, this cannot happen. You write a fix, you run the tests, the tests tell you what you broke. You know immediately. You fix the regression before deploying. The system maintains integrity.

In a vibe-coded codebase, there are no tests to run. The only way to discover what broke is to deploy to production and wait for users to complain. By which point you have already broken their trust and possibly their data.

The Documentation Desert

AI does not document.

This sounds like a small thing until you are trying to understand a codebase generated by an AI, modified by someone who did not understand it, modified again by another AI, and modified a third time by someone else who also did not understand it.

Why is this function structured this way? Nobody knows. Why does this data flow through three services instead of one? Nobody knows. Why is there a delay of exactly 3.7 seconds before this action completes? Nobody knows, but if you remove it, everything breaks.

In a properly built system, there are comments explaining non-obvious decisions. There are README files describing architecture. There are commit messages explaining why changes were made. There are design documents capturing the reasoning that led to the current structure.

In a vibe-coded system, there is none of this. The code exists without context. It is an artefact without provenance. Understanding it requires reverse engineering, which requires expertise, which requires someone like me, which requires £400 an hour.

I spend at least 30% of every rescue project just understanding what the hell is going on. This is not productive work. It is not adding value. It is archaeology. But it is necessary because nobody documented anything, and now the only way to understand the system is to read every line of code and reconstruct the intent from the implementation.

The Critical Path Problem

Remember critical path? The sequence of tasks and features that must work for the product to function at all?

Vibe coding destroys the critical path slowly, without anyone noticing.

Here is how it happens. The initial build works. The critical path is intact, probably by accident, because the AI happened to produce code that held together. Then changes are requested. The vibe coder prompts the AI for modifications. The AI produces modifications that accomplish the immediate goal but subtly alter something in the critical path.

Nobody notices because there are no tests. The demo still works if you click the buttons in the right order. But the edge cases are now broken. The error handling is now wrong. The data validation is now incomplete.

More changes are requested. More modifications are made. Each modification makes sense in isolation. Each modification slightly degrades the critical path. After fifty modifications, the critical path is rubble. The system only works in the exact happy-path scenario that the demos always show. Everything else fails.

The client does not discover this until launch. Users do not follow the happy path. Users make mistakes. Users have slow connections. Users click buttons twice. Users paste emoji where they should not. Users do unexpected things, and the system collapses because nobody ever tested those scenarios.

Now the client calls me. The cleanup is not just fixing bugs. It is reconstructing the critical path from the debris. It is figuring out what the system was supposed to do, which nobody can tell me because nobody understood it in the first place. It is writing the tests that should have existed from the beginning, then using those tests to stabilise the codebase, then fixing the actual issues one by one.

This is a monumental task. It takes weeks. Sometimes months. At £400 an hour.

The Maths of False Economy

Let me show you why this matters with some numbers.

A company needs an e-commerce feature built. They get two quotes.

Option A: A proper development shop with experienced engineers. They want £80,000 and three months. They will build with tests, documentation, and proper architecture. They explain their process in detail. It sounds expensive.

Option B: An "AI-native agency" with cheap staff and impressive demos. They want £25,000 and six weeks. They promise rapid iteration and cutting-edge technology. It sounds like a bargain.

The company chooses Option B. Obviously. It is a third of the cost in half the time.

Six weeks later, they have a demo that works beautifully. Two weeks after launch, the problems start. Small bugs at first. Then bigger ones. Then data integrity issues. Then a security incident. Then the agency ghosts them because fixing it would take more hours than they quoted for the entire project.

Now they call me.

I assess the damage. The codebase is untestable. The architecture is incoherent. The critical path is broken in at least eight places. The data model has fundamental flaws that require migration to fix. There is no documentation of any kind.

My estimate: 200 hours to stabilise, test, and repair. At £400 an hour, that is £80,000. Plus the £25,000 they already spent on Option B. Plus the revenue lost during the weeks of instability. Plus the customers lost to bad experience. Plus the reputation damage.

Total cost of the "cheap" option: well over £100,000 and six months of pain.

Total cost if they had chosen Option A: £80,000 and three months.

This is the maths of false economy. Cheap development is not cheap. It is deferred expensive development plus interest plus penalties. The bill always comes due.

What the Cleanup Actually Involves

Let me walk you through what happens when you hire me to fix a vibe-coded disaster, so you understand why it costs what it costs.

Phase One: Archaeology. I read the code. All of it. I trace data flows. I map dependencies. I identify what the system is supposed to do by observing what it actually does. I interview anyone who knows anything about the requirements. I reconstruct the spec that never existed. This alone takes 20-40 hours depending on system size.

Phase Two: Test Infrastructure. I set up the testing frameworks that should have been there from the start. I configure CI/CD pipelines. I establish the basic infrastructure needed to develop safely. Another 10-20 hours.

Phase Three: Critical Path Tests. I write tests for the critical path. Not comprehensive tests for everything, not yet. Just the tests that verify the core functionality. The things that absolutely must work. This is painstaking because the code is often so tangled that testing it requires refactoring it, and refactoring without tests is dangerous. 40-60 hours.

Phase Four: Stabilisation. With tests in place, I can finally start fixing things without fear of breaking other things. I address the critical path issues first. I fix the data integrity problems. I repair the security holes. Each fix is verified by tests. Progress is measurable. 40-80 hours depending on damage.

Phase Five: Edge Cases. The happy path works. Now I address all the scenarios that real users encounter. Error handling. Validation. Concurrent access. Network failures. Malformed input. The things that vibe coding never considers because AI demos do not include unhappy paths. Another 20-40 hours.

Phase Six: Documentation. I document what I learned. Architecture diagrams. API documentation. Deployment guides. The knowledge that should have been captured during development but never was. 10-20 hours.

Total: 140-260 hours. At £400 an hour. For a system that should have been built properly in the first place.

I Use AI Too, But There Is a Difference

I want to be clear about something: I am not anti-AI. I use AI tools daily. They make me faster and more productive. They are genuinely useful.

But I use them as tools, not as replacements for understanding.

When I ask an AI to generate code, I read the code. I understand what it does. I evaluate whether it is the right approach. I modify it when needed. I test it. I document it. The AI accelerates my work; it does not do my work.

The vibe coders do not do this. They prompt, accept, deploy. The code is a black box to them. They do not know if it is good or bad, secure or vulnerable, efficient or wasteful. They cannot evaluate it because they do not have the knowledge to evaluate it. They are not developers using AI. They are AI operators who do not understand what the AI produces.

This is the difference. AI in the hands of an experienced developer is a force multiplier. AI in the hands of someone who does not understand software development is a disaster generator.

The tool is the same. The outcomes are opposite.

How to Not Become My Client

If you are a company considering a software project, here is how to avoid paying me £400 an hour to fix it later.

Hire people who understand software development. Not people who can prompt AI. People who know what TDD is. People who have built production systems. People who can explain their architectural decisions. The AI tools are just tools. The knowledge of how to build software is what matters.

Demand tests from day one. Ask to see the test suite. Ask about test coverage. Ask what happens when the tests fail. If the developers look confused by these questions, run. You are about to pay for a disaster.

Require documentation. Every non-obvious decision should be documented. Every API should have documentation. Every deployment should have a guide. If the team says documentation slows them down, they are building something nobody will be able to maintain.

Insist on code review. Actual humans who understand the code should review every change before it is deployed. Not AI review. Human review. People who can ask "why is this structured this way" and expect a coherent answer.

Pay for experience. Yes, experienced developers cost more per hour. No, they do not cost more total. The £80,000 project that works is cheaper than the £25,000 project that requires £80,000 to fix.

Or ignore all of this advice, hire the cheap AI-native agency, and call me in six months. I will be happy to help. At £400 an hour.

The Gold Rush Will Not Last Forever

I am enjoying this market. I would be lying if I said otherwise. The demand for people who can fix vibe-coded disasters exceeds the supply. The rates are extraordinary. The work, perversely, is satisfying because the before and after are so dramatic.

But it will not last forever.

Eventually, companies will learn. The horror stories will accumulate. The maths of false economy will become common knowledge. Best practices will reassert themselves. The vibe coding agencies will go out of business or start hiring actual developers. The market will correct.

Until then, the experienced developers are printing money. We are the adults cleaning up after the children played with matches. We are the surgeons treating the patients who thought they could operate on themselves with YouTube tutorials. We are, frankly, having the time of our professional lives.

If you are a senior developer reading this, raise your rates. The market will bear it. The demand is there. You have skills that cannot be prompted into existence.

If you are a company reading this, make better decisions. Hire properly. Build properly. Test properly. It is cheaper in the end, and you will not have to explain to your board why the "cost-effective" project cost three times budget to fix.

And if you are someone who got into "development" because AI let you ship code without understanding it, I have some advice: learn to actually develop. Learn what tests are. Learn why architecture matters. Learn the fundamentals that AI cannot teach you because you have to understand them to evaluate AI's output.

The free lunch is ending. The bills are coming due. The only question is whether you will pay them to someone like me, or whether you will invest in doing it properly from the start.

I know which option I prefer. £400 an hour. The meter is running.

Got a vibe-coded disaster that needs professional cleanup? I am currently booking at £400 per hour for AI disaster recovery, code archaeology, and test implementation. The queue is long but I am good at what I do. Get in touch with details of the mess, and I will tell you what it takes to fix it. Or do it properly from the start and save yourself the money. Either way works for me.