The prompts we use to clean up AI-generated code
These are the exact prompts we run against a freshly vibe-coded app before we ever open an editor ourselves. Copy them as they are. They are organized by what they actually do: understand what exists, find what's dangerous, clean up what's messy, prove any of it works, and keep it that way going forward.
Why does prompting alone stop finding new problems?
An AI can't tell you what it doesn't know about your business, and past a certain point it starts confidently fixing symptoms instead of causes. That ceiling shows up faster than most people expect, usually right after the first round of obvious bugs is gone.
Here's the mechanism. An AI coding assistant reasons from what's written in the code and what's written in your prompt. It has no access to the conversation your co-founder had with a customer eight months ago that's the actual reason a discount can't stack with a referral code. It doesn't know that the "temporary" admin bypass in the login flow was supposed to be removed before launch. Those facts live in your head, not in the repository, so an AI reviewing the repository will walk right past them.
The more dangerous failure mode is the confident one. Ask an AI to "fix the slow checkout page" and it will find a real, fixable thing, usually a query or a render loop, and fix it well. It rarely stops to ask whether checkout is slow because of that query, or because there's no index, or because there's no ownership check forcing an extra table scan on every request. It optimizes the thing it can see and reports success, and the report is not wrong, it's just incomplete. That's the plateau: real fixes that don't touch the structural cause, delivered with total confidence.
The prompts below are built to work around that ceiling by forcing the AI to show its work, name what it actually read, and separate "I fixed this" from "I don't know." Read each one, then use it as-is or adapt it to your stack.
Understand what you have
You cannot safely change a codebase you haven't mapped. These four prompts build a working mental model before a single line changes.
Map the codebase
Read through this entire repository and produce a map of it. For each
top-level folder, tell me: what it's responsible for, the 3-5 most
important files inside it, and which other folders it depends on. Then
tell me, in one paragraph, what kind of application this is and what
it does for its end users. Do not guess at anything you haven't
actually opened and read.Names real folders and files it opened, states concrete dependencies between them ("routes/orders.ts imports lib/stripe.ts and models/order.ts"), and admits when it skipped a folder. A vague summary that never names a file means it didn't actually read the code.
Explain this file
Explain [filename] to me as if I've never seen it. Walk through what
it does top to bottom, in the order execution actually happens, not
the order the code is written in. For every function, tell me what
calls it and what it calls. Flag anything that looks unused, and flag
anything you don't fully understand instead of guessing.Follows the real call order, not the file's visual order. Explicitly separates "unused, safe to remove" from "unclear, needs a human." Never says a function "probably" does something without checking its callers.
Find where auth happens
Trace every place a user's identity is checked in this codebase,
starting from the incoming HTTP request. For each entry point, tell
me: how the user is identified (cookie, JWT, session, API key), where
that check happens in the code, and what happens if the check fails.
If you find any route or endpoint where you cannot locate an identity
check at all, list it separately under "no auth check found."A route-by-route table, not a paragraph. The "no auth check found" list is the most valuable output, an empty list here is worth double-checking rather than celebrating.
Produce an architecture summary
Write a one-page architecture summary of this application for a
technical reviewer who has never seen it. Cover: the stack (languages,
frameworks, database, hosting), how a request flows from the browser
to the database and back, where state lives, what third-party
services are called and why, and the single biggest structural risk
you can see in how it's built. Be specific, not generic.Names the actual risk in this codebase, not a generic "consider adding tests" line that would apply to any app. If the "biggest risk" section reads like it could be pasted into any other project's summary, push back and ask again.
Find the danger
Once you understand the shape of the app, hunt for the four things that show up in almost every breach post-mortem of an AI-built app: exposed secrets, missing authorization, untrusted input, and IDOR-style ownership gaps.
Find hardcoded secrets
Search this entire repository, including git history if accessible,
for anything that looks like a secret: API keys, database connection
strings, private keys, tokens, passwords. Include partial matches like
"sk_live", "postgres://", "service_role". For each one you find, tell
me the file, the line, and whether it's also present in the
built/compiled output. Do not tell me a codebase is clean unless
you've actually searched every file type, including .env files that
may be committed by mistake.File paths and line numbers, not "I didn't find anything obvious." It should explicitly confirm it checked .env, .env.local, and any committed build output, since those are where secrets hide most often.
List every endpoint and its authorization check
List every API route or server action in this codebase. For each one,
tell me: the HTTP method and path, what it does, and the exact
authorization check that runs before it executes, not just
authentication, authorization: is this user allowed to do this
specific thing to this specific record. Mark any endpoint where the
only check is "user is logged in" with no ownership or role check as
HIGH RISK.A full table, every route accounted for, with an explicit HIGH RISK column. If it silently skips routes it found confusing instead of flagging them, ask it to list what it skipped and why.
Find unvalidated inputs
Go through every place this application accepts input from a user or
an external system: form submissions, query params, JSON bodies,
webhooks, file uploads. For each one, tell me whether the input is
validated against a schema before it's used, or whether it's trusted
as-is. List every unvalidated input point, with the file and line,
ranked by how sensitive the data it touches is.Ranked, not just listed, so you know which unvalidated input to fix first. Webhook and payment-adjacent inputs should always land near the top.
Find where user data is read or written without an ownership check
Find every place in this codebase where data is read or written using
an ID that comes from the request, for example a URL param, a body
field, or a query string like /api/orders/:id. For each one, tell me
whether the code verifies that the currently logged-in user actually
owns or is allowed to access that specific ID, or whether it just
trusts the ID and fetches it. List anything that just trusts the ID as
an IDOR risk.Uses the term IDOR correctly and points to the exact query, for example a findUnique({ where: { id } }) with no userId in the same clause. This is one of the most common findings in AI-built apps, expect at least one hit.
Clean it up
Cleanup prompts are only safe when they refuse to change behavior at the same time as structure. These four keep refactors small, reviewable, and reversible.
Safe incremental refactor
I want to refactor [file/module] without changing any behavior.
Propose the refactor as a sequence of small, individually safe steps,
where each step could be committed on its own and the app would still
work identically. For each step, tell me exactly what to test manually
or automatically before moving to the next one. Do not combine a
refactor with a behavior change in the same step.A numbered list of small commits, each with its own verification step. If any step mixes "and also fix this bug while we're in here," split it out, that's a behavior change wearing a refactor's clothes.
Dedupe
Find every place in this codebase where the same logic appears more
than once with only minor variation, for example the same validation
rules, the same pricing calculation, or the same API call written
slightly differently in two files. For each duplicate, show me both
locations and propose a single shared implementation. Flag any case
where the duplicates have silently drifted, meaning they no longer do
exactly the same thing, since that's usually a bug, not just
untidiness.Explicitly separates true duplicates from drifted duplicates. A drifted pricing calculation, two versions that quietly disagree, is a live bug, treat it as one, not as cleanup.
Name things properly
Review the naming in [file/module]: variables, functions, and types.
Flag any name that doesn't tell me what the thing actually holds or
does, any name that's misleading (for example a variable called
"user" that actually holds a session token), and any inconsistent
naming for the same concept across files (userId vs user_id vs uid).
Propose better names, but don't rename anything that's part of a
public API, database column, or external contract without flagging it
as a breaking change first.Catches misleading names, the genuinely dangerous kind, not just stylistic ones. It should explicitly call out anything touching a public contract as a breaking change rather than silently including it in a "quick rename."
Extract the data layer
This codebase talks to the database directly from [routes/controllers/
components] in multiple places. Extract all direct database calls into
a single data-access layer, one function per real operation (e.g.
getOrderById, not a generic query builder call scattered everywhere).
Keep the exact same behavior and return shapes. Show me the plan
before you touch anything, including every call site that needs to be
updated.A full inventory of call sites before any code moves. This is also where ownership checks from prompt 08 get centralized instead of copy-pasted, one good place to enforce the rule beats fifteen places that might forget it.
Make it verifiable
A fix nobody tested is a claim, not a fact. These two prompts turn the money paths and any refactor target into something you can actually verify stayed correct.
Generate tests for the money paths
Identify the 3-5 flows in this app where a bug directly costs money or
trust: checkout, refunds, subscription billing, account deletion,
sending money or credits between users. For each one, write tests that
cover the happy path, the most likely failure mode, and at least one
adversarial case (what happens if a malicious or confused user sends
unexpected input). Use the existing test framework in this repo, don't
introduce a new one.Real, runnable tests using your existing framework, with at least one test per flow that tries to break it, a negative quantity, a duplicate webhook, an already-refunded order. Tests that only check the happy path haven't earned the word "coverage."
Write a characterization test before refactoring
Before I refactor [function/module], write tests that capture its
CURRENT behavior exactly as it is now, including any behavior that
looks like a bug, don't fix anything, just document what it actually
does today with passing tests. I'll use these to confirm the refactor
didn't change anything unintentionally. Tell me separately, outside
the tests, about anything you noticed that looks like a bug.Tests that pass against today's code, even the ugly parts, plus a separate, clearly labeled list of suspected bugs it did not silently fix. If it "fixes" something inside a characterization test, that's exactly the mistake this prompt exists to prevent.
Keep it clean
A one-time cleanup drifts back to messy within a month unless the AI has standing rules. These two prompts build the constraints file that every future session, yours or a teammate's, loads before it writes a line.
Write the rules file
Based on everything you've learned about this codebase, write a rules
file (AGENTS.md / CLAUDE.md style) that should be loaded into context
on every future AI coding session for this project. Include: the
actual folder structure and what belongs where, the naming
conventions in use, the authorization pattern that must be followed on
every new endpoint, which files must never contain secrets, the
testing requirement for money-path code, and any past mistake you
found in this codebase that a future AI session should specifically
avoid repeating.Specific to your app, not a generic checklist that could apply to any project. The best sign it worked: it cites a real mistake it actually found earlier in this session.
Constrain the blast radius
Add a rule to [AGENTS.md/CLAUDE.md] that any change touching
authentication, authorization, payments, or database schema must be
proposed as a plan first, listing every file it will touch, before any
code is written. No new npm/pip dependency may be added without saying
why an existing one can't do the job. No destructive database
operation (DROP, DELETE without a WHERE, TRUNCATE) may be run without
explicit human confirmation in the same message.A rule an AI agent will actually follow because it's specific and checkable, not a vague "be careful with the database." This single rule is the difference between a mistake and the kind of incident that deletes a production table.
If your app was largely AI-generated, pair this rules file with a full pass of the vibe-coding security checklist before you rely on it going forward.
The closing prompt: the 3am test
Run this last, after everything above, and expect it to be uncomfortable. Its entire job is to stop being encouraging.
The 3am production-readiness review
Act as a skeptical senior engineer doing a production-readiness review
of this codebase, the night before it goes live to real paying
customers. You are not trying to be encouraging. List every single
thing that would page someone at 3am: data loss risks, security holes,
silent failure modes, missing monitoring, single points of failure,
and anything that only works because nobody has tried to break it yet.
Rank them by how bad the 3am call would be. Don't soften this for my
feelings, I'd rather know now.A ranked, specific, occasionally blunt list that cites real files and real scenarios, not a reassuring summary. If the answer reads like a compliment, ask again and tell it explicitly to stop hedging.
This is also, honestly, where prompting alone hits its wall for good. The AI can list what would page someone; it can't tell you which of those risks your specific business can tolerate for another month and which one ends the company. That judgment call is exactly what a second, human set of senior eyes is for.
More on working with, not against, your AI-built codebase.
The rescue playbook.
Real prompts, security rules, and teardowns of broken AI-built apps, sent when we publish something worth your inbox. No fluff, no drip sequence.
One or two emails a month. Unsubscribe anytime.
Ran these prompts and didn't love the answers?
A senior engineer will read the actual code, not just prompt around it, and hand you a straight, prioritized list of what to fix first. Start with a plain conversation, no sales engineer, no junior.
Common questions about prompting your way to a clean codebase.
Can I just tell the AI to fix everything at once?
No. A single broad instruction like "fix all the bugs" produces shallow, unverifiable changes across too many files at once. Every prompt above is scoped to one job, mapping, finding, refactoring, or testing, so you can review and commit each result independently instead of reviewing one enormous diff you can't reason about.
Which AI coding tool should I use for these prompts?
Any coding agent with full read access to your repository works: Claude Code, Cursor, GitHub Copilot Workspace, Windsurf, or a chat interface where you paste in relevant files. The prompts are written to be tool-agnostic, they describe the job, not the tool.
How often should I run the danger-finding prompts?
Run them before every production release, and again any time a new contributor, freelancer, or AI session has touched authentication, payments, or database schema. They take minutes to run and catch the exact class of issue that shows up in breach post-mortems.
What if the AI says everything looks fine?
Treat that as a reason to be more suspicious, not less. Ask it to show you the specific files and lines it checked to reach that conclusion. An AI that can't point to what it actually read hasn't verified anything, it has guessed.
Do these prompts replace a professional security audit?
No. They catch a meaningful share of common issues and are genuinely worth running, but an AI reviewing its own or another AI's code shares the same blind spots a human reviewer would want a second opinion on. Pair this library with the vibe-coding security checklist, and get an independent audit before anything handles real user data or money.