Rovo Dev: Agent vs. Foundation

TL;DR

Engineers using Rovo Dev, Atlassian's coding agent, need to ask if they use Atlassian's native tools (Teamwork Graph and DX Fabric) as a foundation, or add a different platform layer that works with any agent. Each approach has trade offs, which are presented in this guide.

What is Rovo Dev?

Rovo Dev is Atlassian's coding agent. It runs in the terminal, inside VS Code, or directly on pull requests in Bitbucket or GitHub. Its job is to read the context around a task (the ticket, related docs, similar code that already exists) and then write the code to resolve it.

More than 80% of the Fortune 500 already use Atlassian products, so if you're in that group, Rovo Dev works inside an ecosystem you know. It pulls context from three sources:

• Teamwork Graph: Links between your Jira issues, Confluence docs, and code repositories
• Code Context: A searchable index of your codebase
• DX Fabric: A catalog of your services, who owns them, and how they connect to each other

These three sources let the agent understand what you're changing, why it matters, and what might break.

Atlassian is also sunsetting its older Compass product at end of 2027 in favor of DX Fabric, which adds auto-discovery from deployment data and connectors to tools like PagerDuty and incident.io.

What Your Rovo Dev Setup Might Need

Writing code requires context. Getting that context often takes up a lot of an engineer’s time: finding the right ticket, pulling up the docs from six months ago, searching for code that already does something similar. Rovo Dev addresses this by automating the busywork of context-gathering.

But when code gets deployed, it touches systems the developer didn't write. Those systems might be critical to payments, or they might be unstable, or they might call three other services downstream. None of that information is obvious from reading the ticket. A developer can write clean code that passes review and still ship something that breaks production.

This problem is bigger than any coding agent alone can solve. It needs a foundation: a source of truth about what your systems are, how they depend on each other, what's currently running, and what's important. And it needs that foundation to be live, not a snapshot from hours before.

The choice between Atlassian's approach and an alternative foundation is do you build this foundation inside the Atlassian suite, or do you build it as a separate platform that any agent can read from?

Two Approaches: Atlassian's Suite or a Separate Platform

Approach 1: Build on Atlassian's Native Tools

If your engineering work already lives in Jira, Confluence, and Bitbucket, this is the simpler path. You use what Atlassian ships: Rovo Dev for the agent, DX Fabric for the catalog, and Atlassian's own automation layer to enforce policies.

The upside:

• No new tools to adopt. 
• One vendor, one support contract.
• If your team uses Jira daily, the context is already there.
• Atlassian has invested heavily in making these products work together.

The constraints:

• The catalog relies on manual entry. Someone has to tell DX Fabric which services depend on which other services, using a form or API. This means the dependency graph is only as good as the discipline to keep it current.
• Refreshes happen on a schedule (DX Fabric refreshes every two hours), so the agent sees a snapshot, not live data.
• Automation happens through DX Fabric's own workflow engine, which means it only connects to services Atlassian has built connectors for. If your merge checks live in Bitbucket and your service ownership lives in DX Fabric, there's no native way to wire the two together. You have to build that bridge yourself.
• If you want to use a different coding agent later (Claude Code, Cursor, etc.), you'd have to re-architect this layer.

Approach 2: Add a Separate Platform Layer

The alternative is to add a platform that lives underneath Rovo Dev or any agent. This platform holds the same information (catalog, dependencies, ownership), but it doesn't require manual entry and it doesn't work only with Atlassian tools.

Port is one example. It ingests data from your CI/CD pipelines, Kubernetes clusters, cloud accounts, and incident systems. It derives the catalog automatically (a service appears because a deployment landed), it can build the dependency graph from CI/CD configs and API calls, and tracks who owns what from recent code authors.

The upside:

• The catalog updates live, not on a timer. When something deploys, Port knows about it immediately.
• Dependencies are derived from actual deployments and code, not entered manually. 
• It works with any coding agent. Same platform serves Rovo Dev, Claude Code, Cursor, or custom tooling.
• You can wire automation directly to operational state. A merge gate can check "is this service tier-1 and would this change affect payment paths?" and block automatically.
• It knows about your entire stack (Kubernetes, AWS, GCP, Azure, observability tools), not just Atlassian products.

The constraints:

• It's another platform to adopt and integrate. Your pipelines, clusters, and incident systems have to be connected first.
• The integration takes time. Teams with clean CI conventions and standardized infrastructure get there in weeks. Teams with accumulated technical debt in their deployment scripts take longer.
• You'll still have Atlassian tools. You're not replacing them, you're adding a layer beneath the agent.

When to Choose Each Approach

Choose Atlassian's suite if:

