PR Review Agents vs Coding Agents: What Each One Should Do
Coding agents are built to change a repository. PR review agents are built to decide whether a change should be trusted. Mixing those jobs is how teams get noisy automation.
A coding agent changes code. A PR review agent judges code that changed. The distinction sounds small until the same model is asked to write a patch, defend the patch, review the patch, and decide whether it should merge. Good engineering workflows separate those roles.
The jobs are different
Teams get better results when writing, reviewing, and fixing are treated as separate jobs with separate success criteria.
| Capability | Coding agent | PR review agent |
|---|---|---|
| Primary goal | Produce a requested change. | Decide whether a proposed change is safe enough to merge. |
| Input | Prompt, repository checkout, issue context, tests. | PR diff, surrounding files, policy, historical context, review thread. |
| Output | Commits, patches, implementation notes. | Findings, evidence, severity, verdict, suggested fixes. |
| Failure mode | Plausible but incomplete implementation. | Noisy comments, missed blast radius, weak evidence. |
| Trust boundary | Needs review before merge. | Needs evidence before it can block merge. |
Why one model is not enough
A single model can inspect a diff, but code review is not one skill. Security, test coverage, performance, API compatibility, data access, concurrency, and architecture all have different failure patterns. A useful review system has to route attention, not just produce prose.
This is why Critique uses a layered review shape: first map the change, then inspect specialist risk lanes, then synthesize a final human-readable verdict. The goal is not more comments. The goal is a smaller number of better claims, each with enough evidence for a maintainer to check quickly.
The right workflow
The stronger loop is especially important when AI generated the first draft. The fact that the code compiles does not prove that it respects the product contract, follows the surrounding architecture, preserves auth boundaries, or updates the tests that actually matter.
When to use each agent
- 1Do you need new code written?Use a coding agent. Give it a bounded issue, the relevant repository context, and a concrete verification command.
- 2Do you need a merge decision?Use a PR review agent. Give it the diff, policy, related files, and authority to produce an evidence-backed check result.
- 3Do you have a known narrow defect?Use a fix agent only after the finding is clear. Bounded repair works best when the problem is already localized and testable.
- 4Do you need to understand a codebase?Use repo chat or search first. Explanation work should not automatically become review work or patch work.
FAQ
Use the right agent for the right job
Run Critique where merge decisions already happen: on the GitHub pull request, with evidence, policy, and a clear verdict.
Install Critique