The €400 an hour AI disaster cleanup business

Cleaning up AI built software is now a business

There is a new line of work in software: fixing what AI built. In September 2025, 404 Media reported that freelance developers and entire companies are "making a business out of fixing shoddy vibe coded software", and that the "vibe coding cleanup specialist", once a LinkedIn joke, is "actually a growing profession".¹ For years people said AI would replace developers. So far it has also created a great deal of work for the developers who know how to repair what it produced.

This article is about that work. What causes the mess, what it looks like from the inside, why it costs so much to fix, and how to avoid needing it at all.

Where the €400 an hour comes from

The figure in the title is the rate I use for the cleanup specialist in this article's examples. It is not my rate. My published rate for development is €195 an hour, shown next to the sterling rate of £175, and it is on the pricing page for anyone to see. I picked €400 for the examples because it is a believable premium for senior, emergency work in a city, and because it makes the arithmetic easy to follow.

It is also not the eye watering figure it sounds like. A common line is that people fixing code now outearn law firms. They do not. The best published yardstick is British: the guideline hourly rates that the courts in England and Wales use for solicitors' costs, set in pounds and in force from 1 January 2026. They put a solicitor with over eight years' experience in central London at £579 an hour, and one with over four years at £393, or £327 in the City and central London band.² At the European Central Bank's reference rate for 6 November 2026, one euro bought 0.83415 pounds,³ so €400 is about £334. So €400 an hour buys you, roughly, a mid level London solicitor. The point of the title is not that cleanup pays like law. It is that the cleanup bill, at any sensible senior rate, is far larger than anyone expected when they chose the fast route.

Worked example: what one rescue costs at the example rate

An invented online shop needs 200 hours of rescue work, a figure I explain in the section on the cleanup phases. At the example rate:

1. Hours: 200.
2. Rate: €400 an hour.
3. Cost: $200 \times 400 = 80{,}000$, so €80,000.

That is before anyone counts the sales lost while the shop was misbehaving. Hold on to that €80,000, because it comes back when we compare two quotes.

Vibe coding works in the demo

AI coding tools got good enough that someone with no programming background could describe what they wanted and get working code back. Good enough that some agencies could hire inexperienced staff, hand them an AI assistant, and ship projects that looked finished.

The key word is "looked".

Andrej Karpathy coined the name vibe coding in February 2025, for a style of building where you "fully give in to the vibes" and "forget that the code even exists": accept every change, paste the error messages back in, never read the diffs. He was clear that it suits "throwaway weekend projects".⁴ No architecture, no testing strategy, no understanding of why the code works, only that it appears to work right now, when you click the buttons in this order.

For a demo, that is close to magic. For a production system that must handle odd input, survive load, keep its data consistent and not fall over when a customer does something unexpected, it is a slow fuse.

The research says the same from several sides. In a randomised controlled trial run by METR in 2025, 16 experienced open source developers completing 246 real tasks took 19% longer with AI tools allowed, while believing afterwards that the tools had made them 20% faster.⁵ When a research team asked GitHub Copilot to complete 89 security relevant scenarios, about 40% of the 1,689 programs it produced were vulnerable.⁶ And Google's DORA research programme found in its 2024 survey that, as AI adoption increased, it was accompanied by an estimated 7.2% reduction in delivery stability.⁷ That last figure is an association from a survey, not proof of cause, but it points the same way: speed you can feel is not the same as software you can rely on.

I wrote about where these systems break first, the database, the framework and the language, in the hidden cost of AI built architectures. This article is about the cleanup that follows.

No tests means nothing tells you what broke

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

"Where are the tests?"

"The what?"

"The automated tests. Unit tests, integration tests. The things that check the code still does what it should."

"I don't think there are any. The developers said they tested it."

"By hand?"

"I suppose so. They clicked around and it worked."

"And now it doesn't."

"No. That's why we called you."

This is the foundation of almost every vibe coded mess: there are no tests. Not weak tests, not old tests. None.

Two practices exist precisely for this, and neither is new. Test driven development (TDD), which Kent Beck developed in the late 1990s, guides the work by writing a failing test first and then the code that makes it pass, so you know what the code should do and can prove that it does.⁸ Behaviour driven development (BDD), which Dan North introduced in 2006, describes the behaviour in plain sentences of the form "given some initial context, when an event occurs, then ensure some outcomes", so that the business and the developers agree on what "working" means before anyone builds it.⁹ Those sentences then run as tests.

