Reject an AI fix and write the change by hand when the code is security critical, the root cause is unclear, the diff is a large rewrite, tests cannot demonstrate the fix, or the suggestion keeps failing review. Use the tool for drafts, not for decisions on high risk code.
The seven signals
- Security critical code. Authentication, authorization, input validation and cryptographic operations. OWASP's guidance on secure coding with AI recommends writing security critical tests manually for these areas, and the same caution applies to the code they protect.
- The root cause is not understood. If neither you nor the assistant can explain why the flaw exists, a plausible patch may be a guess.
- The diff is a rewrite. A fix that restructures many files costs more to review than it saves, and large changes hide small problems.
- No honest test is possible. If you cannot write a test that fails before and passes after, you cannot show the fix works. Do the harder thinking yourself.
- The suggestion touches things it should not. Pipeline files, build scripts, tests or tool configuration. Ask for a split, and if it persists, write it by hand.
- Facts do not check out. A version that does not exist, a package you cannot find, or an advisory that says something different. One wrong fact is a reason to distrust the rest.
- Two rounds of rework did not converge. Each round of corrections costs reviewer time. Set a limit.
A quick decision table
| Situation | Suggested path |
|---|---|
| Dependency patch bump, tests solid | Accept after normal checks |
| Small, well scoped code fix with a clear test | Accept after review |
| Fix to authentication or crypto code | Draft with a tool if you like, but a person writes and owns the final change |
| Fix needing design decisions | Human design first, tool for boilerplate after |
| Repeated failed rounds | Close the suggestion and write it by hand |
Treat this as a starting point to adjust with your own incident history.
Writing it by hand is not a defeat
Rejecting a suggestion is part of the process working. The aim is correct fixes, not a high acceptance rate. Do keep the useful parts: the explanation of the weakness, the reproduction, the list of places to check.
Time box the experiment
A simple rule: if a reviewer has spent twenty minutes without confidence, stop and hand it to the code owner. The number is only a prompt for you to set your own limit, not a researched figure.
Record the outcome
Add the rejection to your decision log with a reason. Over time, you will learn which categories of fix the tool handles well in your codebase and which it does not. See keeping a decision log for AI fix suggestions.
If you use Safeguard's fix pull requests, remember they are off by default, with every category on Manual, so you decide which categories ever get proposals. Closing a pull request you do not trust is a normal outcome.
Quick check
Does rejecting AI fixes defeat the point of using them?
No. The value is faster drafts for the changes where they are reliable. Rejections on the rest keep quality high.
Who decides to switch to a hand written fix?
The code owner, with security input for sensitive areas.
Sources
Last reviewed: 19 October 2026.
