Atlassian Split the Reviewer in Two. Ship the Matcher's Reject Pile.

Last quarter Atlassian's AI reviewer told a developer who was fixing a CSS bug to rethink how their component fetched data. Well written, confidently worded, about code they hadn't touched. Arthy Vijayaraghavan's write-up of what the Jira team did about it is the most useful engineering post I read this week, and it has one blind spot I've already paid for in my own pipeline.

The short version

Atlassian's Jira team split its AI code reviewer into two agents with a file between them, per Arthy Vijayaraghavan's post on Agentic Pipelines. A matcher pairs each changed path with the guideline document that covers it and writes the list to a file; a reviewer opens only what the file names and comments on critical issues. The rule for the hand-off is to keep the matcher's output dull, and the loop that keeps comments worth reading is human: the owning team edits the guideline whenever a comment missed or cited a rule the file never stated. That loop only sees comments that appeared. A comment never written, because the matcher routed the change to the wrong document or to none, leaves nothing on the pull request to correct. My reading pipeline has the same shape, a script that scores posts and a reader who sees only the keeps, and this week it read 221 posts and dropped 136. Every bug I've found in it was in the drops. The agent drop: a second dull file beside the first, listing the changed files the matcher mapped to nothing and the guidelines it hasn't routed to in a month, read weekly.

Two agents and a file

The failure was structural. One of Atlassian's largest frontend monorepos is shared by many product teams, and each keeps its own review guidelines for its own directories. A human reviewer who owns an area knows which document to open. An agent handed all of them at once has to pick the right one and review in a single pass, and when it picks wrong, the comment is about the wrong thing. The data-fetching document has nothing to say about a styling change, but an agent holding both will write the fetching comment anyway.

So they split the job. The matcher reads the pull request through the Bitbucket MCP server, pairs each changed path with the guideline file that covers it, and writes the list to tmp/pr-analysis.md. Most of its prompt is about what it must not do. Point an agent at a pull request and it wants to review it, so the prompt says: matching is the whole job, do not review, do not comment, do not create any other file. If no changed file is in scope, say so and stop.

The reviewer starts fresh with the diff and that file. It opens only the guideline files the file names, comments on critical issues and real concerns, and skips praise, nitpicks, and walkthroughs, because those are easy to generate and tedious to clear. No new files, no commits.

The rule I'd put on a wall: keep the matcher's output dull. File paths and guideline names, nothing else. If the matcher adds an observation, the reviewer treats it as a conclusion already reached.

On one very large pull request both steps finished in about seven minutes, which the post is careful to call a single run and not a benchmark, against a first human pass that used to take up to half a day. And the post is just as careful about what the speed is worth: if the comments aren't good, a seven-minute review the developer has to dismiss comment by comment costs more than it saves.

The loop, and the thing it can't see

What makes the comments good is not the prompt. The post says so: most of the effort went into the guideline files, because vague guidelines produce vague comments whichever model runs the step. And the mechanism that improves the guidelines is a person. The owning team reads the inline comments alongside the pull request author and edits the guideline file whenever a comment missed something or cited a rule the file never stated.

That's a real feedback loop and it's the right one. Here's its blind spot.

Every signal in it is a comment that appeared. A wrong comment gets dismissed, someone notices, the guideline gets fixed. A comment that should have been written, and wasn't because the matcher paired the changed file with the wrong document or with none, leaves nothing on the pull request. Nobody dismisses it. Nobody edits anything. The loop learns only from what showed up, and the matcher's errors are precisely the ones that show up as silence.

The reviewer never tells you what it was never shown.

I've been running this shape for a month

My reading pipeline is the same two agents with a file between them. A script fetches every post from the sources I follow, scores each one against the five topics this site is about, labels the ones that pass, and writes a digest. I read the digest. I never see what the script dropped unless I ask for it.

This week it read 221 posts and kept 85. It dropped 136.

I wrote up the first three bugs in that script in I Automated My Reading. The Filter Was Wrong Three Times. One version weighted a title like a summary and dropped an enterprise-agents case study while keeping a demand-generation post. One scored a piece about Codex at zero because the vocabulary had no proper nouns in it. One flagged a company I supposedly under-cover because it counted posts instead of mentions per post. All three were proxies that looked like the real quantity. All three were invisible in the keeps. All three were found by reading the drops.

That's the same blind spot as Atlassian's, from the other side. My keeps were clean the whole time. The matcher that dropped the case study produced a digest with nothing wrong in it, and if I'd only ever read the digest I'd have concluded the filter was fine. A Name on the Definition, and the Reject Pile is where that became the standing rule: definitions fail in what they exclude, so the rejects are the audit, not the output.

The drop: a second dull file

So here's the one-afternoon change to Atlassian's pipeline, and to any two-agent split where the first agent routes and the second one acts.

Next to tmp/pr-analysis.md, the matcher writes a second file, just as dull as the first. Three columns.

1. Changed files mapped to no guideline. Every path in the pull request the matcher decided was out of scope. This is where the comment that never got written lives.
2. Guideline files not routed to in the last 30 days. A document nobody's changes ever match is either covering a dead directory or being missed. Both are worth a look.
3. Pull requests where the matcher returned nothing at all. The "no changed file is in scope, stop" case, counted.

Then the owning team reads it on the same cadence they already read the comments. Weekly is enough. The first file tells the reviewer what to look at. The second tells the humans what the reviewer was never shown.

One disagreement with the post. It says if your repository has one contributing guide, skip the matcher, since it would pick the same document every time. I'd keep the file. With one guide the matcher's real job is deciding which changed files are in scope at all, and the out-of-scope list is the only place a missed comment can be seen. The step costs one file. The alternative is a pipeline that gets quieter as it gets worse.

This belongs to the Enterprise AI Agents argument that an agent's own output can't tell you what it missed, and that the check has to come from somewhere downstream or from the pile it left behind. The Seven-Agent Reset: A Lean PM AI Fleet, One Agent Per Stage is the fleet version of one agent per job; this is what the hand-off between two of them owes the person reading the result.

This week: find the first step in any pipeline you run where one agent decides what a second agent sees. Make the first agent write down what it excluded. Read that list once. If it's clean, you've lost an afternoon. It won't be clean.

Related answer: What does a two-agent code review pipeline miss?

Sources: Arthy Vijayaraghavan, "How we accelerated code review in a large monorepo using Agentic Pipelines," Inside Atlassian, October 14, 2026, read in full. The 221, 85, and 136 counts are from this week's run of the reading script in this site's repository (docs/growth/creator-scan/2026-10-15.md). I Automated My Reading. The Filter Was Wrong Three Times. and A Name on the Definition, and the Reject Pile, falkster.com, for the three bugs and the reject-pile rule.