Plenty of teams selling AI built projects for tens of thousands of euro cannot explain either. Some have heard of them and believe AI has made them obsolete. It has done the opposite. When a machine writes code faster than anyone can read it, an automated check that the behaviour is still right is the only thing standing between you and your customers. I go into the practice in TDD and BDD in Ruby on Rails and in Cucumber BDD.

Worked example: one behaviour, written down before the code

Prospect Hill Paper Co. is an invented stationery shop in Galway, at prospecthillpaper.example. Its owner wants free delivery on orders of €40 or more. Written as a BDD scenario, before any code exists:

Feature: Free delivery threshold

  Scenario: An order at the threshold ships free
    Given a basket worth €40.00
    When the customer reaches the delivery step
    Then the delivery charge is €0.00

  Scenario: An order just below the threshold pays for delivery
    Given a basket worth €39.99
    When the customer reaches the delivery step
    Then the delivery charge is €3.95

Step by step:

1. The owner reads the two scenarios and confirms they are right. That takes two minutes and settles the question "is €40 itself free?" before it becomes a bug.
2. The developer, or the AI, writes the code until both scenarios pass.
3. Six months later someone asks the AI to "tidy up the checkout". It changes >= to > in the threshold check. The first scenario fails at once, on the developer's machine, not in a customer's basket.

Without the scenarios, the same change ships, and the shop finds out when a customer with a €40 basket complains about a €3.95 charge.

Fix one thing, break three

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 for the symptom described. The fix ships and the original bug is gone. But something else now fails, something that depended on the behaviour that just changed and that nobody checked, because nothing is checked. The client reports the new bug. Another fix ships. Now two more things are broken.

The vendors in my £35,000 lesson showed the same pattern from the outside. From the inside, the git history reads like a thriller nobody wanted:

fix login redirect
fix payment total after login fix
fix stock count after payment fix
fix login redirect (again)
revert part of payment fix
fix payment total

In a tested codebase this loop breaks itself. You write a fix, run the tests, and the tests tell you what you broke before anything ships. In an untested one, the only test suite is your customers.

The diagram runs from top to bottom. Both branches start from the same fix. The only difference is whether something checks it before customers do. The "no" branch has no end of its own: it leads straight back to the top.

How fast untested changes add up

You can put a number on the gamble. Suppose each change has some small chance of breaking something else. The chance that a run of changes breaks at least one thing is

$$P_{\text{break}} = 1 - (1 - p)^{k}$$

where $P_{\text{break}}$ is the probability that at least one of the changes breaks something, $p$ is the probability that a single change breaks something, and $k$ is the number of changes. The formula multiplies the chances that each change is harmless, $(1 - p)$, and takes the result away from one. It assumes the changes are independent, which is generous to the untested codebase. The rules behind it are in Foundations: probability.

Worked example: twenty small changes

Assume, for the example, that each change to an untested codebase has a one in ten chance of breaking something elsewhere, so $p = 0.1$.

1. After five changes: $1 - 0.9^{5} = 1 - 0.590 = 0.410$, a 41% chance that something is already broken.
2. After 20 changes: $1 - 0.9^{20} = 1 - 0.122 = 0.878$, an 88% chance.
3. With tests that catch, say, nine in ten of those side effects before release, the chance that a change ships a breakage falls to $p = 0.01$, and after 20 changes $1 - 0.99^{20} = 1 - 0.818 = 0.182$, or 18%.

Twenty changes is a few weeks of ordinary work. Without tests, a break is not a risk, it is the expected outcome.

No documentation turns every fix into archaeology

AI does not document unless someone asks it to, and in a vibe coded project nobody asked.

That sounds small until you try to understand a codebase generated by an AI, changed by someone who did not understand it, regenerated by another AI, and changed again by someone else. Why is this function shaped like this? Nobody knows. Why does this data pass through three services instead of one? Nobody knows. Why does this action wait exactly 3.7 seconds before it completes? Nobody knows, but remove the wait and something else breaks.

A well built system answers those questions in writing: comments on the decisions that are not obvious, a README that explains the architecture, commit messages that say why, and short records of the big decisions. A vibe coded system has none of these. The code exists without context, and the only way to recover the intent is to read every line and reconstruct it from what the code does.

I spend at least 30% of every rescue project just understanding what is going on. It adds nothing new. It is archaeology. But nothing else can start until it is done.

