AI-assisted code review adds artificial-intelligence analysis to a team’s existing review process. It can streamline tedious checks and flag potential problems, but it should support—not replace—the reviewer’s own examination of the change, its architecture, maintainability, readability, and project goals. section 13.2.3
A safer rollout
A team adds an AI-powered review tool to its pull-request process. Initially, reviewers inspect the tool’s findings and continue reviewing the code themselves; they do not block a pull request solely because the AI flags an issue. The team records whether suggestions are correct, incorrect, or missing, then revises its working agreement as confidence grows. section 13.2.3 section 13.4
Use confidence levels to make adoption a team decision:
- Low confidence: use AI for initial analysis, tolerate inaccurate suggestions, avoid blocking pull requests, and evaluate what it catches and misses. section 13.4
- Medium confidence: take suggestions more seriously while allowing human reviewers to override incorrect findings; continue observing false positives, false negatives, and missed cases. section 13.4
- At every level, define expected uses, acceptable accuracy thresholds, and how reviewers should address AI-generated feedback. section 13.4
Table 3.1 Code review functions
|
Function
|
What is it?
|
Things to consider
|
|---|---|---|
|
Version control/source code management system integration
|
The ability to integrate with or support the source code management system your team is using
|
Make sure the tool you choose supports your source code management system.
Popular systems include Git, SVN, Mercurial, Perforce, CVS, and TFS.
|
|
Project management platform integration
|
The ability to integrate with or support the project management system your team is using
|
Make sure the tool you choose supports your project management platform.
Using the same tools within an ecosystem can make integrating easier and less cumbersome than piecing together different systems and platforms.
Popular platforms include Jira and Azure Boards.
|
|
Continuous integration/continuous deployment tool integration
|
The ability to integrate with or support CI/CD pipeline tools
|
Ensure your tool supports integrating with your CI/CD tools (or at least the most common and popular ones if you have not created a CI/CD pipeline yet).
Without this integration, the ability to automate and include extra safeguards in your overall process is diminished.
|
|
Self-hosting
|
The ability to host your own instance of the software or tool in a location you control and administer
|
If you are required to self-host due to compliance, regulatory, or security policies, your tools must give you the option to self-host.
|
|
Web hosting
|
The ability to have an external party host an instance of the software or tool in a location you do not control or administer
|
Backup and redundancy are great things to consider for web-hosted tools/systems.
Highly distributed teams may benefit from a web-hosted version of their review tools.
|
|
Change history
|
The ability to search through your changes and/or view a timeline-style overview of your code changes.
|
A robust search, like being able to search by date, commit, comment, or reference, can be an indispensable function your team may need.
Visual representations of changes can be helpful, especially if you use Git as your version control system.
|
|
Code-diff
|
A side-by-side comparison of changed code with original code; see added, deleted, and edited code.
|
A visual representation of code diffs can help reviewers see exactly what changed.
Bonus: If you can compare code across custom parameters, say your current commit versus a change made two months ago, that can also be a helpful tool to have during troubleshooting or debugging.
|
|
Pull requests
|
The mechanism to propose the integration of a set of code changes into a branch
|
Ideally (and since we’ve been talking about these the whole book), your tool has some form of proposing changes and a way to handle their integration to or rejection from the main codebase.
It may be called something other than a PR, but if you are able to facilitate a reviewing mechanism through this function (as discussed in this book), it’s worthwhile to consider.
|
|
Inline comments
|
The ability to highlight specific lines of code and leave a note
|
The ability to highlight code as specifically as you need to is a bonus.
Highlighting by line should be a bare minimum capability.
|
|
Conflict resolution
|
The ability to assist in resolving simple code conflicts between proposed changes and your main codebase
|
Some tools can do some simple conflict resolutions automatically. This includes visually viewing changes that conflict and manually sorting through them using a graphical interface.
It is worth considering as an additional safeguard if your team uses Git or if you expect code clashes with your team.
|
Evaluate the surrounding review tool as well as its AI capability: integration with source control, project management, and CI/CD systems can determine whether automation fits the team’s workflow. section 3.2.1
