The GitHub PR Review Agent I Would Trust#

Most AI code review bots are annoying because they review code like they are trying to prove they exist.

They comment on style. They repeat what the diff already says. They miss the actual risk.

A useful PR review agent needs a different job:

Find the problems a tired engineer might miss before merge.

That is a workflow problem, not a prompt problem.

Do not make one agent review everything#

Code review has different kinds of judgment:

• What changed?
• Which services are touched?
• Are tests missing?
• Did an auth or billing path change?
• Did a migration change data shape?
• Is CI failing for a real reason?
• Does this violate an architecture decision?

One general agent can do a pass. A production workflow should split the work.

Diff Scout

Reads the PR, classifies touched files, finds risky paths, and summarizes the change.

Architecture Reviewer

Checks boundaries, service ownership, data contracts, migrations, and coupling.

Security Reviewer

Looks for auth changes, secret leaks, unsafe permissions, and dependency risk.

Review Composer

Turns findings into a concise review with severity and evidence.

That keeps the output cleaner. It also makes evals possible.

The agent should know when not to comment#

This matters.

The goal is not to maximize comments. The goal is to improve merge quality.

Rules I would add:

• Do not comment if the finding is purely preference.
• Do not repeat CI output unless you explain the likely cause.
• Do not block unless the issue is high severity or confirmed by evidence.
• Do not quote secrets.
• Do not approve changes to auth, billing, deploy, or migrations without owner review.

This is where most review bots fail. They have no taste. They have no threshold.

Tool access#

The workflow needs:

• GitHub diff and file reads.
• CODEOWNERS.
• CI logs.
• Architecture docs.
• Previous issues or incidents.
• Dependency metadata.

Posting comments should be a higher risk action than reading the diff.

I would start with draft comments. Once the useful finding rate is high, allow final comments on low-risk issues. Blocking reviews should stay gated.

Model routing#

Do not use the same model for every step.

Use a cheaper model for diff classification. Use a stronger reasoning model for architecture and security judgment. Use a writing-focused model for the final review.

And keep the fallback visible. If the preferred model is rate limited, the workflow should say what model took over.

Evals that matter#

Measure:

• Useful finding rate.
• False blocking rate.
• Critical path coverage.
• Secret redaction.
• CI failure explanation quality.
• Human override rate.

The PR agent is ready when engineers start saying, "that was actually useful," not when it posts a lot.

Build it in Codelit#

Try this:

Build a GitHub PR review agent that watches pull requests, classifies the diff, checks architecture risk, security risk, tests, CI, CODEOWNERS, and posts only high-signal comments with evidence.

Build this PR review workflow in Codelit

The bar is simple: fewer comments, better comments.