Worked example: a decision record that saves a week

Dock Road Coffee Supply is an invented coffee wholesaler in Limerick, at dockroadcoffee.example. Its order sync waits 3.7 seconds before writing to the warehouse system. Two lines in a decision record would have explained it:

Decision 7: wait 3.7 seconds before sending an order to the warehouse.
Why: the payment provider confirms by webhook up to three seconds after
checkout. Sending earlier created warehouse orders for failed payments.
Replace with: send on the payment webhook instead of on a timer.

Step by step, what the record changes:

1. Without it, a new developer sees a strange delay, removes it to speed things up, and the warehouse starts packing orders that were never paid for.
2. With it, the same developer reads three lines, understands that the delay is a workaround, and sees the proper fix written next to it.
3. The proper fix, sending on the payment webhook, takes an afternoon. Rediscovering why the delay existed, from an unpaid parcel and a confused warehouse, takes days.

The critical path wears away one change at a time

The critical path is the sequence of things that must work for the product to work at all: find a product, add it to the basket, pay, receive a confirmation, get the parcel. I wrote about it as a planning idea in time to market. In a vibe coded project it erodes quietly.

The first build works, often partly by luck. Then changes are requested, and each one is made by prompting the AI for the immediate goal. Each change makes sense on its own. Each one nudges something on the critical path: an error that is no longer handled, a validation that no longer runs, a status that is set in one place and not another. Nobody notices, because the demo still works if you click in the right order. After fifty such changes the system only works on the happy path, the exact route the demos always take.

Then it launches, and customers do not follow the happy path. They mistype, they lose signal halfway through, they press the button twice, they paste an emoji into the Eircode field. The system was never tested against any of that.

Worked example: the button pressed twice

Gowran Cycles is an invented bike shop in Kilkenny, at gowrancycles.example. On a slow mobile connection, a customer presses "Pay" twice. The vibe coded checkout creates two orders and takes two payments of €649. A test that writes the behaviour down catches it:

it "creates one order when the same checkout is submitted twice" do
  2.times { post "/checkout", params: { basket_id: basket.id, token: "chk_123" } }
  expect(Order.where(basket_id: basket.id).count).to eq(1)
end

Step by step:

1. The test submits the same checkout twice, with the same one time token, as the double press does.
2. It expects one order. On the vibe coded checkout it finds two, so it fails.
3. The fix stores the token with the first order and returns that order on the second request instead of creating a new one.
4. The test passes, and it keeps running on every future change, so a later "tidy up" cannot quietly bring the double charge back.

One refund of €649 and one angry review cost more than the ten minutes that test takes to write.

The maths of false economy

Here is why the quote with the smaller number is often the more expensive project. The numbers below are an invented example, with every assumption stated.

A company needs an eCommerce feature built and gets two quotes.

Option A: an experienced engineer or a small senior team. €80,000 and three months, built with tests, documentation and a considered architecture. It sounds expensive.

Option B: a cheap agency selling itself as "AI native". €25,000 and six weeks, with impressive demos and promises of rapid iteration. It sounds like a bargain, at a third of the price in half the time.

The company picks option B. The demo is lovely. Two weeks after launch the problems start: small bugs, then bigger ones, then data that no longer adds up, then a security incident. The agency stops answering, because fixing it would take more hours than it quoted for the whole project.

The total cost of an option is

$$C = B + h \times r + L$$

where $C$ is the total cost, $B$ is the build price, $h$ is the number of rescue hours, $r$ is the hourly rate for the rescue, and $L$ is the revenue lost while the system misbehaves. For option A, $h$ and $L$ are assumed to be zero, which flatters it slightly, since every system needs some fixing. It is plain addition and multiplication. When the rescue is uncertain, it becomes an expected cost, which Foundations: expected value explains and the second example below uses.

Worked example: two quotes for the same feature

Option B, with the example's assumptions:

1. Build: $B = 25{,}000$.
2. Rescue: $h = 200$ hours at $r = 400$, so $h \times r = 80{,}000$.
3. Lost revenue: assume the shop takes €10,000 a week, and six weeks of instability cost it a quarter of that, so $L = 6 \times 10{,}000 \times 0.25 = 15{,}000$.
4. Total: $C_B = 25{,}000 + 80{,}000 + 15{,}000 = 120{,}000$, so €120,000, and about six months from first quote to a working system.

