AI Cleanup After Vibe Coding: Technical Debt Founders Must Pay

The cheap part and the expensive part

Generating a working app with an AI agent can take an afternoon. Understanding it, securing it and changing it safely takes longer. The gap between those two timelines is technical debt, and it grows with every unreviewed commit.

Veracode’s 2025 study tested more than 100 models on 80 tasks and found AI introduced security flaws in 45% of cases, with no meaningful improvement from larger models. The evidence on speed is more mixed: in a 2025 randomised trial, experienced developers were 19% slower with AI tools while believing they were faster. Feeling productive and being productive are different.

Where the debt hides

A 30-day cleanup plan

Week 1: inventory.

• List the main flows: signup, login, payments, data export.
• Map the architecture on one page: services, database, third-party APIs.
• Run a dependency audit and a secrets scan, and list what you find.

Week 2: protect the critical paths.

• Write tests for the flows that handle money, identity and customer data first.
• Review authentication and authorisation by hand. Check that one customer cannot read another’s data.
• Rotate any exposed secrets and move them to environment configuration.

Week 3: set gates.

• Add continuous integration that runs tests, linting and type checks.
• Turn on dependency and static-analysis scans.
• Require review for changes touching security-sensitive code, including AI-written changes.

Week 4: reduce the mess.

• Delete dead code and duplicate logic that the tests now let you remove safely.
• Add structured logging and error tracking.
• Write a short architecture and runbook document so the next person can orient quickly.

Using AI in the cleanup

Models are useful here too, with supervision. Ask them to explain unfamiliar modules, draft tests for existing behaviour, summarise dependencies and propose refactors. Then verify. The pattern that works is “AI proposes, tests decide”. If you cannot say what a change should preserve, the model cannot either.

When to rewrite parts

Replace a component rather than patch it when:

• It cannot be tested without a rewrite.
• It handles sensitive data in ways you cannot make safe.
• Its performance or structure blocks product work.
• Nobody, including the model, can explain what it does.

Keep behaviour you can verify. Rewriting everything usually loses edge cases that users depend on.

Diligence and fundraising

Investors and enterprise buyers increasingly ask how code is reviewed and secured. A short, honest answer helps: tests on critical paths, CI, dependency scanning, review rules for AI-assisted changes and a named person responsible for security. That is the kind of foundation a fractional CTO can set up quickly.

Prevent the next pile of debt

• Write a short spec before prompting, as in spec-driven development.
• Keep generated changes small and reviewed.
• Track the share of code with tests on critical paths.
• Treat security checks as part of “done”.
• Decide who owns each part of the system.

The human side of this change, and why engineers still matter, is explored in Proton’s AI reckoning. For agent-specific risks, see AI agent security.

A pull request checklist for AI-written code

Put this in your repository’s pull request template so every change, human or AI, passes the same bar:

• Does the change have a test that fails without it and passes with it?
• Are all new dependencies named, justified and checked for known vulnerabilities and licences?
• Does it touch authentication, payments, personal data or file uploads? If yes, a second person reviews it.
• Are secrets read from the environment and absent from code, logs and error messages?
• Can the author explain in two sentences what the code does and what could go wrong?
• Is there logging for failures, with no sensitive data in it?
• Does it delete anything it replaces, rather than leaving the old version beside it?

Define “done” as green checks plus a reviewer who understood the change. A model’s confidence is not a review.

Your next step

Choose the one flow whose failure would cost you a customer or a contract, usually login or payments, and write three tests for it this week. Run a secrets scan on the repository at the same time. Two small, finished steps beat a large cleanup plan nobody starts.

Bottom line

Vibe coding gets you to a demo quickly and leaves you with debt you will pay later. Inventory first, test the critical paths, add gates, then reduce the mess. Rewrite only what cannot be made safe, and keep a human accountable for what ships.