How Atlassian accelerated code review in a large monorepo using agentic pipelines

A CSS bug fix drew a comment about data fetching. The AI reviewer had read every team's guidelines and decided all of them applied. In a monorepo shared by many product teams, that approach produces comments a developer has to dismiss one by one.

The problem with handing an agent everything at once

A single style guide would not work in one of Atlassian's largest frontend monorepos. Different teams keep their own review guidelines in specific directories. The rules differ by area, and they are written that way on purpose. For any given pull request, most of those documents have nothing to say.

A human reviewer who owns a specific area knows which document to open. An agent that starts with all of them 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. Elsewhere in the set sits a document about data fetching. It has no bearing on a styling change, but an agent holding both documents will happily write the fetching comment anyway. The human reviewer then has to work out whether the comment is about the code or about a document that should never have been opened.

The Jira team fixed this by splitting the job into two steps with Agentic Pipelines. The first agent matches the changed files to the guideline documents that cover them. The second reads that short list, reviews the diff against only those documents, and leaves inline comments. The author and the human reviewer still decide what to change.

How the matcher and reviewer divide the work

Agentic Pipelines runs one agent per step. In the first step, the matcher reads the pull request through the Bitbucket MCP server, pairs each changed path with the guideline file that covers it, and writes that list to tmp/pr-analysis.md. If the Bitbucket pull request tools do not return a specific file the agent needs, the matcher can read that file directly from the checked-out copy of the repository.

Most of the prompt is about what the matcher must not do. Point an agent at a pull request and it wants to review it. Leave the wording loose and you can get something worse: an agent that writes a script, adds files and finishes the step without leaving a single comment. The prompt tells the matcher to use the repository checkout if a file is not in the pull request tools, and if no changed file is in scope, to say so in tmp/pr-analysis.md. Otherwise it lists the changed path and the guideline file that applies. It does not review the code.

The reviewer reads tmp/pr-analysis.md, opens only the guideline files it lists, and comments on the diff. Atlassian briefs it as a principal engineer for that area of the codebase. Each area's guidelines are local and a little strict, and the team wanted the reviewer's tone to match. Praise, nitpicks and a walkthrough of what the diff does stay off the pull request, because they are easy to generate and tedious to clear. The prompt also rules out new files and new commits. The reviewer's job is done when its comments are on the pull request.

The hand-off between the two agents is a single pipeline artefact. When the reviewer step starts, it has the artefact and the checkout, and the only things it needs to read are the diff and the files the artefact names.

The numbers that matter

On one very large pull request, both steps finished in about seven minutes. Authors in this repository used to wait up to half a day, sometimes a full day, for a first review pass. The pipeline catches the obvious guideline misses before a teammate even opens the pull request.

Making the comments worth reading took more effort, and a lot of it went into the guideline files rather than the prompts. Vague guidelines produce vague comments, whichever model runs the step, and developers quickly learn to ignore them. The guidelines that worked were the ones that spelled out what that team actually cares about. That only happens if someone says when a comment was wrong or useless. 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.

Atlassian plans on rewriting prompts after a month or so of real pull requests. The matcher should list file paths and guideline names, and nothing else. If the matcher adds its own observations, the reviewer treats them as conclusions that have already been reached. And if the comments are not good, the speed does not matter. A seven-minute review that a developer has to dismiss, comment by comment, costs more than it saves. It is only worth having when each comment is something a thoughtful teammate might have written.

What this means for engineering teams

If your repository has one contributing guide, skip the matcher. The second agent earns its keep when different directories have different owners, and those owners have already written down how they review. Atlassian recommends three things: write the guidelines before you write the prompts, give each agent one job and let them communicate with artefacts, and run it by hand first while keeping a person on approval.

Every comment the reviewer leaves traces back to a guideline file. Give each area its own file in the repository, and fill it with the cases that team actually argues about in review, not generic best practice. One agent picks the documents, and the other reviews against them. The moment the matcher starts reviewing, or the reviewer gets every guideline pasted into its prompt, you are back to one agent holding everything.

Try the pipeline on a few real pull requests before you turn on the automated trigger. Read the first comments with the author, and fix the guideline file whenever a comment misses. Atlassian uses the same pattern to do vulnerability fixes, clean up stale feature flags and update documentation. Agentic Pipelines is in beta on Bitbucket Cloud. Rovo Dev requires a paid Bitbucket Cloud plan with Pipelines enabled, plus a Rovo Dev Standard subscription. Claude and Codex use an account your organisation already has, and that provider bills for the tokens.

Sources:

• Atlassian, 14 October 2026