How to Stop AI-Generated Technical Debt Before Merge

“We will clean it up later” was already unreliable when humans produced code at human speed. With coding agents, the backlog can grow faster than the team can even classify it. The right time to remove unnecessary complexity is while the pull request is open and the task context is still available.

This does not mean demanding perfect code or blocking every imperfect legacy interaction. It means stopping new, avoidable debt from becoming shared infrastructure.

Debt prevention is a change-control problem: define the allowed delta, prove it, and refuse to transfer unexplained cost into main.

What the current evidence says

The 2026 preprint Debt Behind the AI Boom analyzes 302,600 verified AI-authored commits across 6,299 GitHub repositories. The authors report 484,366 attributed issues, with code smells representing 89.3% of them. More than 15% of commits from every assistant in the dataset introduced at least one issue, and 22.7% of tracked AI-introduced issues remained in the latest analyzed revision.

These figures depend on the study's attribution, static-analysis rules, repository sample, and observation window. They are not a universal defect rate. Their value is showing persistence: some issues introduced by AI-assisted changes do not disappear in routine maintenance.

The TRIM study adds a mechanism. Agents accumulate speculative and abandoned edits while searching for a working solution, leaving functionally unnecessary residue in the final patch. Together the research supports prevention at merge, not a vague promise of future cleanup.

Classify the debt before you automate it

Behavioral debt: missing failure handling, concurrency assumptions, partial implementations, or tests that do not prove the contract.

Structural debt: duplicated logic, wrong boundaries, one-call abstractions, excessive coupling, and large units with mixed responsibility.

Comprehension debt: code the team owns but cannot explain, operate, or safely change.

Security debt: unverified dependencies, broad permissions, unsafe input handling, secret exposure, or controls deferred behind TODOs.

Operational debt: missing observability, timeouts, rollback, migration safety, capacity limits, or incident ownership.

Different debt needs different evidence. A complexity limit cannot prove authorization, and an end-to-end test cannot prove the dependency came from a trustworthy source.

The pre-merge debt firewall

1. Baseline before generation. Record current tests, quality findings, dependencies, and the files expected to change. This distinguishes new debt from inherited debt.
2. Define the smallest contract. State observable success, important failure, and protected behavior. Reject speculative options and future-proofing without a real second use case.
3. Run checks during the agent loop. Format, compile, type, test, scan secrets and dependencies, and inspect generated-code patterns while repair is cheap.
4. Review boundaries. Confirm input parsing, data ownership, authorization, errors, network behavior, and persistence follow established architecture.
5. Minimize the final patch. Remove abandoned helpers, duplicate checks, narrative comments, dead branches, unrelated cleanup, and configuration the contract does not need.
6. Prove operational ownership. A human explains failure behavior, dependencies, monitoring, rollback, and the risk being accepted.

Ratchet; do not demand a fictional clean slate

A mature repository may already contain thousands of warnings. Turning every rule into a blocker on day one freezes delivery and teaches teams to suppress the tool.

Establish a baseline, then prevent regression. Block new critical findings in changed code. Require the quality score not to fall. Tighten thresholds after the highest-volume false positives are calibrated. Give every exception a reason, owner, and expiry. This turns quality into a ratchet: existing debt can be reduced over time, but new work cannot quietly make it worse.

Do not reward green-by-deletion

Reject repairs that achieve a pass by:

• Deleting, skipping, or weakening the test that found the problem.
• Broadening a type to unknown or any-shaped data.
• Swallowing an error and returning a plausible empty result.
• Disabling a linter, scanner, permission, signature, or coverage threshold.
• Adding a large generated snapshot without reviewing the semantic change.
• Marking a warning ignored without a documented risk decision.

The completion criterion is not a green terminal. It is a green terminal produced by a valid implementation and a still-intact control system.

Make recurring review comments executable

If reviewers repeatedly flag the same objective pattern, encode it in a test or deterministic rule. aislop covers generated-code residue such as swallowed exceptions, unsafe type assertions, trivial and narrative comments, debug leftovers, dead code, unresolved stubs, generic naming, dependency findings, and complexity thresholds.

Replace the example base with the pull request's target branch. aislop cannot identify every form of technical debt or decide whether an abstraction fits your architecture. Its value is making the repeatable part immediate, reproducible, and inexpensive enough to run on every change.

The merge question

Do not ask only whether the feature works. Ask whether the repository is now harder to understand, change, secure, or operate—and whether that cost is necessary for the value delivered. If the answer is unknown, the pull request is not ready. If the cost is deliberate, record who owns it and when it will be repaid.

Sources

• Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild
• TRIM: Reducing AI-Generated CodeSlop via Agent Trajectory Minimization
• GitHub: Review AI-generated code