Thank you to everyone who joined our Accelerate your code reviews with Rovo Dev webinar (if you missed it, you can watch it on demand).
We received over 600 questions across the sessions we ran. This post summarizes questions around key themes and provides answers so you can reference them as you evaluate Rovo Dev.
Some of the questions were specific to your environment and use case, for those, we recommend starting a new thread here in the community or if you have a paid plan, you can reach out to support.
In reviewing responses, we also confirmed a few updates. We’re making Rovo Dev code review available in Bitbucket Data Center and GitLab soon. The beta launches in a few weeks, and we’ll use your feedback to shape the timing of general availability. If you’d like to be part of the beta, please join the waitlist.
If you don’t see an answer to your question, or have follow-up questions, please leave a comment here, and we will get back to you.
Q: Do I need Jira or Bitbucket to use Rovo Dev code review?
Jira Cloud is required to enable Rovo Dev to work. Once Rovo Dev is enabled in Jira, you can use it with Bitbucket or GitHub.
Additionally, when you include your Jira issue key in your pull request title or commit message, Rovo Dev can also review your code against the acceptance criteria defined in those issues.
Q: Can I try Rovo Dev before rolling it out to my whole team?
Yes. You can test Rovo Dev with a few developers and repositories to see how it fits your workflow before expanding more broadly. Details on plans and trials are on the pricing page.
Q: Is Rovo Dev included with Jira or Bitbucket, or is it a separate product?
Rovo Dev is a separate product from Jira and Bitbucket. When you start a trial, you will see Rovo Dev appear as a product in Atlassian Admin.
Q: How does the per-user credit model work?
Rovo Dev uses a seat + usage-based pricing model with credits:
You can purchase Rovo Dev seats for developers who needs them. You don't need to purchase seats for everyone in your organization.
Rovo Dev Standard Plan is priced at $20 / user / month, which includes 2,000 credits; overage is billed at $0.01/credit.
A pull request review charges the PR author's credits.
Rovo Dev credits are per user and per site; they are not pooled org-wide.
Q: How far does 2000 credits take you?
We estimate that you can review 30-50 PRs with 2000 credits. Note that these are 2000 credits per developer. Credits are only charged to the PR author's account. e.g. if you have 100 developers with Rovo Dev, you can review about 300-500 PRs/month.
Credit usage depends on the intensity of code changes. To get a better estimate for your PRs, start a free trial and try it out.
Credits can be used for any of Rovo Dev’s features - code generation in the CLI or IDE, code review in Bitbucket or GitHub, and debugging builds (only av. in Bitbucket Pipelines).
Q: Can we pool credits?
Rovo Dev credits are per user and per site. They are not pooled.
Q: Is my code used to train Atlassian’s AI models or any third‑party models?
No. Atlassian does not use your code and related data to train models for other customers. Reviews are run in an isolated context per customer.
We also have agreements with our LLM providers so that they do not retain your inputs/outputs and do not use them to train their models.
We publish detailed information about how Atlassian handles your data, including retention, isolation, and model usage.
Q: Can admins control where Rovo Dev is enabled and who can use it?
Yes. your Atlassian org admin can decide which users have Rovo Dev seats.
Your repo admins can control which repositories have Rovo Dev code review turned on and configure when reviews run (for example, only on demand, or on every new commit).
This makes it possible to do a gradual rollout and limit Rovo Dev to specific teams or repos as needed.
Q: Can admins see how many credits are being used and by whom?
There is visibility into usage and billing at the account level, and developers can see their own credit usage.
We hear your asks for richer usage visibility by team/repo and more flexible ways to manage spend; that feedback is directly informing how we evolve our admin and reporting features.
Q: How do we tell Rovo Dev about our coding standards and review rules?
When you sign up for Rovo Dev, you can create a custom instructions file which includes:
Your coding conventions and style preferences.
Security and performance rules you care about most.
Architecture and domain rules (for example, “services in folder X must not call Y”).
Rovo Dev uses these instructions alongside the pull request diff and project context to tailor its review to your team.
Here’s how to set it up:
Create a .rovodev folder in your repository root.
Add a .review-agent.md file in the .rovodev folde. This file is where you can add clear, specific instructions for Rovo Dev to follow when reviewing pull requests in the repository.
Save the file.
Here is our support page and the starter instruction prompts that we shared during the webinar.
Q: Can we reuse existing guidance (like AGENTS.md, Claude.md, or other AI instructions)?
We don’t require a specific format for the markdown file but the file needs to live within the rovodev folder in the repository per the above process. You can copy any existing AI guidance into .review-agent.md file to avoid maintaining two different forms of instructions.
Q: Can multiple repositories share the same configuration?
Today, configuration is defined at the repository level. We know there’s a strong desire for more centralized configuration that can be shared across repositories, and that’s an area we’re actively exploring.
Q: Can Rovo Dev access our coding standards in Confluence?
Rovo Dev’s code review capability does not connect to Confluence yet, but we are working on this. Rovo Dev CLI is connected to Confluence.
Q: Can Rovo Dev work with other ticketing systems besides Jira?
No, we only support Jira for acceptance criteria checks.
Q: When does Rovo Dev run on a pull request?
You can configure when Rovo Dev runs per repository:
Bitbucket Cloud
– Automatically when the PR is created
– Automatically when the PR is created and on each new commit
– Only when the PR author manually triggers it
GitHub
– Automatically when the PR is created
– Automatically when the PR is created and on each new commit
– Manual triggering is not available yet.
Q: Does Rovo Dev review only the changed code or the entire repository?
Rovo Dev only reviews code changes in the pull request, but it uses the context from the rest of your repository. It is designed to be PR‑centric.
Q: Can we prevent Rovo Dev from commenting on certain files or folders?
We don’t have user‑configurable ignore patterns yet e.g., glob lists per repo.
However, there is a built‑in skip list for many file types and paths. Scroll down to the ‘File and pattern exclusions’ section on this page.
For example, Rovo Dev automatically skips:
Minified files (*.min.js, *.min.css)
Binaries / bytecode (*.exe, *.dll, *.class, etc.)
Lock files (package-lock.json, yarn.lock, Pipfile.lock, etc.)
Translations, coverage reports, test snapshots, asset binaries (images, videos, audio, PDFs, archives, fonts)
The .rovodev/** directory itself
Q: Does Rovo Dev approve the PR automatically if everything looks good?
No, a human reviewer has to do the final approval.
Q: Can Rovo Dev integrate with Jenkins instead of Bitbucket Pipelines?
Rovo Dev code review runs in the PR screen in Bitbucket Cloud. If you’re using Bitbucket Cloud with Jenkins, you can still use Rovo Dev to run your reviews. Rovo Dev also has a feature to debug build failures - this is available only in Bitbucket Pipelines.
Q: Does Rovo Dev require Jira issues to do code review?
No. Rovo Dev will still review your code changes even if there is no linked Jira issue.
Linking a Jira issues gives Rovo Dev additional context to review against the acceptance criteria as outlined in the Jira issue.
Q: How does Rovo Dev use acceptance criteria from Jira?
When a pull request is linked to a Jira issue, Rovo Dev can read the issue’s summary, description, and common acceptance‑criteria fields, and based on that, get context on what the code change is expected to accomplish. It uses this context to review if the code changes would deliver what it is expected to.
Q: Does Rovo Dev understand BDD/Gherkin‑style acceptance criteria (AC) and non‑English text?
Yes, Rovo Dev can use BDD/Gherkin‑style acceptance criteria.
We haven’t published a list of supported natural languages for AC checks list, but the underlying LLMs (GPT, Claude, etc.) support many human languages.
Q: For which programming languages can Rovo Dev review code?
Rovo Dev can review code in Java, JavaScript, Python, C++, .NET, Go, Ruby, PHP, TypeScript, Kotlin, Swift, and any other popular language.
Q: What kinds of issues is Rovo Dev good at finding?
Rovo Dev is designed to help with:
Correctness issues (e.g., missing null checks, edge cases, obvious logic errors).
Security and reliability concerns, especially when you ask it to focus on them in your custom instructions markdown file.
Code quality and maintainability (duplicated logic, suspicious complexity, unclear naming, etc.).
Teams also use it to prompt for missing tests or better test coverage.
Q: How does Rovo Dev avoid low‑value comments?
Rovo Dev uses a multi‑step process to generate and then filter comments, so you don’t just get a raw stream of model output. That said, some teams still feel certain comment types are low value. You can reduce noise by:
Being very explicit in your custom instructions file about what you don’t want (for example, “don’t comment on minor formatting if we already have linters”).
Instruct Rovo Dev to focus on high‑impact categories like correctness, security, and performance.
Q: Does Rovo Dev suggest fixes, or just point out problems?
Rovo Dev often suggests concrete improvements in its comments, such as alternative code snippets or refactorings. There is also an ‘Apply suggestions’ button which automatically applies the fixes. Note that this is currently only for smaller fixes. We are working on an autofix feature that will address more complex changes using Rovo Dev’s code-generation capabilities.
Q: Do we support for GitLab, Azure Repos/Azure DevOps, and Bitbucket Data Center/Server?
Today, Rovo Dev code review supports Bitbucket Cloud and GitHub pull requests.
We plan to ship a beta for GitLab and Bitbucket Data Center in a few weeks. If you’re interested in signing up for a beta, join the waitlist.
Q: Do we plan to support more IDEs and local tools?
Beyond VS Code and the CLI, we heard requests for JetBrains IDEs, Eclipse, and other editors.
Today, you can use Rovo Dev via the VS Code extension and Rovo Dev CLI.
We are talking about expanding to more IDEs but we do not have dates to share yet.
Several questions went deeper on which LLMs we use, how they’re configured, and whether you can bring your own model or cloud account.
For code review in Bitbucket and GitHub, we manage the model selection and orchestration for you so you don’t have to tune prompts or pipelines.
In the Rovo Dev CLI, you have more control and can switch between supported models; we’ll continue to evolve this as the model landscape changes.
Full “bring your own model” for hosted code review is not supported today.
We also heard questions about where data is processed, data residency, and how Rovo Dev fits with regulations like GDPR and the EU AI Act.
Rovo Dev builds on Atlassian’s existing cloud infrastructure and security posture.
Dedicated data residency controls for Rovo Dev are not available yet.
For current details on AI data handling, we recommend reviewing our docs.
Many teams asked for more control over how reviews behave, including:
Marking severity levels on comments (blocker vs suggestion),
Using Rovo Dev as a formal “quality gate” alongside tools like SonarQube, and
Running scheduled, whole‑repository reviews, not just PR‑based checks.
Today, Rovo Dev is focused on PR‑centric reviews with repo‑level configuration. Deeper file‑level ignore rules, severity tagging, and scheduled scans of the full repository are areas we’re actively exploring.
Finally, many of you asked how Rovo Dev compares in practice to tools like GitHub Copilot, CodeRabbit, SonarQube, and DIY setups with ChatGPT/Claude.
We don’t have specific benchmarks to share around code review, but sign up for a free trial and compare Rovo Dev's code review vs. any other tool that you’re currently using.
As a platform, here are some reasons to choose Rovo Dev as your developer AI agent.
Rovo Dev is far more than a code review tool. It can generate code from your CLI or IDE (and soon directly from Jira issues), review pull requests, help you debug build failures, and even kick off automated, agentic workflows from Jira.
Rovo Dev also understands the world around your code. Through deep integration with Atlassian’s Teamwork Graph, it can draw on context from your Jira issues, Confluence pages, support tickets, and Jira Service Management knowledge base, alongside your Bitbucket or GitHub repositories, for more relevant output. For example, when reviewing code, Rovo Dev natively connects to Jira issues and checks your code against the acceptance criteria listed in the issue.
For code generation, you can switch between Claude and OpenAI Codex within Rovo Dev, so you get access to multiple leading models without managing multiple subscriptions.
Your feedback helps shape our roadmap, so please continue to share how Rovo Dev is working for you and what features you’d like to see next.
If you haven’t tried Rovo Dev yet, you can sign up here.
Thank you again for all the questions and feedback you shared during the webinar. If you have additional questions, please let us know.
Ash Moosa
0 comments