AI Code Review That's Signal, Not Noise
An agent can review every PR you open. Whether that's useful or just more comments to ignore comes down to one thing: does the reviewer know your team's standards?
AI code review is one of the highest-leverage jobs you can hand an agent — every pull request, reviewed instantly, before a human looks. But most teams that try it quietly turn it off, because the reviews are noise: generic style nits and surface observations that reviewers scroll past. The difference between useful and ignorable isn't the model. It's context.
What good AI code review does
A useful review reads the diff and checks it against how your team actually works: does this follow the patterns you standardized on? Does it reintroduce something you tried and rejected? Does it touch code someone specific owns? It catches the mechanical and consistency issues so human reviewers spend their attention on design and trade-offs — the things only people can judge.
Why most AI reviews are noise
The common failure is that the agent reviews in a vacuum. It doesn't know your conventions, your past decisions, or your ownership — so it falls back on generic observations that apply to any codebase. Those comments are technically correct and completely useless, and reviewers learn to ignore the bot entirely. A reviewer that doesn't know your standards can't enforce them.
The fix: give the reviewer context
An AI reviewer is only as good as what it knows. Feed it your team's decisions — the patterns you chose, the approaches you've ruled out, who owns what — and the same model produces a completely different review: it flags a change that contradicts a standard you set, notices a reverted approach sneaking back, and tags the right owner. Signal instead of noise. The change is the context, not the agent.
First-Tree is the platform that gives the reviewer that context.
It's an open-source orchestration platform where humans and agents work side by side: PRs and issues become the work queue the reviewing agent picks up, agents coordinate the handoff in shared threads, and your team's decisions and ownership live in an owned, versioned context tree every agent reads — whether you run review through the Claude Code GitHub Action, Codex CLI, or your own bot. The reviewer stops guessing your standards because it can see them.
The same PR, reviewed two ways
The gap between noise and signal is easiest to see on one diff. Say a
PR adds a fetch() call with its own retry loop. A reviewer
with no context leaves the comment on the left; a reviewer that has read
your team's decisions leaves the one on the right:
| Context-free review (noise) | Context-aware review (signal) |
|---|---|
| "Consider adding error handling to this fetch call." | "We standardized on the httpClient wrapper for
retries in March — this hand-rolled loop bypasses our timeout and
tracing defaults. See the networking decision in the context tree." |
| "This function is a bit long; consider splitting it." | "This reintroduces the per-request cache we removed last quarter for the stampede bug. Flagging the owner of the caching module to confirm before merge." |
Same model, same diff. The left column is what reviewers mute; the right column is what gets a PR fixed before a human spends a minute on it. The only thing that changed is what the reviewer was allowed to know.
Wiring review into the queue
A useful reviewer isn't a chat window you paste diffs into — it's a step that fires automatically when a PR opens, runs a defined first pass, and posts back. The trigger is just your CI. A minimal GitHub Action hands the diff and your context to the agent on every pull request:
# .github/workflows/ai-review.yml
on:
pull_request:
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: first-tree inject --for . > CONTEXT.md # team decisions + ownership
- run: agent review --diff "$(git diff origin/main...HEAD)" --context CONTEXT.md --post-commentsThe shape that matters is the order: pull the context first, then review. Skip the inject step and you're back to a reviewer guessing your standards. With it, the agent runs the same first pass on every PR — the mechanical checks below — and a human only looks once that pass is clean.
- Read the diff in scopePull only the changed hunks plus the files they touch, not the whole repo — focused context, faster review.
- Check against decisionsCompare the change to the patterns your team standardized on and the approaches you've already rejected.
- Flag contradictions, not styleComment when the diff fights a real decision or reverts a past fix — skip the generic nits a linter already owns.
- Route to the ownerTag whoever owns the touched module so the right human sees it, instead of spraying the whole team.
- Hand off cleanSummarize what passed so human review starts on design and trade-offs, not on re-checking the basics.
Notice what the agent never does: it doesn't approve, and it doesn't decide trade-offs. Mechanical and consistency checks are delegable; judgment isn't. Drawing that line on purpose is what keeps the first pass fast and the human pass high-leverage — and keeps a linter's job (formatting, unused imports) out of the review entirely, where a plain CLAUDE.md rule or a pre-commit hook handles it cheaper.
Where it fits
AI code review is one job in a larger agent workflow — and it benefits from the same foundation as the rest: a tight CLAUDE.md for local rules and a shared context tree for the team's decisions. That's the setup behind running AI agent teams on First-Tree — where agents pick up work from your GitHub queue, coordinate alongside humans in shared threads, and read the same context tree, so they actually participate in your repo instead of adding to the noise.