What AI review is good at
A model reviewing a diff is fast, consistent and does not get tired on the fortieth file. It is good at spotting unhandled errors, missing tests for new branches, mismatches between a change and its stated purpose, risky patterns and obvious security mistakes.
It is also good at reading evidence. Given the validation output, the CI status and the project's own guidelines, a reviewer agent can check whether the change does what the task asked and whether the claims in the description hold.
What it misses
AI review has no stake in the product. It does not know that a team agreed last week to stop using a pattern unless that is written down where it can read it. It can miss design-level problems that only make sense with business context.
It also tends toward agreement. A model asked to review a plausible diff will often approve it. A verdict in free text is easy to misread, and a review that lists serious findings and then says the change looks good is worse than no review.
This is why AI review should narrow the human reviewer's attention, not replace the human. The useful output is a structured verdict with findings and evidence, on a specific commit.
Independence matters most when agents write the code
When an agent wrote the change, asking the same session to review it tells you little. It already believes its own reasoning. An independent review starts from a fresh checkout with no memory of how the change was made.
The reviewer should also be unable to alter what it reviews. Read-only tools mean it can inspect and search but cannot fix things quietly, so its verdict describes the change as submitted.
Independence has degrees. A separate job with separate context is a real improvement. A different model from a different provider is stronger still, since models from the same family can share blind spots.
- Fresh checkout at the commit under review
- Read-only tools
- Structured verdict that fails closed when it cannot be parsed
- Verdict tied to one commit and discarded when the commit changes
How review works in PWR
Every pull request a PWR task produces gets a separate review job. It clones the repository at the pull request head, has read, search and list tools only, and works from a rubric that includes the validation result, CI status and approved project knowledge.
The reviewer must end with a strict structured verdict. If the verdict cannot be parsed, it does not count as approval. If it approves while reporting blocking findings, the platform downgrades it. When the head commit changes, the review is invalidated.
The review is one input to a human decision. A person approves, requests changes or rejects, and that decision is bound to the commit. PWR also offers a Review mode in the repository workspace for reading code with an agent, and a Security Engineer role that reports findings with severity, evidence and remediation. One limit to know about: by default the reviewer uses the same agent definition as the implementer, so the same model family. Set a dedicated review agent in the project policy for stronger independence. PWR reviews the pull requests its own tasks create. Reviewing arbitrary pull requests opened by people is not a current feature.