Option A: $C_A = 80{,}000$, in three months.

Each bar is one way of counting the same decision, and the vertical axis is the total in euro. The second bar is the only one anybody looked at when the decision was made. The fourth is what the company actually paid. The customers who did not come back are not in any bar at all.

Worked example: when the rescue is not certain

Not every fast, untested build needs a full rescue. So the fairer question is how likely the rescue has to be before option B costs more on average. With an assumed probability $q$ that the rescue is needed, the expected cost of option B is $E[C_B] = 25{,}000 + q \times 95{,}000$, where 95,000 is the rescue plus the lost revenue. This is an expected value, explained in Foundations: expected value.

1. Set the expected cost equal to option A: $25{,}000 + q \times 95{,}000 = 80{,}000$.
2. Solve: $q = 55{,}000 / 95{,}000 = 0.58$.
3. Read it: if more than about six in ten such projects need the rescue, option B costs more on average.

The average is not the whole story either. Expected value says nothing about the one time you cannot afford the bad outcome, and a €120,000 bill for a €25,000 project is exactly that outcome for many small businesses. The bill for a missing foundation always comes due. The only question is how much interest it has collected.

What the cleanup actually involves

When a business brings me a vibe coded system to rescue, the work runs in six phases. The hours are my estimates for a typical system of the size in the example, and the ranges depend on how large and how damaged it is.

1. Archaeology, 20 to 40 hours. Read all the code. Trace how the data flows, map the dependencies, work out what the system is supposed to do by watching what it actually does, and interview anyone who knows the requirements. In effect, write the specification that never existed.
2. Test infrastructure, 10 to 20 hours. Set up the testing tools that should have been there from the start, and a pipeline that runs the tests on every change before anything is deployed (continuous integration and delivery, CI/CD).
3. Critical path tests, 40 to 60 hours. Write tests for the things that absolutely must work. This is slow, because tangled code often has to be restructured before it can be tested, and restructuring without tests is risky. So the first tests describe what the system does today, right or wrong, and act as a safety net for everything after.
4. Stabilisation, 40 to 80 hours. With tests in place, fix things without fear of breaking others: the critical path first, then the data that no longer adds up, then the security holes. Each fix is proved by a test, so progress is measurable.
5. Edge cases, 20 to 40 hours. The happy path works. Now the routes real customers take: errors, validation, two people editing the same thing, dropped connections, odd input.
6. Documentation, 10 to 20 hours. Write down what was learned: the architecture, the interfaces, how to deploy, and why the big decisions were made.

That is 140 to 260 hours in total. The 200 hours in the example sit close to the middle.

The horizontal axis shows the six phases in order, the vertical axis the midpoint of each estimate in hours. The midpoints add up to $30 + 15 + 50 + 60 + 30 + 15 = 200$. The point to take from it: almost half the hours, the first three phases, go into understanding the system and building the safety net before a single bug is fixed. That is the price of not having built them in the first place.

Worked example: pricing the rescue phase by phase

For the invented shop in the false economy example, at the example rate of €400 an hour:

1. Archaeology: $30 \times 400 = 12{,}000$.
2. Test infrastructure: $15 \times 400 = 6{,}000$.
3. Critical path tests: $50 \times 400 = 20{,}000$.
4. Stabilisation: $60 \times 400 = 24{,}000$.
5. Edge cases: $30 \times 400 = 12{,}000$.
6. Documentation: $15 \times 400 = 6{,}000$.

Total: €80,000, the same figure as before, now with a reason behind every euro of it. Of that, €38,000 is spent before the first bug is fixed.

I use AI too, but I read what it writes

To be clear, I am not against AI. I use AI tools daily. They make me faster, and they are genuinely useful.

But I use them as tools, not as a replacement for understanding. When an AI writes code for me, I read it. I check whether it is the right approach, change it when it is not, test it and document it. The AI speeds up my work. It does not do my work.

Vibe coding skips every one of those steps: prompt, accept, deploy. The code is a black box to the person shipping it. They cannot say whether it is secure or full of holes, efficient or wasteful, because they lack the knowledge to judge it. They are not developers using AI. They are operators of a tool whose output they cannot read.

That is the whole difference. In experienced hands, AI multiplies good work. Without understanding behind it, it multiplies mistakes, faster than anyone can find them. The tool is the same. The outcomes are opposite. I wrote more about why that understanding matters in when one expert beats an entire team.

