For most teams, a short optional note on AI use in the pull request template is worth it, as long as it changes how review happens and is never used to punish. If nothing would change because of the note, skip it and enforce the same standard for everyone.
Reasons to ask
A reviewer who knows a block was generated can slow down on the parts a model gets wrong: invented APIs, unneeded abstractions, tests that restate the code. It also helps later, when someone asks why a pattern appeared.
For regulated work, a record of how a change was produced may help with change management evidence. Check your own obligations rather than assuming them.
Reasons not to
Disclosure can become a ritual. Authors tick a box and reviewers ignore it. It can also create stigma, so people stop being honest. And it can imply that human written code is trusted by default, which is not true.
Google's review standard offers a useful balance: the change is judged by whether it improves code health, and the reviewer should read and understand every line either way. The tool does not change the bar.
Three options
- No disclosure. Same standard for everyone. Simple, but reviewers have less context.
- Optional note. A line in the template, such as which parts were generated and how you checked them. Low friction.
- Required statement for sensitive areas. Authentication, payments, crypto and infrastructure code get a mandatory note and a second reviewer.
A light template
Add three prompts to the pull request template:
- Did you use an AI tool on this change, and where?
- How did you verify the generated parts?
- Anything you are unsure about?
The second prompt matters most. It moves the conversation from the tool to the checking.
How reviewers should use it
Spend extra time on the flagged sections. Run the code. Break something and see if tests fail. Check any new dependency before accepting it. Do not lower or raise the bar for approval because of the note, since the standard of improving code health applies either way.
Handling honesty
If someone discloses and gets harsh feedback, others will stop. Thank people for disclosing and keep comments on the code.
Review the policy later
After a quarter, check whether the notes were useful. If reviewers cannot name a case where one helped, drop the requirement and keep the culture of verification.
A word on tone
Write the template as a question, not an accusation. "Where did you use AI, and how did you check it?" invites a useful answer. "Did you use AI?" invites a defensive one. The goal is better review, and the wording decides whether people cooperate.
Quick check
Does disclosure change the approval standard?
It should not. The change is approved when it improves code health, whoever or whatever wrote it.
What is the most useful question to add to the template?
How the author verified the generated parts.
Sources
Last reviewed: 19 October 2026.