Why I added Rovo Dev even though we already had Claude Code in the stack

[#1]

The real difference between Rovo Dev and other AI coding agents is the context they can access

If you already run Claude Code, GitHub Copilot, or OpenAI Codex in your team, you have probably asked the question I hear in almost every evaluation:

Why add Rovo Dev when a capable coding agent is already in the stack?

This article argues that the question is framed around the wrong variable. The comparison most teams run is model against model, and on that axis Rovo Dev is not really a competitor to Claude or Codex. It runs them. The variable that actually differs is the context the agent can reach, and that is where the decision should be made.

Why the model comparison is the wrong frame

The default way to evaluate a new AI coding tool is to benchmark its output quality against the tool you already use. For Rovo Dev that benchmark is close to circular, because for code generation you can switch between Claude and OpenAI Codex inside Rovo Dev itself. You get access to multiple leading models without managing a separate subscription for each one. The set of models available for generation has expanded over time, including newer OpenAI Codex variants.

There is one nuance here that is easy to miss. The model choice is most explicit in the Rovo Dev CLI, where you control which supported model runs. For hosted code review in Bitbucket and GitHub, Atlassian manages model selection and orchestration for you, so you do not tune prompts or pipelines per provider. Full "bring your own model" for hosted code review is not supported today.

So if you put Rovo Dev's raw generation quality next to a standalone Claude or Codex agent, you are largely comparing the same engines. The model is not the differentiator.

What you actually buy is the Teamwork Graph context layer

The thing that is genuinely different is what the model is allowed to see before it reasons. A standalone coding agent starts from your repository and whatever you paste into the prompt. Rovo Dev starts wider.

Through Atlassian's Teamwork Graph, Rovo Dev can draw on context from your Jira issues, Confluence pages, support tickets, and your Jira Service Management knowledge base, alongside your Bitbucket or GitHub repositories. Atlassian describes the Teamwork Graph as the data intelligence layer of the Atlassian Cloud Platform, a unified data model that maps the relationships between work, knowledge, people, and goals across Atlassian and connected third-party tools.

That positioning matters for how you read the product. Atlassian is not betting on a proprietary LLM that out-reasons the frontier labs. It is pairing frontier models it does not own with a context graph that it does own. The defensible asset is the graph, not the model. When you adopt Rovo Dev, the graph is the part you are actually buying.

How the context shows up in practice

The clearest concrete example is acceptance-criteria review. When a pull request is linked to a Jira issue (by putting the issue key in the PR title or a commit message), Rovo Dev can read the issue summary, description, and common acceptance-criteria fields, then review the code change against what the issue says it is supposed to deliver. A standalone agent with no link to your tracker cannot do that unless you paste the requirements in by hand every time.

The same context awareness extends across the developer journey, from generating code in the CLI or IDE to reviewing pull requests, debugging build failures in Bitbucket Pipelines, and kicking off agentic workflows from Jira. In each case the differentiator is not how the model writes a function, it is whether the model already knows why the function exists.

What to keep in mind before you go live with Rovo Dev

• Jira Cloud is mandatory. Rovo Dev is enabled through Jira Cloud. If your tracker is not Jira, the acceptance-criteria check does not apply, because Rovo Dev only supports Jira for that check.
• It is a separate product. Rovo Dev is not bundled with Jira or Bitbucket; it shows up as its own product in Atlassian Admin on a seat-plus-usage credit model. As of June 2026 the Standard plan is 20 USD per user per month including 2,000 credits, with overage billed per credit, and credits scoped per user and per site rather than pooled org-wide. Check the current pricing page before you model spend.
• A human still approves. Rovo Dev does not auto-approve a pull request even when the review is clean. Final approval stays with a human reviewer.
• Data handling. Atlassian states it does not use your code to train models for other customers, and that it has agreements with its LLM providers not to retain inputs or outputs for training. Dedicated data-residency controls for Rovo Dev were not available yet, which matters if you have hard residency requirements.

None of these are dealbreakers on their own. They are the lines you draw so the internal conversation is about reality, not the brand promise.

So when does Rovo Dev earn its place?

Reframe the evaluation away from "is its model better than my current agent" toward "do I want my agent grounded in my Atlassian context." If your requirements, decisions, and support history live in Jira, Confluence, and JSM, the context layer does work no standalone agent can replicate without a lot of manual pasting. If your team works entirely outside Atlassian, most of that advantage evaporates and the model-parity argument points you straight back to whatever agent you already like.

The honest test is simple: Just pick the surface your team actually works in, list the sources you want an agent to read before it writes a line, and check how many of them Rovo Dev reaches there today.

References

• Rovo Dev product page
• Teamwork Graph, the Atlassian Cloud Platform data intelligence layer
• New AI models available in Rovo Dev (including Opus 4.7 and GPT 5.5)
• Set custom instructions for code reviews

If you have run Rovo Dev next to a standalone coding agent, I am curious where the context layer earned its keep and where it did not. Which sources mattered most in practice? The linked Jira issue, Confluence, the JSM knowledge base, or just the repo? I am also curious to hear in which scenario you are currently using Rovo Dev.

I am looking forward to your comments. 

Greetings,

Alex

[Frank Sherwood]

"Rovo Dev runs Claude and Codex"

I'm very sensitive to ambiguity, and this is very much an ambiguous statement. "Codex" (currently) specifically means OpenAI's particular coding agent.  "Claude" by itself would generally mean the chat front-end, as opposed to Claude Code, or Claude Cowork front-ends.  Or it can also be used generically for any of the Anthropic Claude LLMS:  Haiku, Sonnet, or Opus.

So does this mean Rovo Dev runs Claude Code and Codex?  Does it mean a user can choose between Claude Code vs Codex? 

Or does it mean Rovo Dev uses (at its discretion) both Claude LLM and the Codex agentic coding harness ?  Even that seems questionable, because it seems that Rovo Dev is its own agent harness.

And if Rovo Dev is an agent harness on it's own, then why/how would it employ a different one such as Codex?  Don't you mean instead that Rovo Dev uses both Claude and OpenAI LLMs?

I can't find anything in the Rovo Dev product info with any specifics.  Which seems typical of all things Rovo. Atlassian is generally quite opaque about what they do in the background - which providers they use, when, and for what purposes.

[Frank Sherwood]

Also, how much of the context benefit of Teamwork Graph could you get by simply wiring the Rovo MCP into your existing agentic coding stack?