Yes, inside the team. Record when a change was substantially AI-assisted so reviewers know to apply extra checks, and so you can find affected code if a tool turns out to have a flaw. Keep accountability with the human author either way, since the person who merges owns the change.
Why label at all
Labels help three things.
- Review focus. A reviewer who knows code was generated can look harder at dependencies, authorization and test quality.
- Incident search. If a tool or model version is later found to produce a certain flawed pattern, a label lets you search for exposure.
- Honest metrics. You cannot judge whether assistants help or hurt without knowing where they were used.
What to record
A short, consistent note is enough.
- Which tool or agent was used.
- The extent: small suggestions, a generated function, or a whole change.
- What the author checked, such as "read all lines, added tests for wrong user case".
- New dependencies and why each is needed.
A line in the pull request template works better than a policy document people forget.
What a label should not do
It should not shift blame to the tool. The author must understand the code well enough to explain it in review. A rule that says "I can explain every line I merge" is simple and sets the standard.
It should also not become a stigma. If labeling invites suspicion rather than care, people stop doing it.
Commit trailers
Some teams add a trailer to commit messages naming the assistant. This keeps the information with the history, where git log can search it. Pick one format and apply it consistently.
External considerations
Customers, auditors and open source projects may have their own rules about AI use in code. Check contract terms and project contribution guidelines instead of assuming. This post does not cover legal questions about ownership or licensing of generated code, which should go to counsel.
Tie it to controls
Pair the label with automated checks: dependency review, secret scanning and required human approval. Safeguard's policies and gates can enforce those checks on each pull request.
Rolling it out
Start with the pull request template and one reminder in the team channel. Review the labels after a month to see whether they are being used and whether they correlate with more review comments. Adjust the threshold if people find it tedious. A light rule that is followed beats a detailed rule that is ignored.
Quick check
Do tiny autocomplete suggestions need a label?
Usually not. Set a threshold your team agrees on, such as any generated block of more than a few lines or any new dependency.
Last reviewed: 19 October 2026.
