The SDLC You Build Yourself — Andy Wong, Andrei Bocan & Shane Wolf, Atlassian

A coding agent can produce a change while leaving the surrounding work untouched: deciding what to build, finding the relevant decisions, reviewing the result and operating it afterward. Andy Wong opens this Atlassian workshop with the judgment that gains from additional coding tools are tapering, making the work “left and right of code” an attractive place to improve the software development life cycle. Joined by Andrei Bocan and Shane Wolf, he introduces a set of agents connected through organizational context.

The Jira coding agent makes a work item the starting point. Its proposed advantage is access to the material surrounding that item: Jira tickets, Confluence documents, email and Slack messages. That material supplies requirements and background for planning and implementation, while the cloud experience lets a developer interact with the resulting pull request inside Jira.

Agent choice and triggering are separate decisions. A team can assign a Jira item to its preferred agent, with Claude, Cursor and Codex named as options, or use Jira automation to start code generation when a condition is met. The workflow therefore begins before an editor session: a work-management event can initiate implementation.

AI Reviewer is introduced with three jobs: catch bugs, enforce standards and verify requirements. Reviewing against requirements requires knowing what the change was meant to accomplish, so the intended review reaches beyond the diff into Jira, Confluence, source control and Slack. Centralized standards add another input: a team defines its rules once and applies them across relevant repositories, with GitHub, GitLab and Bitbucket Cloud named as supported platforms.

More comments can make that review less useful. Atlassian describes training models to filter low-value or overly nitpicky comments before they reach a pull request. What does the presented comparison say about whether the remaining comments get resolved? Wong reports a resolution rate of around 40%, against a human baseline of 45%. The recording does not define the evaluation population or resolution metric precisely, so this is a reported comparison about review comments, rather than a general measure of bug-detection accuracy.

The opening overview extends the same context-driven approach to two other kinds of work:

• AutoDev: examine a Jira backlog, identify work suitable for autonomous execution, apply relevant standards and produce pull requests for review. Repository scope, credit limits and per-user work limits control how much it takes on; dashboards distinguish runs waiting for requirements from those waiting for review.
• AI SRE: bring previous incidents, Jira and Confluence into incident diagnosis. The described Slack experience summarizes impact, proposes root-cause theories and suggests mitigation steps, including during the familiar 2:00 or 3:00 AM incident.

The shared dependency is the AI context engine: a way to retrieve relevant material scattered across repositories and documentation and make it available to agents. Semantic code search is part of that plan. Browser, IDE and CLI access are described as ways to bring these capabilities into existing work habits.

The intended hands-on session runs into persistent Wi-Fi trouble, turning much of the workshop into questions about the machinery underneath the products. The first substantial question is what the context engine actually connects.

Graph databases connect information from Jira, Confluence and Bitbucket, along with third-party sources such as Notion and Slack. Some relationships are inferred from product use; others are explicit. A Jira ticket based on a Confluence specification is the concrete example: the ticket and its specification become connected pieces of context rather than independent search results.

Agentic search operates over those connections to bring relevant information into a coding session. A change in one part of an organization may depend on another team’s platform documentation or an initiative elsewhere. Retrieval needs to discover those dependencies even when the developer’s immediate task does not name them.

Code search also offers an alternative to consolidating repositories just to give agents more context. A monorepo can make related code available together, but it brings tooling costs and potential slowdowns. The proposed code context engine lets separate product repositories “feel like monorepos” by retrieving code across them when needed. Direct access to implementation also helps distinguish current behavior from documentation that captured an earlier state.

Freshness and correctness remain separate problems. In response to a question about saving context, the explanation favors retrieving information on the fly over keeping a task-level snapshot that can become stale. Conflicting information needs another signal: a person can mark content as verified and give it higher weight. Automatically treating generated knowledge as authoritative risks allowing an agent’s own output to become the evidence for its next conclusion. Applying verification to Jira work items is described as possible but more manual.

