How do I clean up an AI-generated codebase?

Clean it up in small, reviewed steps, not in one big rewrite. A safe cleanup follows an order: (1) save a version you can always return to, (2) find out what the code actually contains, (3) protect the features that already work, (4) fix one kind of problem at a time, most dangerous first, and (5) write down what you decided. None of these steps requires you to read code. Skipping them is how a cleanup can break a product that was working.

Why clean up a product that works?

Most founders don’t start here because the code looks bad. They start here because changes have become slow, expensive, or risky.

A new feature takes three attempts. A fix in one place breaks something in another. The AI writes a second version of something that already exists. It happens to developers too. One opened a file and found the AI had quietly duplicated a function that already existed somewhere else (opens in a new tab).

Messy code costs you on every change after it. Each copy of a rule has to be found and updated. Each unused file is something the AI might read and follow. One developer spent a year following vibe-coded projects after launch. In many, the person who built the code could read it but not change it with confidence (opens in a new tab).

The point of a cleanup is to make the next change safe.

What “messy” usually means

AI-generated code tends to go wrong in the same few ways.

• Duplicates. The same rule, such as how a price is calculated, written in two or three places. Fix one copy later, and the others keep the old behavior.
• Leftovers. Pages, files, and settings from features you abandoned. Nothing uses them, but they still sit in the code and confuse the next change.
• Exposed secrets. Passwords and keys for paid services, such as a payment provider, written straight into the code instead of stored separately.
• No checks. Nothing confirms that sign-up, payment, or your core feature still works after a change.
• No record of decisions. Nobody wrote down why a page skips a login check or why prices round a certain way. So the next cleanup “fixes” it.

The five steps, in order

1. Save a version you can always return to

Before you change anything, make sure your code lives in a repository, the place where code and its full history are stored. GitHub is the most common one.

A repository lets you undo any change, however large. It also gives a developer your full history if you bring one in later. If your code still lives only within a vibe coding platform, our guide to moving to a normal GitHub workflow covers the move.

2. Find out what you have before you change it

Ask for a report, not a fix. Ask the AI to list what it finds without changing anything: rules written in more than one place, unused files, keys written into the code, and features with no tests.

A report changes nothing, so it can’t break anything. You decide what gets fixed, and in what order. You also learn how big the job is before anyone starts.

3. Put checks on what already works

A cleanup is supposed to change how the code is organized, not what the product does. To prove it, check the most important things your product does, before and after.

Choose the three to five things your product must never stop doing, such as “a new user can sign up” and “a customer can pay.” Ask for a test for each, and keep those tests with your product. A test is a small program that checks one of these automatically. Now every cleanup step has to pass them.

4. Fix one kind of problem at a time, most dangerous first

Start with anything that could hurt your users or your bill. Exposed keys come first: move them out of the code, and replace every key that was written into it, because the old one stays in the history.

Then remove duplicates, one rule at a time. Then delete leftovers. Save the reorganizing for last, because it touches the most files.

Keep each step small enough that you can say in one sentence what changed. Ask for each one as a separate proposed change that you approve before it goes live. If a step breaks something, you know which step it was.

5. Write down what you decided

A cleanup settles questions. Which copy of the pricing rule is the real one? Which page stays public on purpose?

Record those answers in a short file within the project, and give it to the AI at the start of every session. Without it, the next round of changes slowly undoes the cleanup. Our guide to why the AI keeps fixing one thing and breaking another explains why that record matters.

What to avoid

Don’t ask for “clean up the whole codebase” in one request. The AI may change hundreds of lines at once. You won’t be able to check them, and you won’t know which change broke what.

Don’t combine cleanup with new features. When a change does both and something breaks, it’s hard to tell which half caused it.

Don’t judge the result by how the code looks. Judge it by whether your checks still pass and whether the next change is easier.

How Forged handles this

Forged starts a cleanup with a diagnosis, and nothing is built until you approve a plan.

Dimension	The Forged approach
Finding the problems	A Product Health check reads your repository and reports what it finds, without changing any code
What it looks at	Security, correctness, architecture, maintainability, testing, and how safely an AI agent can work on the code
Turning a finding into work	Each finding can become a plan, which you review before anything is built
How big each fix is	Small action items, each with acceptance criteria it has to meet
Where each fix lands	A pull request in your own repository, approved by you before it reaches users
What is remembered	Notes about your codebase and the decisions confirmed in earlier changes

It diagnoses first. A Product Health check reads your repository and writes its findings into Forged. It changes nothing in the code. The findings cover six areas, from security to how easily an AI agent can change the code without duplicating what is already there. A separate section points out patterns that often appear when a product is built quickly.

Every fix is a plan you approve. Any finding can become an improvement plan. You see what will change and how Forged will know it worked, before any code is written. Forged calls these acceptance criteria. Each change then arrives as a pull request, a proposed change you approve before it goes live, with the evidence that its acceptance criteria were met.

Later changes respect the cleanup. Forged keeps short notes about your codebase and the decisions confirmed along the way. Later plans and builds read them, so new work follows the decisions the cleanup settled.

Your questions, answered

Can I just ask the AI to clean up my code?

Yes, in small pieces.

The same AI that wrote the code can clean it up, as long as each request is narrow and reviewed. Ask for a report first, then one fix at a time, and run your tests after each one.

Should I stop building new features while I clean up?

Not entirely, but keep the two apart.

Alternate between them rather than mixing them in one change. A simple rhythm is to make every third change a cleanup until the worst problems are gone.

Do I need a developer to clean up my codebase?

Not for most of it.

The report, the tests, and the small fixes can all be done with AI, as long as each change is reviewed. A developer is worth paying for when you want a second opinion on the order of work or on a large reorganization. Our guide to whether you need a developer now that your app has users covers that decision.

How do I know when the cleanup is done?

When the next change is easy to make.

A cleanup has worked when a new feature takes one attempt, your checks pass after every change, and fixing one thing no longer breaks another.

Find out what needs cleaning in your product

Connect your repository and start with a Product Health check.

It reports what needs attention without changing any code. You choose what gets fixed first, and each fix comes back as a pull request for your approval.