Before your vibe-coded app meets real users, four things need to happen: scan it for exposed secrets, verify authentication actually restricts access, audit every dependency the AI chose, and produce a map of what was actually built. None of these require you to read code — but skipping them is how prototypes become breach headlines.
This is the cleanup guide for founders who built something with Cursor, Claude, Lovable, Bolt, or v0, watched it work, and now feel the correct instinct that "it works" and "it's safe to launch" might be different claims.
Why Does Working Code Still Need a Cleanup?
Because AI optimizes for making the thing you asked for run — not for the security properties you never thought to ask for. The data on this is no longer anecdotal:
- In March 2026 alone, 35 CVEs (catalogued security vulnerabilities) were directly attributed to AI-generated code — up from 6 in January.
- When Veracode tested whether AI models choose secure or insecure implementations of common tasks, they picked the insecure option 45% of the time.
- Across 2.23 million AI-generated code samples, 19.7% contained at least one hallucinated package name — references to software that doesn't exist, which attackers register with malware inside.
And the structural problem underneath: when something's found later, there's no author to ask why it was done that way. The AI made the decision and didn't document its reasoning. You shipped a codebase with no institutional memory on day one.
None of this means vibe coding was a mistake. You validated an idea for a fraction of what an agency would have charged. It means the prototype phase ends with a deliberate checkpoint — the same conclusion we reached in is your AI-generated code production-ready, but this post is the what to do about it.
The Cleanup Checklist: 7 Steps, in Priority Order
1. Hunt for exposed secrets — before anything else
AI assistants routinely hardcode API keys, database passwords, and tokens directly into code because it's the shortest path to "it works." If that code was pushed to GitHub — even a private repo, even briefly — treat those credentials as compromised. Automated bots scan public commits in seconds.
Do: run a secrets scan, rotate anything found, move secrets to environment variables. Full walkthrough: how to find exposed secrets in GitHub.
2. Test whether auth actually... authorizes
The most common serious flaw in AI-built apps is IDOR — insecure direct object reference. Plain English: the app checks that you're logged in, but not which data you're allowed to see. User #41 changes a URL from /invoices/41 to /invoices/42 and reads someone else's invoice. AI models correctly authenticate users but fail to verify permissions with remarkable consistency, because the prompt said "add login" and login is what it added.
Do: create two test accounts. With account A, grab URLs to your own data. Log in as B and try them. If B can see A's data, you've found your launch blocker. This test requires zero code.
3. Audit the dependencies the AI chose for you
Every package your AI assistant imported is a vendor you didn't vet — chosen for popularity in training data, not for current security. Some are outdated versions with known CVEs; some may be hallucinated names typosquatted by attackers; and this spring's npm/PyPI worm wave showed even legitimate, massively-downloaded packages get poisoned.
Do: generate a dependency inventory, flag known-vulnerable and unmaintained packages, pin versions.
4. Find the input holes
SQL injection and command injection — attacks where a user types code into a form field and your database executes it — remain in the AI-generated CVE record because models follow input patterns without applying sanitization logic. Anywhere a user can type is a potential entry point.
Do: this one's a scan-and-fix for a developer or an automated tool. It's hours of work when identified specifically, not a rewrite.
5. Check what the app exposes by default
Missing security headers, permissive CORS configurations (rules controlling which websites can call your backend), verbose error messages leaking internals, debug endpoints left enabled — the classic "ships straight to production when no one reviews the output" category. Individually small; collectively, they're reconnaissance gifts to attackers.
6. Get a map of what was actually built
You described features; the AI made architecture decisions — database schema, file structure, what talks to what. Nobody on earth currently has that map in their head. Before you hire your first developer or hand the code to an agency, produce one: it converts "weeks of archaeology" (and the quotes you'd get reflect that, as we covered in I inherited a codebase, now what) into "days of onboarding."
7. Decide: harden, partial rewrite, or document-and-defer
With findings in hand, you have a triage decision, not a panic. Reasonable rubric: harden if findings are the usual list above (secrets, IDOR, deps — all fixable in days); partially rewrite only the components handling money or sensitive data if those are structurally unsound; defer cosmetic debt with a written list. What you may not do is launch to real users with #1–#3 unchecked.
What Should Your AI-Assisted Workflow Look Like After Cleanup?
The cleanup checklist fixes the past. These habits stop the same debt from re-accumulating — because you're presumably going to keep building with AI, and the goal is keeping the speed without re-earning the same findings every quarter.
Prompt for the security property, not just the feature. "Add an invoices endpoint" gets you an endpoint. "Add an invoices endpoint where users can only access their own invoices, with input validation" gets you the version that passes audit. AI models deliver what's specified with reasonable fidelity — the 45% insecure-choice rate applies when security is left implicit. A reusable prompt preamble ("always parameterize queries, always check object ownership, never hardcode secrets") costs nothing and shifts the baseline.
Gate dependencies. Before accepting any AI-suggested package: does it exist (the 19.7% hallucination rate makes this non-rhetorical), is it maintained, and do you already have something that does the job? One minute per package versus inheriting an unvetted vendor.
Keep secrets out by default. Set up environment variables and a .gitignore before the next build session, and tell the AI explicitly to use them. Secrets that never enter the repo never need emergency rotation.
Re-scan on a rhythm. New code means new findings. A scan per release — or monthly, whichever comes first — keeps the findings list short enough to actually fix. The teams that drown are the ones that audit annually and meet 200 findings at once.
Write down what got built. After each significant AI-built feature, capture three sentences: what it does, what it touches, what was deliberately deferred. This is the institutional memory the AI doesn't provide, and it's the difference between a maintainable codebase and an inheritance problem you're creating for your own future team.
None of this slows you down meaningfully — it's minutes per session. What it buys is the thing vibe coding's critics say is impossible: AI-speed development with a codebase you can defend to an auditor, an acquirer, or your first senior engineer.
What Does This Cost — and What Does Skipping It Cost?
| Path | Cost | Time |
|---|---|---|
| Traditional consultant security audit | $10,000+ | 2–6 weeks |
| Freelance security review | $2,000–8,000 | 1–3 weeks |
| Automated scan (SystemAudit) + targeted fixes | Free scan; fixes priced by findings | Minutes + days |
| Skipping it | One leaked AWS key: $5K–50K+ in attacker-run compute; one breach: customer trust, disclosure duties, dead acquisitions | — |
The asymmetry is the argument. A single exposed credential found by the wrong person routinely costs more than every option in the table combined — and breach findings surface later in investor due diligence, where they reprice or kill deals.