How to Fix AI-Generated Code: A Step-by-Step Approach

To fix AI-generated code, work in this order: put it under version control, check security first, reproduce one problem at a time, lock each fix with a test, and stop the AI from regenerating files you’ve fixed. Most AI-built apps don’t need a rewrite; they need disciplined, small changes. Here’s the process that works, whether you do it yourself or hire someone.

Step 1: Get the code under control

1. Export or sync to Git. Lovable, Bolt and Replit can connect to GitHub; Cursor and Claude Code work in a local folder you can git init.
2. Commit the current state before changing anything:

git init
git add -A
git commit -m "Baseline before cleanup"

3. Check it builds outside the tool:

npm ci
npm run build

If it only builds inside the AI tool, that’s the first issue to fix.

Step 2: Security first

These issues don’t show up as bugs, so they’re easy to miss.

Database access rules

If you use Supabase, check that Row Level Security (RLS) is enabled on every table in the public schema. Run this in the SQL editor:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Any false means that table may be readable or writable with your public key. Then review the policies themselves: “enabled” with a policy of using (true) is still open. Supabase’s RLS guide explains how policies work. This isn’t theoretical: in May 2025, CVE-2025-48757 documented that 170 of 1,645 apps in Lovable’s showcase exposed tables via the anon key.

Secrets in the frontend

Anything shipped to the browser is public. Search your code for keys:

grep -rnE "sk_live|sk_test|service_role|OPENAI_API_KEY|-----BEGIN" src/

A secret scanner such as gitleaks also checks Git history. If a secret was ever committed or shipped to the browser, rotate it in the provider’s dashboard, then move it to a server-side environment variable.

Dependencies

npm audit

Review high and critical findings; don’t blindly run npm audit fix --force, which can introduce breaking upgrades.

Step 3: Fix bugs one at a time

1. Reproduce the bug and write down exact steps.
2. Write a test that fails because of the bug (or at least a manual checklist).
3. Make the smallest fix that makes it pass.
4. Commit with a clear message.
5. Repeat.

When you use an AI tool for a fix, give it the failing test and the specific file, and ask for a minimal change. Review the diff before accepting it.

Example: one bug, start to finish

Say customers report that after logging out and logging in as someone else on the same device, they briefly see the previous user’s orders.

1. Reproduce: log in as user A, open Orders, log out, log in as user B. The list flashes A’s orders before refreshing.
2. Locate: search the code for where orders are loaded. You find the list is kept in a global store or cache that is never cleared on logout.
3. Check the server side too: confirm that the database itself only returns B’s orders to B (with RLS or server checks). If it doesn’t, that’s a security bug, not a display bug, and it goes first.
4. Write the check: a test, or a written manual step, that logs in as A, then B, and asserts no order from A appears.
5. Fix minimally: clear the store on logout and on user change. Don’t let the AI “refactor the state management” while it’s at it.
6. Commit with a message that describes the bug, so the history explains why that line exists.

The same pattern applies to almost every bug in an AI-built app: reproduce, find the real source, confirm the server-side rule, lock it with a check, fix small.

Writing a fix prompt that works

AI tools fix better when the request is narrow and verifiable. Include the exact error or wrong behavior, the file and function involved, what must not change, and how you’ll check the result. Ask the tool to explain the cause before it edits. If its explanation doesn’t match what you observed, don’t accept the change.

Step 4: Common AI-generated code issues to look for

Issue	Symptom	Fix
Duplicated logic	A bug fixed in one place persists elsewhere	Consolidate into one function
Swallowed errors	Things fail silently	Handle errors and show/log them
Client-side “security”	Admin checks only in the UI	Enforce on the server or in database rules
Hard-coded config	Works locally, breaks in production	Environment variables per environment
Unbounded queries	Slow pages as data grows	Pagination and indexes
Ghost code	Unused files and components	Delete them; less for the AI to misread

Step 5: Stop the AI from undoing fixes

• Tests in CI, so a broken change fails before it deploys.
• Small prompts scoped to one file or function.
• Never regenerate whole files you’ve fixed by hand.
• Code review of every AI change, even quick ones.

When a rewrite is actually justified

Rewrites are tempting and usually wrong. They’re worth considering only if the data model can’t represent your business (and migrating it would touch everything), if the platform the AI chose can’t meet a hard requirement such as compliance or offline use, or if there’s so little working functionality that keeping it saves nothing. Even then, keep the old app running until the new one matches it.

Vibe coding cleanup specialist: when to hand it off

Doing this yourself is reasonable for a side project. Hand it to a specialist when:

• The app takes payments or stores personal data.
• The same bugs keep returning.
• You can’t tell whether a security fix actually worked.
• Investors or a buyer will review the code.

See vibe coding cleanup specialist and AI code auditor.

When to get help

Black Engine Technologies is a software engineering studio in Monterrey, Mexico (UTC-6) with 12+ years shipping production software, including licensed fintech payment systems. We work daily with AI coding agents, and we fix AI-generated code inside your own repository and accounts. Send us a WhatsApp message to have your app reviewed, or start with my AI app is not working.