Atlassian splits monorepo review into two agents: one picks the guidelines, one reviews against only those
Oct 14, Inside Atlassian. In a large frontend monorepo where each team owns its own review rules, a reviewer holding every guideline left confident comments about code nobody touched. The Jira team put a matcher agent and a reviewer agent in separate Bitbucket Agentic Pipelines steps, connected by one file, and spent most of the effort on the guideline documents.
Source: How we accelerated code review in a large monorepo using Agentic Pipelines
Arthy Vijayaraghavan's write-up opens with the failure: an AI reviewer told a developer fixing a CSS bug to rethink how their component fetched data, in a well-written comment about code they hadn't touched. The cause was structural. In one of Atlassian's largest frontend monorepos, each product team keeps its own review guidelines for its own directories, and an agent given all of them at once has to choose the right document and review the code in a single pass. When it chooses wrong, the comment is about the wrong thing, and a human has to work out which.
Two jobs, two agents, one file between them
The Jira team split the work into two Bitbucket Agentic Pipelines steps. A matcher pairs each changed path with the guideline file that covers it and writes that list to tmp/pr-analysis.md; a reviewer starts fresh with the diff and only the documents named there. Most of the matcher's prompt is about what it must not do, because an agent pointed at a pull request wants to review it, and loose wording produced one that wrote a script, added files, and finished without leaving a comment. Two smaller lessons travel well. A sample pull request ID left in the instructions can make the agent review that pull request instead of the real one, so the ID has to come from the pipeline. And the matcher's output should stay dull, because if it adds its own observations, the reviewer treats them as conclusions already reached.
Speed was the easy part
On one very large pull request both steps finished in about seven minutes, against a usual wait of half a day to a full day for a first review pass, and the authors are careful to call that a single run, not a benchmark. The harder work was making comments worth reading, and much of it went into the guideline files rather than the prompts: the owning team reads the inline comments with the author and edits the guideline whenever a comment missed or cited a rule the file never stated. That is the feedback loop that makes an always-on reviewer compound instead of accumulating ignored comments, and the post states the cost of skipping it plainly: a seven-minute review that a developer has to dismiss comment by comment costs more than it saves. Approval stays with people because runs vary, and the extra matcher step only earns its keep where different directories have different owners who have already written down how they review. Compare Fin sharing one standards skill between its coding and review agents.