How to stop your AI from finding new errors on every review

You ask the model to review the repo. It finds six issues. You fix them. You ask again. Six more.

That is not a haunted codebase. You told it to look, and looking has no end. Kenton Varda wrote that their reviewer can always find 3 to 6 new problems. I have done that loop. It feels like the code is broken. The review job is broken.

The fix is not a shorter prompt. Short prompts are how you get infinite nits. The fix is a protocol: investigate, challenge the scheme, then look at the code, then stop.

I am using a prompt a Chinese engineer posted for exactly this. It is long on purpose.

How you run it

1. Open a new chat. Not the one that just wrote the code.
2. Point it at the repo, or paste the diff plus the files around it.
3. Paste the prompt in the code block below. Do not add "and also tidy the names."
4. Let it finish. Read the route conclusion. You decide. It does not patch until you say so.

If you skip the new chat, the rest is theatre. The writer chat will defend the file it just wrote.

Why the order is the whole tutorial

I. Investigate

README, AGENTS.md, CLAUDE.md, spec, issues, current git diff, entrypoints, data model, auth, tests. Bound the scope. Do not wander the whole tree. Do not ask you questions it could have answered by reading.

II. Restate the job

What problem this change is for, what scheme is in use, which files that came from, which assumptions it is standing on, what is still unknown. If the docs and the code disagree, it has to say which one it trusted.

III. Review the scheme first

No local style comments yet. Is this the right path. Did a simple problem get a complicated house. Would a different scheme delete this class of bugs. Compare only if there is a real alternative.

Then one of four conclusions:

• keep
• adjust
• replace
• not enough information

No code patches before that sentence. That is the part most "review this" prompts skip. They assume your architecture is correct and start circling timeouts.

IV. Then implementation

Only if the scheme is still worth keeping. Real bugs: logic, auth, leaks, validation, concurrency, tests, drift from the spec. Each finding gets severity, confidence, file evidence, trigger, impact, what to do, root cause or symptom. Same root cause is one item, not five.

V. Quality bar

Do not invent issues to look busy. If there is nothing important left, say so. Style is not a defect. No evidence, not a bug. Diminishing returns: recommend stop.

VI. Output, then wait

Fixed report shape, including "is another round worth it." Then it stops. You decide.

The prompt

Copy the whole block. Paste it into a new chat on the repo.

Act as an independent software architect, security reviewer, and code reviewer. Do a full review of the current repository.

Your job:
1. Judge whether the current technical scheme is reasonable.
2. Decide whether a simpler, safer, or easier-to-maintain scheme exists.
3. Only if the scheme is reasonable, review the actual code.
4. Report problems that are actually worth fixing. Do not invent problems to fill a review.

Do not assume the existing architecture, tech choices, or implementation are correct. Do not start editing code.

## I. Investigate the repository first

Read the repo yourself. Reconstruct the project goals, constraints, and current scheme from what is already there.

Prioritize:
- README, AGENTS.md, CLAUDE.md, and other project docs
- docs, spec, requirements, issues, tickets
- git diff of the current branch and recent related commits
- dependencies, build, env, deploy config
- program entry, main modules, call relationships
- data model, authz, external service interfaces
- existing tests and the scenarios they cover
- code and docs directly tied to the current change

Bound the relevant scope. Do not scan the whole repository with no aim.

Do not ask for information that is already in the repo, the code, config, tests, or git history.

Only ask a question if all of these are true:
- the answer is really not in the repo
- a different answer would clearly change your review conclusions
- you cannot keep judging with reasonable read-only checks

At most 3 key questions at a time. Ordinary uncertainty can be flagged. Do not halt the whole review for it.

## II. Reconstruct goals and current state

From the investigation, state briefly:
- what problem this project or change is trying to solve
- what scheme is in use now
- which files or code that judgment came from
- which key assumptions the current scheme depends on
- what is still uncertain

If docs and code disagree, say so clearly and say which one you used as the base.

## III. Review the scheme first

Do not get stuck on how local code is written. Go back to the project goals and check whether the current path is the right one.

Judge:
- whether the current scheme actually meets the need
- whether a simple problem got overcomplicated
- whether early choices created a pile of later patches
- whether permission, security, or state bugs come from the architecture itself
- whether the current problems can be fixed with local edits
- whether another scheme would delete this class of problems at the root
- whether a replacement is worth the migration cost

Do not get trapped by how much code already exists. A lot of code does not mean the scheme should continue.

If there is a real alternative, compare:
- need coverage
- security risk
- implementation complexity
- maintenance cost
- performance and resource cost
- blast radius when it fails
- migration and rollback difficulty

Do not invent forced alternatives to fill the format. If the current scheme is already reasonable, say why it is worth keeping.

End with exactly one of:
- keep the current scheme
- adjust the current scheme
- change the scheme
- missing key information, cannot judge yet

Do not provide code patches before you have a route conclusion.

## IV. Then review the implementation

Only if the current scheme is still worth keeping. Then look at:
- functional and logic bugs
- permission, identity, and data-leak risk
- input validation and error handling
- concurrency, state consistency, resource cleanup
- performance
- test gaps
- implementation that drifted from the need or the design
- structure that will raise future maintenance cost

Each issue must include:
- severity: Fatal / High / Medium / Low
- confidence: High / Medium / Low
- matching evidence from files, code, or config
- the specific scenario that triggers it
- possible consequences
- suggested direction
- whether it is a root cause or a surface symptom

If several issues share a root cause, merge them and prioritize the root-cause fix.

## V. Review quality bar

- Do not raise issues just to hit a count.
- If you did not find new important problems, say so.
- Separate confirmed defects, reasonable risks, and unchecked assumptions.
- With no code or doc evidence, do not present a theoretical possibility as an existing bug.
- Do not treat personal style preference as a defect.
- Do not repeat issues already fixed.
- Do not only inspect the local patch. Check the caller, the data flow, and the affected scope.
- For low-probability, low-impact items, say whether they are worth handling.
- Do not modify code unless I explicitly ask after this.
- If continuing the review is diminishing returns, say clearly that we should stop.

## VI. Output format

In this order:
1. Repository investigation scope
2. Project goals and current scheme
3. Key information still unconfirmed
4. Key assumptions of the current scheme
5. Scheme-level problems
6. Alternatives and tradeoffs
7. Route conclusion
8. Implementation-level problems
9. The three priority things to handle
10. Remaining risks that are acceptable for now
11. Whether another review round is worth it

Finish the review and wait for my decision. Do not modify code directly.

After it answers

Read item 7 first: keep / adjust / replace / cannot judge. If it wants to replace the scheme, that is the actual review. The timeout comments can wait.

Then item 11. If it says another round is not worth it, do not send "ok one more pass." That reopens the infinite job.

I still get real findings. I stopped getting a new religion every time I said "review."

If you use this, did it actually challenge a design, or did it still hide in the types?