Why I added Rovo Dev even though we already had Claude Code in the stack
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 the underlying models. It is the agent harness that runs on top of them, and you select which large language model it uses, today Anthropic Claude and OpenAI models. 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 Rovo Dev is its own agent harness and lets you switch the underlying model inside the CLI or IDE with the /models command. Today that set includes Anthropic Claude models (Haiku, Sonnet, Opus) and OpenAI models (GPT-5.x and the GPT-5.x-Codex variants). To be precise, Codex here means the OpenAI GPT Codex model, not OpenAI's separate Codex CLI. You get access to multiple leading models without managing a separate subscription for each one, and the available set expands over time.
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
Was this helpful?
Thanks!
Alexander Nilsson
3 comments