Andrei Bocan is a software engineer whose work at Atlassian has included developer platforms and GraphQL schema evolution. A principal engineer on Compass, he has explored how teams can change shared APIs without disrupting their consumers. His public work also addresses autonomous development: choosing suitable backlog tasks and keeping generated changes within a team’s capacity to review them.
Building Compass and evolving its APIs
As a principal engineer on Compass, Andrei worked on a developer platform that brings software components, ownership, dependencies, and operational information together. Compass helps teams understand how their services fit into a larger software system, including who owns connected components and how those components are performing.
Building Compass from the ground up with GraphQL gave Andrei a concrete architectural problem: how to keep an API useful as the product and its consumers change. His work on evolving GraphQL schemas addresses consistent API design, compatibility rules, and processes for keeping independently developed services aligned. Compass also had to fit into Atlassian’s federated GraphQL gateway, where a shared schema connects multiple underlying services. Changes therefore had consequences beyond the team making them: existing consumers still needed to work as the API developed.
In their joint “Two GraphQLs” framework, Andrei and Andreas Marek distinguish frontend-first and structure-first schemas. The former organize APIs around interface needs; the latter organize them around domain models. Their distinction makes an architectural choice explicit, including its consequences for team responsibilities and breaking changes. A schema organized around domain structure can be particularly difficult to reorganize later.
Keeping autonomous development reviewable
Andrei also helped build the Rovo Dev CLI as part of the team behind its launch. The command-line coding agent can investigate a repository and access Jira, Confluence, and Compass through the Model Context Protocol (MCP). That connects the code an agent is changing with organizational context: the work described in tickets, supporting documentation, and information about software components.
In “The SDLC You Build Yourself,” presented with Andy Wong and Shane Wolf, Andrei discusses autonomous development that starts with backlog work and produces changes for human review. His contribution focuses on deciding which work an agent should attempt and how much work a team can absorb.
Andrei advocates selecting suitable tasks, limiting both spending and the volume of generated pull requests, and asking people to clarify underspecified tickets before an agent proceeds. These decisions address separate constraints: an agent can consume too much computing budget, create more changes than reviewers can assess, or implement a ticket whose requirements were never clear. Review capacity is therefore part of planning autonomous work, alongside the agent’s ability to produce an implementation.
Andy Wong, Andrei Bocan and Shane Wolf explain Atlassian’s approach to connecting Jira work, organizational context, repository standards and autonomous development—with human judgment at the points where requirements, evidence and review capacity matter.
The context engine combines connected organizational information with code search, so agents can retrieve relevant implementation and decisions across separate repositories.
Fresh retrieval, human verification and historical reasoning serve different purposes: staying current, choosing trusted sources and understanding why the code took its present shape.
Autonomous development needs separate controls for spending and human review capacity, plus explicit pauses for missing requirements and completed changes awaiting judgment.
Acceptance criteria become actionable when the agent also has a runnable environment and repository instructions that explain how to verify the result.