• Your engineering work is already fully in Jira, Confluence, and Bitbucket.
• Your team isn't planning to switch agents in the next couple of years.
• Your infrastructure is mostly AWS (since DX Fabric has native AWS support) and you don't need real-time dependency tracking.
• You want to avoid adopting another platform right now.

Choose a separate platform if:

• You run Kubernetes anywhere in your stack.
• Your deployments happen through pipelines Atlassian doesn't own.
• You get paged through tools outside the Atlassian suite (PagerDuty, incident.io, Datadog, etc.).
• You think you'll use more than one coding agent over the next two years.
• You want automation that responds to operational state in real time.

Comparing the Two Layers

This table compares the two approaches. The comparison is between the layers, not between Rovo Dev and a separate platform. Rovo Dev is kept either way.

A Real Example

dLocal, which handles payments for companies like Google, Uber, and Microsoft, built an internal agent called dCoder that reads incoming tickets, pulls context from a unified data layer (catalog, infrastructure, repositories, ownership), and writes code to their standards. The agent runs on a separate platform that provides governance, audit trails, and approval gates.

With that foundation in place, dCoder handles 45% of engineering tickets autonomously. Their reported numbers: 50% reduction in lead time and mean time to resolve cut in half.

The architecture (an agent reading from a unified platform that provides context and governance) is the same pattern teams consider when evaluating what foundation Rovo Dev should run on. The specific constraints of your stack (Kubernetes, multi-cloud, your deployment pipeline, your incident tooling) determine which approach makes sense.

Start free at app.port.io, or book a demo to see it running against your own services and the coding agent you already use.

Starting Out

If you're evaluating which direction to go:

Start with your infrastructure, not your tools. Do you have Kubernetes? Do your deployments happen outside Atlassian's suite? Do you manage multiple cloud providers? If the answer to any of these is yes, then manual dependency entry isn't going to scale. A separate platform makes sense.

If your entire stack is AWS and Atlassian, then the native approach is simpler. Just be honest about the cost: Someone has to keep the catalog current. It's not a set-it-and-forget-it system.

Be clear about the integration cost. If you choose a separate platform, you'll need to connect your CI/CD pipelines, clusters, and incident tooling first. That's real work. Clean, standardized infrastructure makes it fast. Accumulated technical debt makes it slow. Budget accordingly.

FAQ

What does Rovo Dev do?

Rovo Dev is Atlassian's coding agent. It reads your Jira tickets, related Confluence docs, and similar code in your repositories, then plans and writes code to resolve the ticket.

What is an Agentic SDLC?

An Agentic SDLC is a software delivery system where agents (like Rovo Dev or Claude Code) handle routine coding tasks. Below the agent sits a platform that holds operational context: what your services are, who owns them, what depends on what, what's currently running. Without that platform, agents can write code, but they can't understand the consequences.

Is Rovo Dev an Agentic SDLC?

No. Rovo Dev is a coding agent, a piece of it. The layer underneath, built from Teamwork Graph and DX Fabric, is the part that aspires to be a platform. Today that layer has constraints: dependencies are entered manually, refresh is on a schedule, and you have to build the connectors between catalog state and actual gates.

Can you use Rovo Dev with a separate platform like Port?

Yes. Port works with Rovo Dev, Claude Code, Cursor, and other agents the same way. Rovo Dev reads context from the platform over MCP, and the platform enforces gates and triggers that the agent itself can't run. This is the recommended pattern if you go the separate platform route.

Does that mean I'm running two catalogs?

Only if you want to. You'd need to pick one source of truth (either DX Fabric or the separate platform) and have Rovo Dev read from there. If you're a Compass customer, you already have a migration to DX Fabric on the calendar (by 2027), so this is a good time to decide which system you want your agents to consult.

What are the alternatives to Rovo Dev?

For coding agents: Claude Code, Cursor, GitHub Copilot, or internal tools like dCoder. For the platform layer: DX Fabric (Atlassian's native path), or OpsLevel, Cortex, Backstage, and Port.

When should you choose Rovo Dev?

When your team lives in Jira and Bitbucket and wants a coding agent that understands your tickets and code without extra configuration. Just be clear-eyed about whether Rovo Dev alone will give you what you need, or whether you need something underneath it.

What's the real difference between the two approaches? Atlassian's approach says: Use our suite, and we'll build the platform beneath the agent for you. The separate platform approach says: Keep whatever agent you want, and we'll build a platform that works with it and knows about your entire stack, not just one vendor's products. Neither is wrong. It depends on what your infrastructure looks like and what you're trying to optimize for.

{{from_manual_to_autonomous_engineering}}