The workshop workspace includes an Atlassian Swag starter repository in Bitbucket, but network and account-access problems continue to interrupt participation. Requirements verification becomes the next useful question: what does an agent check after it has written the code?

The expected input is a work item with an acceptance-criteria checklist. Once the Jira coding agent thinks implementation is complete, it checks those criteria. Its sandbox can install dependencies, run the repository and open a browser, provided the repository explains how to start the application and perform the verification. This makes repository instructions consequential: they connect a written requirement to an action the agent can actually carry out.

That execution happens in a proprietary, Atlassian-hosted container with Docker enabled. Bringing a separate sandbox is not supported in the answer given here. The environment can run repository tooling, but the hosting arrangement limits how a team can substitute its own execution infrastructure.

The billing discussion is less settled. The presenters describe both using your own API keys and usage through Atlassian credits, without clearly resolving how those arrangements fit together. They do confirm support for Claude and OpenAI models. Credit reporting is tentatively described as aggregated by user and product experience, with finer attribution still being developed; that limits how confidently a team can connect spending to an individual piece of completed work.

Model selection has a clearer division:

• Top-level choice: the user selects the model for the Jira coding agent’s harness—the environment that runs the agent and its tools.
• Skills and subagents: teams can customize skills and specify model choices for particular skills or subagents.
• Automatic routing: choosing a model from the task’s apparent difficulty is not available in the described release. Bocan presents it as work underway for AutoDev, with success metrics intended to help teams decide whether to adopt a routing policy.

Because participants cannot reliably use the environment during the session, the presenters agree to leave it available through the conference. They also make its intended use explicit: it is a shared workshop setup, so participants should enter only material they would be comfortable putting in a public snippet.

A question about fifteen or twenty years of accumulated documentation returns to source quality. Search tends to favor recent results, but an old document can still be the best description of an enduring rule. Confluence’s verified badge supplies that distinction: a person can confirm that an older document remains current and should be favored. Recency helps rank candidates; verification preserves useful exceptions.

Wong then demonstrates standards in the product, separately from the participant demo environment. The example is design token enforcement. He creates a standard, enters its name, description and rules, then selects its repository scope. How does a shared rule become applicable to only the right codebases? The interface offers manual repository selection or selection by a matching pattern, keeping the content of the rule separate from where it applies.

Once created, the standard becomes an input to pull-request review in those repositories. The agent checks whether a proposed change adheres to the specified rules and adds comments. This moves repeated enforcement work out of a reviewer’s memory and into a reusable review input. The demonstration establishes that setup and scoping workflow; it does not show the exact design-token rule text or a resulting violation being corrected.

Bocan describes AutoDev’s initial release as a way to reclaim engineering capacity from suitable backlog work. It selects items the agents are confident they can handle and puts up pull requests for people to review. The human review checks both whether the work was worth doing and whether the implementation follows the team’s standards. AutoDev is presented here as an initial-release plan and product direction, rather than a full live demonstration.

Standards create two different workloads. Review can check incoming code against a new rule. Bringing existing code into compliance requires finding old violations and changing them progressively. A single pull request that rewrites half the codebase is difficult to approve; fifty small pull requests a day can overwhelm the team just as effectively. Bocan gives three or five assigned pull requests per person per week as examples of a manageable configuration, rather than a universal target.

The longer-term example is an organization upgrading Rails across a hypothetical ten thousand similar services. Much of the implementation work repeats, so a coordinating team could direct agents to produce changes across services and retain lessons from earlier migrations. Humans would coordinate the initiative while agents perform more of the repeated implementation. This is the stated vision for organizational steering, including memory across runs, rather than a demonstrated migration result.

Keeping autonomous work visible in Jira lets people intervene when AutoDev chooses the wrong item or assigns the wrong reviewer. Two independent limits then constrain the stream: work-in-progress limits protect the team from excessive review demand, while spending limits constrain cost per ticket or per week. Limiting token expenditure alone would still allow the system to create more review work than the team can absorb.

