AI can be useful in code reviews, but it is easy to end up at either extreme: dismissing it entirely or accepting its findings without checking them. I think there is a practical middle ground.
The developer is still responsible for reviewing the code and deciding whether to approve the change. The AI can support that work by giving the review a structure, gathering relevant context and examining the change from different perspectives.
I want it alongside me during the review, surfacing findings that I can investigate. Before a finding becomes a PR comment, I check the code, assess the impact and decide whether the feedback is useful enough to post. In this post I will go through how my code-review skill supports that approach.
What I want from an AI review
There is quite a bit to keep in mind when reviewing someone else's change. What was requested? Can the user complete the flow? What happens if one of the calls fails? Do the tests actually check the behavior we care about?
I want the skill to help cover those perspectives and give me concrete things to investigate. A comment such as “consider improving error handling” does not give me much to work with. A finding that explains which failure leaves the user stuck, and points to the code responsible, is much more useful.
The motivation is a structured review that helps me examine the change thoroughly, including its behavior, failure scenarios, security and test coverage. Several AI reviewers can share the same blind spot, so their agreement alone does not establish that something is wrong or correct.
Start with the pull request
With repository access configured, this example uses my raholsn skill through its Claude Code command:
/raholsn:code-review example/export-service#42 post_comments=noneThe repository and PR number are examples. post_comments=none keeps the findings in the review output, so I can read them before deciding what to do with them.
The skill reads the PR description, changes and existing comments. When it finds a linked ticket and has access to the tracker, it also reads the requirements and acceptance criteria. Those requirements are shared with every selected reviewer.
This matters because the code tells us what was implemented. It does not necessarily tell us what should have been implemented. If the ticket cannot be read, the review should say that instead of claiming the acceptance criteria have been checked.
Different reviewers, different questions
The main command coordinates separate agents with focused responsibilities. Functional review always runs. Architecture and QA join when the change makes them relevant, or when explicitly requested. Configured domain or compliance reviewers run when their scope applies.
| Reviewer | Main question |
|---|---|
| Functional | Does the change deliver the requested behavior through the affected user journey? |
| Architecture | Does the design hold up under the relevant failure, concurrency and load scenarios? |
| QA | What evidence shows that the behavior works, including the important edge cases? |
| Domain or compliance | Does the change follow the supplied rules that apply to this area? |
For a small documentation change, bringing in every specialist would add little value. A change to retries, data handling or service boundaries deserves a broader look.
The company-specific rules come from configuration and reference documents. The command should not invent a policy because the repository happens to contain something that looks like payment code.
The workflow
The review goes through these steps:
- Gather the context. Read the PR, available requirements and repository guidance. Record the exact revision being reviewed.
- Choose the reviewers. Select the perspectives relevant to the change and explain any skips.
- Review in parallel. Give each selected agent the same revision and requirements, then let it write its findings independently.
- Combine the results. Check conflicting claims against the source, remove duplicates and prioritize by demonstrated impact.
- Present the assessment. Show concerns, supporting evidence, open questions and limitations. Post comments only according to the selected preference or a subsequent user choice.
The source revision is an easy detail to overlook. My local checkout might be on another branch, or someone might push a new commit while the review is running. The reviewers need the source that belongs to the captured PR revision. Before posting comments, the command checks whether that comparison has changed and refreshes affected findings if necessary.
Workflow diagram
Open the overview at full size
Explore the detailed workflow
The sequence below comes from the skill guide and includes its supported branches. For the developer-led approach in this post, use the local review and individually selected comments path.
One change, three perspectives
Let's say a PR adds retries to a background CSV export. This is an illustrative example, not a finding from an actual review.
The ticket says the user should receive one download link when the export is ready. A storage request times out, and the worker tries again.
The architecture reviewer follows what happens around the timeout. Could the first upload have succeeded even though the response was lost? Does the retry create another export? Is there an existing key or state check that prevents duplicate work?
The functional reviewer follows the outcome for the user. Does the export remain stuck in “processing”? Could the user receive two notifications? Does the download still contain the rows they requested?
The QA reviewer checks the evidence. Is there a test where the upload succeeds but the response is lost, followed by a retry? Does it assert the final state and number of notifications, or only that no exception was thrown?
These questions overlap, which is useful. The consolidation step should turn the overlap into a clear finding rather than three comments about the same issue. If the code already handles the scenario, the concern should be dropped. If the expected behavior is unclear, that remains a product question.
Keeping the findings useful
A finding should identify the affected code, explain the scenario and describe its impact. The command groups results into critical issues, warnings, suggestions and areas checked without concerns.
Missing tests alone should not turn into a critical defect. There needs to be a distinction between a demonstrated problem, a meaningful validation gap and an optional improvement.
It also matters what the review could not establish. Reading a test is different from running it. A reviewer that only had access to the diff may be missing behavior elsewhere in the repository. Those limits belong in the assessment.
Posting comments
For this approach, I keep the initial review local with post_comments=none. I work through the findings, check the supporting code and decide which comments I want to put my name behind. A severity label from the AI does not make that decision for me.
When I want the AI to post feedback, I explicitly identify the findings I have reviewed and approve their wording. With no posting preference supplied, the skill also offers an individually selected findings option after presenting its assessment. It supports broader posting options, but the approach described here keeps a developer decision before each comment is posted.
The review itself does not apply fixes or merge the PR. It gives me an assessment and, when requested, puts the relevant feedback where the author can act on it.
The skill
You can find the code-review skill on GitHub.
The full instructions will live there, including how the command passes context to the reviewers and combines their output. This article describes the workflow as of its updated date.
I think the useful part of this approach is combining a structured review with developer judgment. The AI helps me explore the change and raises questions worth checking. I remain responsible for the feedback I post and the decision to approve the PR.
Happy coding!
