Daniel Kim

Posted on Aug 19

Atlassian Code Context Makes AI Agents 44% More Accurate. Its Fine Print Puts the IP Risk on You.

#ai #atlassian #devtools #security

On August 12, Atlassian shipped something with a boring name and an unboring implication: Code Context, a new layer in its Teamwork Graph that indexes your source code — across every repo you connect — and hands it to Rovo, Jira, and any coding agent that asks nicely. Atlassian's internal benchmark claims agents get 44% more accurate and burn 48% fewer tokens once they have it. Those are good numbers, and Atlassian's own documentation undercuts the pitch in a way most launch posts never do: if you use this feature through its command-line interface with Claude Code, Cursor, or Codex, your source code leaves Atlassian's infrastructure and lands inside a third party's, "governed by their terms" — and you, not Atlassian, are on the hook for deciding whether that's acceptable.

That sentence, buried in a support article rather than the press release, is the actual story here. Everyone selling AI coding tools in 2026 is selling "context." Almost none of them are this candid about where that context goes once it leaves the building. This piece digs into what Code Context does, how the indexing pipeline actually works, what Atlassian's own fine print says about it, and how it stacks up against Sourcegraph, GitHub Copilot, and Cursor's built-in retrieval — three products already fighting over the exact same "context is the real differentiator" argument.

What happened

Code Context is a rename-and-expand of a feature Atlassian previously called "Code Intelligence." It's now generally available in open beta, folded into the Teamwork Graph — the data-and-permissions layer Atlassian unveiled at its Team '26 conference in May to unify Jira issues, Confluence pages, Loom recordings, and roughly 100 connected third-party apps into one queryable graph. Code Context adds source code to that graph as a first-class citizen, connected via Bitbucket or GitHub.

The launch was accompanied by a quote from Mark Walz, CTO of point-of-sale vendor SpotOn, a real enterprise customer rather than a hypothetical persona: "When an agent starts in the wrong place, everything slows down and costs more. Developers end up explaining where to look, why the code works the way it does, and what else it touches. Code Context puts all of that in front of the agent from the start, so it can focus on getting the work done." Sanchan Saxena, Atlassian's SVP and head of product for the Teamwork Collection, framed it as a two-part bet: "Frontier intelligence gives teams speed. Context points that speed in the right, most impactful direction."

That framing matters because it's a direct shot at the current AI-coding-tools arms race, where every vendor claims access to the same handful of frontier models. If the models converge, Atlassian's argument goes, the fight moves to who can hand those models the right sixty lines of code out of six million.

What it actually does

Strip the announcement language and Code Context is a retrieval system for source code, wired into three surfaces:

Rovo Chat — ask a natural-language question ("where is auth token refresh handled?") and get an answer grounded in indexed code plus related Jira tickets, Confluence pages, and Loom clips, not just a keyword match.
Jira and the wider Atlassian ecosystem — code context surfaces inline where teams already work, rather than requiring a context switch to a separate search tool.
The Teamwork Graph CLI — a command-line interface that lets any coding agent, including third-party ones, query the graph before it plans or edits. Atlassian explicitly names Cursor, Claude Code, and Codex as agents that can use it this way.

Under the hood, Atlassian's own documentation describes two complementary retrieval modes: lexical search (traditional keyword/string matching, for when you know the exact function name) and semantic search (embedding-based retrieval for when you know the concept but not the identifier). In Rovo Chat and the CLI, the underlying agent picks a mode automatically, sometimes blending both.

How the indexing pipeline works

This is the part most coverage skipped, and it's worth walking through because it explains both the accuracy claim and the risk section below.

An org admin opts in per site under Atlassian Administration → Rovo → Code context. It is off by default — nothing gets indexed until someone with admin rights turns it on, and once on, individual contributors cannot exclude their own repos from indexing (Atlassian's docs note this deliberately mirrors how Bitbucket's existing lexical search already behaves).
Atlassian connects to repositories via the GitHub-for-Jira connector or the native Bitbucket integration.
For GitHub repositories specifically, the code is mirrored into Atlassian's own infrastructure before indexing. Bitbucket repositories, by contrast, are indexed directly, without a separate mirrored copy — because Bitbucket is already Atlassian's own system.
Files are chunked and converted into vector embeddings using what Atlassian describes as a code-optimized embedding model. Embeddings are stored as non-human-readable numerical representations, alongside the raw code chunks, in what the docs call "a secure, isolated environment."
Pushes and branch updates trigger incremental re-indexing, so the graph doesn't go stale immediately — though there's a lag (more on that below).
Disabling code context stops indexing immediately and deletes all stored embeddings, chunks, and indices.

Permissions are enforced at query time against the live repository ACLs in GitHub or Bitbucket, not against a permissions snapshot taken at indexing time — Atlassian's stated design goal is that an agent or user can never see through Code Context anything they couldn't already see by opening the repo directly.

That GitHub-mirroring detail is the one to sit with. It means opting into Code Context for a GitHub org doesn't just let Atlassian query your code — it creates a second, Atlassian-hosted copy of it. For most teams that's an unremarkable SaaS pattern (Cursor and Sourcegraph both do versions of the same thing), but it's a meaningfully different security posture than "Atlassian reads your code over an API call," and it's not the framing used anywhere in the launch materials.