Underspecified tickets require a different intervention. A backlog item that says only “Do the thing” may represent valuable work, but it does not tell the agent what success means. AutoDev should ask a person whether the work is wanted and help obtain a usable specification before proceeding. After implementation, the next human decision is review: accept the change, request more work or discard it. Slack is the planned initial channel for reaching reviewers, because unattended review queues are where autonomous work can stall.

Where does autonomous work pause for people? The diagram separates missing requirements from completed work awaiting review. Those pauses solve different problems: the first establishes what to build, while the second decides whether the result should land.

AI Planner addresses an earlier uncertainty: whether an idea is feasible in the current repository and what implementing it would require. The proposed input is an idea for a feature or a spike. The planner consults repository and organizational context, assesses feasibility and returns a breakdown with possible execution paths.

Wolf makes the retrieval problem concrete with Atlassian’s roughly 15,000 repositories. Questions such as “Where do I implement this change?” and “What services are using this other service?” first require finding the relevant part of the organization’s code. The context engine narrows the search space to likely locations, digs into that code and adds information from the Teamwork Graph.

Current code and historical documentation answer different questions:

• Current code: what exists and how it behaves today.
• Historical decisions: why an earlier implementation took its particular shape, including constraints and mistakes worth remembering.

An old document can be inaccurate as a description of today’s system while still explaining a decision that matters to the next change. Combining these sources gives planning more than a location to edit: it supplies reasons to preserve or revisit the existing design.

The integration is uneven at the time of the workshop. AI Planner and AutoDev use the context engine, while AI Reviewer uses it relatively little and is experimenting with deeper integration. That qualifies the broad review vision from the opening: access to richer organizational context is a direction being developed, rather than an equally mature capability across every agent.

Rovo Chat provides another entry point. The existing code-question experience uses connected search tools, including GitHub or Bitbucket search APIs; the newer code-context capability, described as early access with a few customers, adds a more cohesive view of current code and historical decisions. The Teamwork Graph CLI exposes code-context skills and search primitives to other agents, although the full agentic context engine is distinguished from those individual primitives.

An audience question exposes a consequential limit of standards: they are prose and Markdown interpreted by an agent. Can they become deterministic CI checks? Wong does not identify an out-of-the-box mapping. Writing a binary criterion in Markdown may make the instruction clearer, but the workshop does not establish that it produces a deterministic pass or fail. Teams needing a repeatable CI gate still have a separate requirement to satisfy.

The next question concerns dependency-aware waves of agents. Foundational work might need to finish before a larger set of tasks can begin. Wong describes a composition he had tried: ask the Jira coding agent to split an epic into smaller Jira tasks, then use automation rules to start coding-agent sessions for those tasks.

The discussion extends that idea to foundational, V0, V1 and V2 epics with further ticket refinement. This suggests a way to assemble a larger workflow from decomposition and automation, but it does not demonstrate a built-in scheduler that waits for dependencies and releases each wave. Automatic assignment is likewise placed primarily in Jira coding-agent automation; direct Rovo coordination is left uncertain, and AutoDev is suggested as another possible contributor.

The final questions clarify what “real time” means. Changes made inside a Jira coding-agent session, including its cloud VS Code instance, are reflected within that session. A developer’s separate IDE is a different instance. The answer establishes shared state inside the cloud session; it does not establish continuous standards feedback for every edit in a separate local editor.

Another participant asks how to express a complicated development environment. After clarifying that the question is about environment configuration rather than running the agents on premises, the presenters identify Docker as the mechanism. That connects back to the hosted sandbox: a usable agent environment needs both an environment definition and repository instructions for running the work.

The last exchange confirms recently added skills support in AI Reviewer. Alongside the earlier harness customization, repository-scoped standards and Jira automation, this supplies the practical meaning of an SDLC a team builds itself: configurable pieces that connect work selection, execution and review. Their usefulness still depends on specific inputs—clear requirements, runnable environments, trustworthy context—and enough human attention to decide what should merge.