You built an app with Lovable, Cursor, Bolt or Claude Code, and it works. People use it. But every new feature now breaks an old one, and the AI keeps writing things again that it already wrote.

The fix is a cleanup. The problem is that a cleanup can break the app that works today, and you may not find out until a customer does.

I offer a cleanup service for AI-written code, and its whole promise is that you get proof nothing broke. Before selling that, I wanted to know whether the proof could be trusted. So I ran it on a real app and then tried to fool it.

The app

I picked an open-source web app with more than 900 stars. Its author describes it as vibe-coded, built over about a year with AI tools. It is a real product that people use, and it comes with 817 automated tests of its own.

A scan found what a year of AI-written code usually leaves behind. The same small function was written several times in different files. Old copies of files were left lying around with nothing using them. Some files had grown to thousands of lines.

The cleanup

I merged the identical copies into one, deleted the files nothing used, and split two oversized files into smaller ones. That came to 28 files changed and 2,937 fewer lines.

I left alone anything that would change how the parts of the app talk to each other. One 4,906-line piece of code stayed as it was, because splitting it is a design decision that belongs to the owner.

Then I broke it on purpose

On a throwaway copy, I removed one small step from one of the merged functions. It was the step that turns a file name into lower case.

All 817 tests still passed.

In the app itself, four export screens now produced My-Demo-File-_v2 where they used to produce my-demo-file-_v2. It is a harmless example of a serious problem. "The tests pass" is the usual evidence that a cleanup was safe, and here it would have been wrong.

What caught it

The cleanup is checked four ways, and each one compares the old version with the new one.

  1. Every piece of code in the old version is matched to the new version. All 2,348 were accounted for. This check caught the planted bug.
  2. The app's own tests run on both versions. All 817 passed on both, and no test was edited.
  3. The same screens are opened in the old build and the new build. All 16 were identical down to the pixel, with the same text, errors, network requests and saved data. This check caught the planted bug too, on exactly the four screens that use the function.
  4. The functions that were touched are run with the same inputs on both versions. 594 of 594 results were identical.

One more thing came out of the first check. Eleven places in this app define a function with the same name, and they do not all do the same thing. Merging the wrong two would change behaviour far away from the edit, so the check follows where every name leads, not only whether the text looks the same.

Checking the checks

One planted bug is an anecdote. So the cleaned code was broken in 230 small ways, one at a time, and the first check noticed all 230.

My checks were not perfect the first time, and I think you should know that. The cleanup deleted a file that a settings file still mentioned. Nothing broke, but the report should have pointed at it and did not. I fixed the check, corrected the report in public, and the report now lists that line for a person to read.

What a cleanup does not do

A cleanup that changes nothing also fixes nothing. If your app has a bug or a security hole today, a careful cleanup keeps it, because keeping behaviour the same is the whole point.

Finding security problems, such as open database rules or leaked keys, is a different job, usually called an audit. Many founders need that before launch. Make sure you know which of the two you are buying, because they are often sold under one name.

What you get when you hire me

It always starts with a scan, which costs $95. You get a report on your whole repository that lists the duplicated functions, the look-alikes that are not safe to merge, the files over 1,000 lines and the values that are retyped in many places. It ends with a fixed price for the cleanup, so you know the cost before you commit to anything. If you then hire me for the cleanup, the $95 comes off its price.

Then we agree on what gets cleaned and which parts of the app matter most to you. I do the cleanup in small steps and run the four checks above on your app.

You receive two things. The first is one pull request, which is the cleaned code ready for you to accept. The second is the proof report, which lists every piece of code that was moved, merged or removed, with before and after screenshots of your screens.

If a change in behaviour caused by my cleanup shows up within 30 days, I fix it free.

Your code runs on my machine only inside a sandbox with no internet, after its packages have been checked against a public malware database. I am happy to sign an NDA.

The service covers JavaScript and TypeScript apps, the languages that tools like Lovable and Bolt normally produce for web apps. It does not cover other languages such as Python or Swift.

Three questions for anyone you hire

Whoever does your cleanup, these are worth asking.

  1. What evidence will I get that compares the old version with the new one?
  2. What can that evidence not see?
  3. Has it ever caught a mistake planted on purpose?

If the only answer is "the tests pass", you now know what that is worth.