How to avoid needing a cleanup

If you are about to commission software, here is how to avoid paying a specialist to rescue it later.

Hire people who understand software, not just prompts. Ask whether they have built and run production systems, and whether they can explain their architectural decisions. The AI tools are the same for everyone. The judgement is what you are paying for.

Ask for tests from the first week. Ask to see the test suite, how much of the system it covers, and what happens when a test fails. If the question confuses them, that is your answer.

Ask for documentation as part of the deliverable. Decisions that are not obvious get written down. Interfaces get described. Deployment gets a guide. A team that says documentation slows it down is building something nobody else will be able to maintain.

Make sure a person reviews every change. Someone who understands the code reads each change before it ships, and can answer "why is this built like this?" with a real reason.

Compare the total, not the quote. Experienced people cost more per hour. Over the life of a project they usually cost less, for the reasons in the false economy example. The true cost of outsourcing development goes further into what a quote leaves out.

Worked example: five questions for two quotes

An invented Waterford homeware shop, at johnstownhome.example, has two quotes for a new checkout and asks both suppliers the same five questions:

1. "Can I see the tests for a project you built last year?" Supplier one shares a test suite. Supplier two says they "test thoroughly by hand".
2. "What happens when a test fails?" Supplier one: "Nothing ships until it passes." Supplier two is not sure what is meant.
3. "Who reviews the code before it goes live?" Supplier one names a person. Supplier two says the AI reviews it.
4. "What documentation do I get at handover?" Supplier one lists architecture notes, a deployment guide and decision records. Supplier two offers a walkthrough call.
5. "If you disappeared tomorrow, could another developer take over?" Supplier one says yes and explains why. Supplier two says it would not come to that.

The quotes differ by €20,000 in supplier two's favour. The answers suggest which one will cost more in the end.

This gold rush will not last

There is real demand right now for people who can untangle vibe coded systems, and the work, oddly, is satisfying, because the before and after are so far apart.

It will not last for ever, and it should not. The stories will pile up. The maths of false economy will become common knowledge. Good practice will reassert itself, and the agencies that sold speed without understanding will either learn to engineer or close.

Until then, a few words for each reader.

If you are a senior developer: the fundamentals you learned, testing, architecture, writing things down, are worth more now, not less, because they are exactly what a prompt cannot produce.

If you run a business: build properly, test properly, document properly. It costs less in the end, and you will never have to explain to your board why the project that looked like the bargain cost several times its budget.

And if you got into development because AI let you ship code without understanding it: learn the craft underneath. Learn what tests are and why architecture matters. You need that knowledge to judge what the AI gives you, and nobody can prompt it into you.

The bill always comes. You can pay it up front to someone who builds it properly, or later, with interest, to someone who cleans it up.

Footnotes

1. Emanuel Maiberg, The Software Engineers Paid to Fix Vibe Coded Messes, 404 Media, 11 September 2025, https://www.404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/

2. HM Courts and Tribunals Service, Solicitors' guideline hourly rates, guideline hourly rates in force from 1 January 2026 (England and Wales), GOV.UK, updated 1 January 2026, https://www.gov.uk/guidance/solicitors-guideline-hourly-rates

3. European Central Bank, Euro foreign exchange reference rates, Pound sterling (GBP), reference rate of 6 November 2026, https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/eurofxref-graph-gbp.en.html

4. Andrej Karpathy, post on X introducing "vibe coding", 2 February 2025, https://x.com/karpathy/status/1886192184808149383

5. Joel Becker, Nate Rush, Elizabeth Barnes and David Rein, Measuring the Impact of Early 2025 AI on Experienced Open Source Developer Productivity, METR, arXiv:2507.09089, 2025, https://arxiv.org/abs/2507.09089

6. Hammond Pearce and others, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions, IEEE Symposium on Security and Privacy 2022, arXiv:2108.09293, https://arxiv.org/abs/2108.09293

7. Nathen Harvey and Derek DeBellis, Highlights from the 10th DORA report, Google Cloud Blog, 23 October 2024, https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report

8. Martin Fowler, Test Driven Development, martinfowler.com, updated 11 December 2023, https://martinfowler.com/bliki/TestDrivenDevelopment.html

9. Dan North, Introducing BDD, first published in Better Software magazine, March 2006, https://dannorth.net/blog/introducing-bdd/