You know the pull request. 40 files changed, clean naming, tidy comments, green checks. It looks like a senior engineer wrote it on a good day.
Then three weeks later someone asks why there are four nearly identical functions, and nobody can say which one is the real one.
AI-assisted pull requests are polished. That is the problem. Polish makes a reviewer relax, and review is where this kind of debt gets in. Two 2026 studies of agent-authored pull requests point at the same thing: one finds that plausible-looking AI code hides redundancy and less reuse, and another finds that quiet agent contributions can raise complexity and still get merged.
So here are five things everyone must check before merging an AI-written pull request. None of them need special tooling to start.
1. Did the complexity of the touched functions go up?
Open the functions the diff touched, not the whole file. Count the branches: every if, loop, &&, ||, ternary and case adds a path.
A function that was 4 paths and is now 14 is a review item, even if every line is readable. Readable and simple are different things.
2. Are the changed lines covered, or just the file?
A file at 90% coverage can ship a new function with zero tests. Overall percentages hide this because the old, well-tested code props the number up.
Ask a narrower question: of the lines this pull request added or changed, how many does a test actually run? That number is often much lower than the headline.
3. Did it add duplication?
AI tools love to write a new helper instead of finding the one you already have. Search the repo for two or three distinctive lines from the new code. If the same logic already lives somewhere else, you just got two bugs to fix instead of one.
4. Did it add or bump dependencies?
git diff main -- package.json package-lock.json
npm outdated
Check every new package: is it maintained, is it popular for a reason, and do you really need it for ten lines of code? Assistants add packages the way people add browser tabs.
5. Are any of those dependencies known to be vulnerable?
npm audit
Run it on the branch and on main, then compare. What matters is what this pull request introduced, not what you already had. A new advisory arriving with the diff is a reason to stop and look.
Why the changed lines matter
Notice the pattern. All five checks are about the diff, not the repository. A repo-wide score tells you how the project is doing. It will not tell you whether this pull request made it worse.
Reviewers are not lazy. A 40 file diff is just hard to hold in your head, and the polish of AI-written code does half the persuading for you. A short checklist beats trusting your gut on file 31.
Doing it without the manual work
Disclosure: I work on DebtDraft, a GitHub Action that runs these five checks (complexity, coverage, duplication, outdated dependencies and known-vulnerable dependencies) and posts a comment on the pull request which updates in place. It shows the health of the whole codebase and, separately, of just the changed lines. Free for up to three repositories. Find it on the GitHub Marketplace or at debtdraft.dev.
Either way, the checklist above works without it.
Your turn
What do you check first when a pull request is clearly AI-written? Is there a signal you trust more than any of these five?
Top comments (2)
A healthy repo can still get worse with the next PR. Green tests and good overall coverage don’t tell you everything about the change itself. That’s why PRI looks at reliability signals at the PR level, including fragility and code volatility, rather than relying on a repo wide score alone.
Agreed! Volatility is a signal I left out. Files that change often tend to hide the next bug. Thanks for adding it!