Q&A: using AI tools in code review without losing judgment
Questions we kept getting about where AI assistants fit into review, and how we avoid outsourcing judgment.
Q&A
Are we supposed to use AI tools in code review now?
They’re available; they’re not mandatory.
We treat AI assistants as tools for:
- generating alternative explanations
- pointing out potential edge cases
- drafting comments or suggestions
They are not:
- the final word on correctness
- a replacement for understanding the change
What do we look for in AI-assisted review that we didn’t before?
We pay attention to:
- whether reviewers can still explain the change in their own words
- whether important decisions (interfaces, data flows, security behavior) are understood by humans
If a reviewer can only say "the assistant didn’t see a problem," that’s a smell.
How do we keep AI suggestions from overwhelming the review?
We scope their use:
- ask specific questions ("What are edge cases for this input?"), not "Is this code good?"
- limit suggestions to particular files or functions
- ignore style-only suggestions when they conflict with our existing conventions
Reviewers remain responsible for deciding which suggestions matter.
Can we rely on AI tools to catch security or performance bugs?
We can use them to surface ideas—but we don’t rely on them.
Security reviews and performance-sensitive changes:
- still follow our normal processes
- may use AI tools as an extra pair of eyes, not a gatekeeper
We document real issues they help us catch, but we don’t treat that as a guarantee for future changes.
How do we avoid leaking sensitive data when using these tools?
We:
- use tools that respect our data-handling requirements
- avoid pasting secrets, production-only data, or user-identifying information into prompts
- prefer integrations that keep analysis within our environment when possible
We treat prompts like logs: they may be stored or inspected, so we don’t put anything in them we wouldn’t put in a ticket.
What about training new reviewers—does AI help or hurt?
It can help by:
- offering explanations in different words when something is confusing
- suggesting test cases that a junior reviewer might not think of
It can hurt if:
- reviewers lean on it instead of building their own mental models
We coach new reviewers to:
- write their own summaries of changes first
- use tools to double-check or broaden, not to replace that summary
Takeaways
- AI assistants can make code review more effective, but only if humans stay in charge of judgment.
- Scoped, question-driven use works better than "ask it to review everything."
- Security and performance-sensitive work still requires our existing review practices.
- Prompts and outputs should be treated with the same care as any other stored artifact.