What changed vs. before

Before Code Context, an agent working inside a single repo — via Rovo Dev, Claude Code, Cursor, or anything else — was limited to whatever was checked out locally or explicitly pasted into a prompt. Atlassian's blog post walks through a side-by-side example: two agents are given the same bug report. Both correctly guess the likely cause. The agent without Code Context stops at a plausible hypothesis. The one with Code Context finds a related repository not present on the developer's machine, confirms the actual root cause lives there instead, and — critically — cites a prior architectural decision (surfaced from Confluence or Jira, not the code itself) explaining why the fix belongs in that other service rather than the one open in the editor.

That's the real product claim: not "better autocomplete," but turning a plausible guess into a verified diagnosis by pulling in cross-repo dependencies and the organizational reasoning that produced them. It's a meaningfully different pitch from a pure code-search tool, because half the value is coming from Jira and Confluence, not the code index itself.

Versus the previous "Code Intelligence" branding, the practical change is scope and distribution: it now spans large-scale, multi-repo codebases rather than a single connected repo, and it's exposed through the CLI to agents Atlassian doesn't build, not just to Rovo's own agents.

Why developers should care

Token cost is a real line item now. With agentic coding tools billing by token consumption — GitHub replaced Premium Request Units with usage-based AI Credits on June 1, 2026, and Cursor's plans scale similarly — a credible 48% reduction in tokens-per-task, if it holds up outside Atlassian's own benchmark, is a budget line, not a vibe. Worth treating with the usual skepticism reserved for vendor-run internal benchmarks: nobody has published an independent replication yet.

It's a genuine bring-your-own-agent play, which is unusual for Atlassian. Most platform vendors want you inside their own agent (Rovo Dev, in this case). Exposing the graph to Cursor, Claude Code, and Codex via a CLI is a bet that context, not the agent runtime, is the moat — and it's the more defensible bet if you believe frontier models really have converged.

The IP exposure disclosure is unusually direct, and worth reading in full. From Atlassian's own support docs: "The Teamwork Graph CLI augments Atlassian coding agents (via the Rovo CLI) or third-party products (like Claude Code or Codex). If you use code context via the Teamwork Graph CLI with a third-party agent, your source code will be sent to those products and governed by their terms, which may expose proprietary code and IP. You're responsible for assessing the third-party providers['] security and suitability, for managing all their associated costs, API capacity, and agent actions." That's Atlassian explicitly declining to be the liability backstop for what happens to your code once a third-party agent has it. Reasonable and honest — the CLI is a pipe, not a walled garden — but it means the compliance conversation about Code Context can't stop at Atlassian's own SOC 2 posture. It has to extend to every agent your developers point the CLI at.

Lock-in runs through the graph, not the code index. The code-search half of this is replicable elsewhere. What isn't easily replicable is the Jira-ticket-plus-Confluence-doc-plus-Loom-clip context that makes Atlassian's pitch different from a pure code index — and that only exists if your team's actual work already lives in Atlassian's tools. If it doesn't, Code Context is a mediocre code search product wearing a much bigger product's branding.

Compliance gaps are specific and currently disqualifying for some teams. Code context is explicitly not available to HIPAA-enabled sites, and it currently supports only Bitbucket Cloud and GitHub Cloud — no GitLab, no self-hosted Bitbucket or GitHub Enterprise Server, at least not yet.

Practical use cases

Onboarding. New hire asks Rovo how order fulfillment actually works and gets an answer traced across the services that touch it, instead of pinging three people on Slack.
Cross-repo debugging. Support ticket references a symptom in service A; the actual bug lives in service B's shared library. Semantic search plus the Jira/Confluence layer surfaces that connection instead of leaving it to institutional memory.
Impact analysis before a change. A tech lead asks which services depend on an API before touching it — arguably more valuable than code generation itself, since it prevents work rather than accelerating it.
Agent grounding via the CLI. A team already standardized on Claude Code or Cursor keeps its editor but pipes Teamwork Graph context in before the agent plans a change, rather than switching tools to get better context.
Rovo Chat as a search replacement. For teams that already live in Jira, this may simply replace ad hoc grepping and Slack archaeology with a single chat interface — the lowest-friction use case and the easiest to evaluate in an afternoon.

What the marketing leaves out

Beyond the IP-exposure disclosure above, Atlassian's own support documentation lists limitations that don't appear anywhere in the launch blog post or press release:

Semantic search is not exact-match. Results are ranked by conceptual similarity; if you need a literal string or function name, you're expected to fall back to lexical search.
Freshness lags reality. Recently pushed code may not appear immediately while re-indexing catches up, and if a connected GitHub or Bitbucket instance has an outage, indexing pauses until the connection is restored.
AI answers are probabilistic, not guaranteed — Atlassian's own docs explicitly warn users to verify AI-generated answers before acting on them "in critical situations like incident response or security decisions." That's a reasonable disclaimer, but it's a direct hedge against the 44%-more-accurate headline number sitting one paragraph away in the same product's marketing.
No GitLab support, no self-hosted Git support, which quietly excludes a large share of regulated and infrastructure-heavy engineering orgs.
Not available to HIPAA-enabled sites at all — not throttled, not gated behind a higher tier, simply unavailable.
The rename from "Code Intelligence" to "Code Context" isn't disclosed as a rename anywhere except a single parenthetical in the support documentation. If you evaluated the earlier feature and passed, that context is easy to miss on a second look.

None of these are disqualifying on their own. Collectively, they're the difference between "context engine for your entire codebase" (the headline) and "beta-quality semantic search over two cloud SCMs, with a real IP-liability handoff the moment you point it at a third-party agent" (the more accurate one-line description).

Competitive comparison

The market Code Context is entering already has three players making a version of the same "context, not model quality, is what matters now" argument, and they've converged on genuinely different architectures for it:

Cursor builds its own local index of the checked-out repo and layers automatic plus manual (@codebase) retrieval on top, inside a VS Code fork it fully controls. It's fast and requires zero setup, but it's editor-scoped — cross-repo, org-wide context depends on what's checked out on that specific machine, and there's no shared index across a team's many repos.
Sourcegraph's Cody built its reputation on exactly the problem Code Context is now targeting: a code graph spanning "100 to 1M repositories" across GitHub, GitLab, Bitbucket, Gerrit, and Perforce, with governance features (allow/deny lists, SOC 2 Type II, ISO 27001, zero data retention) aimed squarely at security teams. The catch, and it's a significant one for anyone comparing the two products today: Sourcegraph discontinued Cody's individual Free and Pro tiers in July 2025, pointing solo users toward its newer agentic tool, Amp, instead. Cody Enterprise is still fully supported and remains the strongest option for teams on GitLab, Perforce, or self-hosted Git — none of which Code Context currently touches at all.
GitHub Copilot leans on @workspace and open-file context rather than a persistent cross-repo index. It's the lowest-friction option for teams already fully inside GitHub and Microsoft's ecosystem, with the deepest PR and code-review integration, but multiple independent comparisons published this year describe its large-codebase context as "good but not great" next to a fully indexed graph.

Code Context's actual differentiator against all three isn't the code index — Sourcegraph's is more mature and covers more SCMs today. It's that Code Context is the only one of the four bundling code with an org's Jira tickets, Confluence architecture docs, and Loom explainer clips in the same retrieval layer, natively, because Atlassian already owns all three products. Whether that's a decisive advantage depends entirely on whether your organization's actual "why we built it this way" record lives in Confluence and Jira, or scattered across Notion, Google Docs, and people's heads.

An independent read

Financial coverage of the launch has been notably unenthusiastic, which is a useful counterweight to the CTO quote in the press release. One analysis published two days after launch called Code Context "supportive rather than transformative for the near term" for Atlassian's business, arguing it reinforces the company's AI narrative without changing the underlying investment thesis — which now hinges on Atlassian's guided ~13% year-over-year revenue growth for fiscal 2027 converting into actual margin expansion, rather than just funding more R&D spend on features like this one. That's a fair framing to bring into a technical evaluation, too: this is a beta-stage feature from a company with a strong incentive to make "AI-native" claims land with investors, not just with the developers actually running code context queries at 2am chasing a cross-service bug. Weigh the 44%/48% numbers accordingly — they're internal, unaudited, and haven't been independently reproduced.

Who should try it, wait, or skip it

Try it now if you're already a Jira and Confluence shop on GitHub Cloud or Bitbucket Cloud, your team is experimenting with Claude Code, Cursor, or Codex, and you want to test whether piping Teamwork Graph context into those tools measurably changes output quality. The opt-in is admin-gated and reversible — indexing stops and deletes on disable — so the downside of a trial is bounded.

Wait if you're on GitHub Enterprise Server, self-hosted GitLab, or Bitbucket Server, since none of those are supported yet, or if you're a HIPAA-covered org, where the feature is simply not available. Also wait if your organization's real institutional knowledge lives outside Atlassian's product suite — you'll get a decent code search tool and none of the cross-signal advantage that's the actual pitch.

Skip it if your security team won't sign off on routing source code through a third-party agent's own terms of service the moment a developer runs the CLI against Claude Code or Cursor — that's not a hypothetical edge case, it's the documented default behavior of the feature as shipped. And if your codebase already lives in a mature Sourcegraph Cody Enterprise deployment spanning GitLab and Perforce, there's little reason to duplicate that investment with a narrower, newer beta.

The most interesting thing about this launch isn't the 44% number. It's that Atlassian shipped an unusually blunt admission, in its own documentation, that giving an AI agent your entire codebase's context also means deciding exactly which company's terms of service that code is now subject to — and that decision belongs to you, not the platform selling you the pipe.

Discussion: if you've piped an internal code index into a third-party coding agent via CLI or MCP, how did your security team actually scope the risk — per-repo allowlists, a separate low-sensitivity index, human review of every agent-initiated query, something else? What did the decision process for "yes, but only these repos" actually look like at your org?

Sources:

DEV Community