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

Read the talk

The SDLC You Build Yourself

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.

From a talk by Andy Wong, Andrei Bocan and Shane Wolf

At a glance

Ideas worth remembering

  • 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.

  • Repository-scoped prose standards can guide AI review, but the workshop does not establish a deterministic CI check generated from those standards.

  • 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.

Start with the work on either side of code

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.

0:131:30
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

0:13 · section reference included

Review needs requirements, standards and fewer low-value comments

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.

4:184:48
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

4:18 · section reference included

Connected context without moving everything into a monorepo

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.

11:0512:01
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

11:05 · section reference included

Verification needs acceptance criteria and a runnable environment

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.

21:5322:23
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

21:53 · section reference included

Create a standard, then choose where it applies

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.

35:0535:13
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

35:05 · section reference included

AutoDev must fit the team’s capacity to review

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.

Two human decisions around autonomous implementation

Assess backlog workIdentify work suitable for autonomous implementation.
Needs requirementshuman-input — Ask a person what the item means and whether it should be done.
Implement suitable workWork from a sufficient specification and produce a pull request.
Needs reviewhuman-input — Bring in a person to assess the change; Slack is the planned initial outreach channel.
Requirements determine whether implementation can proceed; review determines whether the completed change should be accepted.
Read the diagram as text
  • Assess backlog work. Identify work suitable for autonomous implementation.
  • Needs requirements. human-input — Ask a person what the item means and whether it should be done.
  • Implement suitable work. Work from a sufficient specification and produce a pull request.
  • Needs review. human-input — Bring in a person to assess the change; Slack is the planned initial outreach channel.
  • Assess backlog work → Needs requirements: Goals are underspecified.
  • Assess backlog work → Implement suitable work: Suitable work with sufficient requirements.
  • Needs requirements → Implement suitable work: A person supplies a sufficient specification.
  • Implement suitable work → Needs review: Pull request ready for a human decision.
38:3939:08
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

39:08 · section reference included

Use current code to locate the change, and history to understand it

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.

46:3047:00
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

46:30 · section reference included

Prose standards and epic decomposition leave orchestration decisions to the team

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.

51:3351:40
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

51:33 · section reference included

Real-time changes stay within the cloud session

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.

54:3554:58
Suggest correction

This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.

54:35 · section reference included

Read the complete timestamped transcript
  1. 0:13

    Welcome, everybody. Welcome to the AI Engineers World's Fair. Uh, thank you everyone for joining for our workshop today. Quick introduction for myself. My name is Andy Wong. I've been working at Atlassian for four years now, and I've been working in the AI space for two and a half. Joining me today are two of my wonderful teammates. We have Shane Wolf, uh, manager do-down in Dev AI space, as well as Andrei Bocan down here as well. So today we're just gonna go over a lot of the things how, how the agentic systems are kind of changing how we are, uh, handling

  2. 0:42

    the t-software development life cycle and how orchestration does change everything.

  3. 0:47

    And while Andy's talking, I'm gonna be running around handing out pieces of paper with a number on it. It's gonna seem weird. It'll make more sense when we get into workshop as, as all of us step on each other's toes.

  4. 0:59

    Loud for those in the back.

  5. 0:59

    Can you repeat?

  6. 1:01

    Yeah, he's, uh-- Shane is gonna walk around, give out-- hand out numbers. Uh, it's gonna be a little bit weird at the beginning, but once we finish up the, uh, introduction talk, we'll be-- it'll make a lot of more s-- a lot ma-make a lot more sense after, uh, after the kind of like the introduction talk kind of finalizes up. Um, but we just wanna quickly get started on the first intro slides. Um, I do want to run through these probably quickly because since it is the AI Engineers World Fair, we want to build. So I just wanna give a quick rundown of everything we're-- we've been kinda building at Atlassian for the last, I would say, one and a

  7. 1:30

    half years or so, uh, just to give you like a high-level overview of all the tools we will be offering you within Atlassian itself. So I think as, as you guys might know, uh, AI agents have kind of changed the software development life cycle, like drastically. Um, as time kinda goes on, you can kinda see that as we have more AI coding tools, kinda productivity gains from those tools are kinda tapering, um, as we have more and more tools coming out. And thus, us at Atlassian, we believe that what our biggest opportunities are tapping on

  8. 2:00

    the, on the everything left and right of code. So everything involving planning, orchestration, uh, the code review process, as well as the operations part. And so we've been developing a lot of the things that, um, what we can say like are not as apparent during the, uh, software development life cycle. Uh, we have things such as the teamwork graph coming out, as well as a bunch of different agents that we've been trying to do left to right of code, um, such as AI Planner, AI AutoDev, Reviewer, SRE. Um, and,

  9. 2:30

    and central of all that is something we call the AI context machine. Just to quickly run through all those tools, what we, we, what we will predominantly be testing out today is something called the Jira coding agent. Uh, that's our-- that's the Atlassian coding agent natively, uh, that has deep organizational knowledge within the Atlassian ecosystem. So it's g- it is a deep enterprise context agent that has, uh, a deep understanding of everything within the Atlassian ecosystem, whether or not you have Jira tickets, Confluence documents. Um, it will read through email, Slack, Slack, uh, Slack

  10. 3:01

    messages as well, um, to be able to gather all the context it needs to kind of plan out and implement a specific Jira ticket that you might have. Uh, within the Jira coding, coding agent itself, uh, you are able to, uh, interact with your pull requests within the Jira ecosystem itself. So you-- everything is, uh, everything you'll be able to maintain and edit within the cloud.

  11. 3:28

    Addition to that, you'll be a-be able to assign your work to specific agents directly. Uh, so if you don't wanna use your Jira coding agent, that's fine. What we do provide for you as well is you are able to assign to, uh, s-agents such as Claude, Cursor, Codex, whatever agent you personally prefer, uh, you are able to assign the Jira agent-- Jira ticket to, um, during, during that process as well. And finally, we also have SDLC automations. As you-- some of you might know, we do have an automation process

  12. 3:58

    within Jira itself. Uh, whenever there is a condition met, you are able to gener-- like you are able to generate code, uh, using a Jira coding agent or whatever agent you pr-des-- you personally decide to use.

  13. 4:18

    As we go further right through code, we do have the AI reviewer. Uh, something similar to-- kinda similar to a lot of tools you've seen in the pr-- uh, in, in the industry today. Uh, we are trying to implement, uh, a reviewer, a reviewer agent to kind of go over pu-pu-pull the pull requests to catch bugs, enforce standards, and verify requirements every time you do make a pull request itself. So the review do-does go beyond the code. Again, we are trying to build something that, uh, retrieves all the context within Jira, Confluence, whatever SCM you kinda use,

  14. 4:48

    as well as Slack, to, to develop like kind of like a holistic view of what your code PR needs to implement, um, and provide a review on that end.

  15. 4:59

    On top of that, we do have centralized ment-- uh, meant to manage standards. Um, every team, every organization kinda has their own standards that they wanna implement in each, uh, each repository. Um, again, it gets kinda tedious, and what we're trying to do with standards is trying to, trying to make it a lot easier for managers, software engineers to implement those standards in all, in all the pull requests that come with-within the specific rep-repository.

  16. 5:26

    And as-- And additionally, this will work on all SCM plat-platforms, whether or not it's GitHub, GitLab, Bitbucket Cloud, um, you will be able to apply standards to your, your pull requests.

  17. 5:39

    One thing we are trying to do at Atlassian with our AI reviewer is we're trying to reduce the amount of like h- s- the amount of noise that comes from the code review process as a whole. Uh, what we do find is that some of the code review processes, uh, do provide-- do ov-- are maybe a little bit overly nitpicky or like, you know, provide a little bit too many co-comments that are not of a high value. So we-- what we've been doing at Dev AI is we, uh, train a few models ourselves, filter those, and what we have done is use those models to filter out, uh, let's say low-value comments

  18. 6:09

    or like noise that we have deemed, uh, and try to f- and filter those like unneeded comments during the pull reque comments. Uh, sorry, the pull request comments itself. Um, as a whole, we have seen that there has been a higher quality, uh, comment resolution. As you can see at the bottom here, uh, using these models, we have been able to get around forty percent, uh, human code resolution rate, which is rather close to human baseline of forty-five.

  19. 6:33

    And as always, we can always measure and, you know, how... see how impactful all these tools are. Um, at Atlassian, we have been building a lot of like dashboards for our various tools to see how many reviews or how many co- like, uh, how many agents you've run, uh, to kinda give you an idea of what the value of all of our tools are, uh, within the dev AI space.

  20. 6:55

    Going on to a few, like the final few, few products we've been implementing recently, uh, something called AI AutoDev. Um, it's pretty self-explanatory what it can do. Uh, it goes through your Jira- J- Jira board, uh, identifies which, uh, which o- which tickets are, I would say, able to be able to be autonomously ran, um, applies all the standards, initiatives, um, then creates a pull request ready for review. Um, all of that is triggerable within the Jira ecosystem itself.

  21. 7:25

    Um, you can configure all, a bunch of different needs, such as maximum number of credits you wanna use per month, uh, maximum number of like pr- tickets you want per, per user to run AutoDev on. Um, and it's able... You can also specify which repos you wanna have this running on, or if you wanna run it on all repos within your Jira organization itself. And as always, we have a dashboard to show all the, uh, all the AutoDev runs, how it's kind of working, um, how n- how many AutoDev pu- pull requests are in need of review, and how many still re-

  22. 7:55

    need requirements. As always, we're trying to give you like as much, uh, metadata as possible for the engineers, for the teams to really understand like how, how AutoDev is overall performing for you.

  23. 8:08

    One other thing we do have AutoDev integrated on is Slack. So once you do have, uh, AutoDev integrated within a repository itself, um, it will start auto... working on a specific work items based on whether or not it's available, it's able to use, um, or if there's any items that you need to, uh, any input to finish them.

  24. 8:28

    More ROI insights. Um, as always, we'll, we will try to measure as much as possible, uh, to see how, what is the overall ROI that you are seeing from AutoDev as a whole. And finally, AI... Sorry. Uh, we've all been through incidents. We all understand how difficult it's to diagnose and kind of go through it, especially at like 2:00, 3:00 AM at night. Um, what AI SRE aims to do is try to grab all that context again, um, within previous incidents, Jira, Confluence,

  25. 8:58

    um, and try to root cause why an incident is happening, and provide suggestions of how to remedi- uh, remediate the specific, uh, specific incidents once they do come out.

  26. 9:09

    Again, it is integrated with Slack, uh, so you should be able to get a quick summary of what's going on, uh, understanding whether or not it's impacting multiple external customers, or if it's only impacting a small section of customers, and it will provide you, uh, detailed reason, detailed, uh, detailed steps of how to possibly mitigate the issue that you c- you are seeing. As you can see here, uh, it will provide, like, like I said, will provide root cause analysis. Um, it gives you a bunch of different theories of

  27. 9:39

    how to possibly remediate the issue as you g- as you see, as you see it coming.

  28. 9:44

    I've been saying a lot about context and how the context will be helpful for your agent itself. What we've been trying to build here is the AI context agent. Um, many of us have been working in large mono repos, and all that context is scattered within the, whether or not be different, different, uh, repositories itself or different pieces of documentation all throughout whatever, uh, w- all what- whatever workspace you kinda work in. What the AI context engine is aiming to do is try to g- grab all of that and create, you know, like a standardized context for you, uh,

  29. 10:14

    for all of your agents to kind of run in kind of like a more efficient way. Um, I know I've said context a lot. That's the biggest thing we're trying to do in Atlassian. We're trying to grab all the context as possible and trying to create, uh, a really powerful engine for us to pro- uh, power our agents in the future. Um, so as you can see here, AI context engine, all of our tools, Jira, Confluence, um, all of our previous instance, everything, uh, will be, will be run using co- semantic, semantic code search, and we will be able to provide all that context to whatever agent you kind of use in the future.

  30. 10:46

    What we're trying to do is also try make a lot of our tools like, uh, plug-in accessible. Uh, you know, so hopefully what we can do is, uh, uh, allow the, allow the engineer to simply just add the tool to their browser, to their, to their IDE or to their CLI, and allow them to use it out of box as simply as possible.

  31. 11:05

    As I said, I wanted to keep this really short 'cause again, we're at the AI Engineers World's Fair, we wanna build. So what we've gotta do here, what I do provide for you here is a small workshop for you to play around with Jira coding agent. Um, you might see Shane walking around with a specific number, uh, specific number, uh, and then hand it out, hand it out over to you. Um, that is going to be your account number. So let me just quickly go over here.

  32. 11:33

    How this will work is that that number will be tied to your login, and the login is the following.

  33. 12:01

    Apologies, some Wi-Fi issues.

  34. 12:10

    So it's not just me. All right. Got it.

  35. 12:21

    Going back to this, just so,

  36. 12:28

    just so everyone does have the QR code available to them.

  37. 13:01

    Yeah, yeah, yeah. Let's see.

  38. 13:04

    Yeah.

  39. 13:05

    Let's see. I will stop sharing my screen.

  40. 13:13

    Yeah, yeah, yeah. I'll do this.

  41. 13:21

    Okay.

  42. 13:24

    Yes.

  43. 13:28

    Not quite.

  44. 13:31

    Is the internet really slow? Let's see.

  45. 13:36

    Oh, the Wi-Fi is quite slow.

  46. 13:38

    Wait, did you connect to this?

  47. 13:39

    Hmm?

  48. 13:40

    You didn't 'cause you're like on a different, uh, Wi-Fi.

  49. 13:47

    Oh, there.

  50. 13:47

    This one?

  51. 13:50

    There we go.

  52. 13:56

    Hmm.

  53. 14:07

    Wow, that-

  54. 14:10

    Network has changed.

  55. 14:12

    Uh,

  56. 14:15

    do you still have Cloudflare on? Try, try turning it off. Oh.

  57. 14:20

    It's off. It is off. Let's see.

  58. 14:33

    How's it going?

  59. 14:35

    Can you guys repeat it as well?

  60. 14:36

    Yeah, we're trying to do right now. Yes.

  61. 14:38

    Yeah.

  62. 14:38

    Um, is there anything that turns down the Wi-Fi quality for like meetings and stuff?

  63. 14:43

    I have heard nothing about Wi-Fi or anything.

  64. 14:46

    Mm.

  65. 14:47

    So is it on the back of this?

  66. 14:50

    No.

  67. 14:50

    Yep.

  68. 14:51

    That Wi-Fi.

  69. 14:51

    That one.

  70. 14:52

    Yeah, yeah. That's the Wi-Fi.

  71. 14:54

    It's never good.

  72. 14:55

    10 years ago.

  73. 15:00

    Well, the thing is, is that it is whoever

  74. 15:07

    Mm.

  75. 15:12

    We have to decide.

  76. 15:14

    Is, is that not working then?

  77. 15:15

    Yeah.

  78. 15:15

    Yeah, it's not working.

  79. 15:17

    Yeah, my only suggest using a hotspot.

  80. 15:21

    Okay, gotcha.

  81. 15:23

    Now do you wanna try yours?

  82. 15:24

    Yeah, I'm gonna try mine.

  83. 15:28

    Yeah. Sorry.

  84. 15:31

    Just make sure when you get back up, you know, again-

  85. 15:34

    Mm-hmm

  86. 15:34

    ... I realize what you're doing so they don't see everything.

  87. 15:36

    Got it.

  88. 15:37

    I understand.

  89. 15:38

    Yeah.

  90. 15:39

    Have any questions that we can talk through while we're figuring out Wi-Fi?

  91. 15:49

    Oh.

  92. 15:52

    Fair, but also, like, um-

  93. 15:54

    Or stand right in front.

  94. 15:57

    Stand-

  95. 15:57

    The light in front

  96. 15:57

    ... right here. Okay. So while we're figuring out Wi-Fi, as I was saying, anybody have any questions that we can talk through in terms of, I don't know, where we're thinking of going with like the, the product line, what stuff's available, what stuff people are keen on, workflows, so on? Uh, happy to go through any of that.

  97. 16:16

    Context engine.

  98. 16:16

    Sorry, go for it.

  99. 16:19

    Tell us a little bit more about the context engine.

  100. 16:20

    Tell us a bit more about the context engine. Okay. So essentially with the context engine, so, um, we have a number of, I guess, graph databases inside of Atlassian that connect to all of the data that you end up plugging into an Atla- uh, into your Atlassian products as an Atlassian customer. So like Confluence, um, Jira, Bitbucket, all of that stuff is sort of connected together. We ma- in... make those connections either

  101. 16:50

    through inferences as you use the product, or you can, like, have the connections be explicit. So like you're working on a Jira ticket, the Jira ticket is based off of like some spec document that is in Confluence. We also link those to like third-party, um, um... What you might call a third-party product. So like we will integrate with things like Notion, we'll integrate with things like Slack. All of that stuff kind of wraps into this whole tapestry of context, and at the end of the day, the thing that we're, uh, we're building now is...

  102. 17:20

    How do I word this? Uh, so it's, it's agentic search on top of all of, all of that context. And as you're... This happens a lot, like internally in Atlassian. Like we end up building on one side of the app, uh, on one side of the ecosystem in our platform, and that needs to pull in context from either some other team, like some platform documentation, where you have, uh, some other initiative that's happening on the other side of the organization that somehow happens to impact this bit

  103. 17:50

    of what you're building on. And through the context engine, all of that stuff gets pulled into, um, your current agentic coding session. Like that is the stuff that Shane, who's currently working on Wi-Fi. So connectivity basically is his through line. Um, that, that's the stuff that's, that he's team's, he, his team's working on. The things that I think we've had a lot of success with, um, has been, uh... So we have a new

  104. 18:20

    code search product that we're, um, we're launching. Um, that's made it so that, uh, I think historically we've, uh, we've seen a lot of teams try to do, like opt for monorepos in order to like have all their, their agents like have the context available at all times. That has some shortcomings and like means building out like a bunch of tooling. Uh, stuff gets slow. I don't know. Internally it's been- The, the proc-- opting for a monorepo ends

  105. 18:50

    up meaning that you're opting for the debt of having a monorepo, building the tooling around it. You spend a lot of time building tooling to build a thing. Um, and I think with, uh, with the code context engine, we've been able to, like, just have

  106. 19:05

    product repos feel like monorepos because you can pull in that engine ad hoc. It's super fast. Like, you get code level, um, code level access, and that means that any logic that you have that would otherwise be potentially stale, right? So like Confluence document is just a snapshot of a thing that happens once, but, like, the truth is in the code. Being able to, like, access that at high throughput and, like, having, uh, good search semantics around it is been really useful. Sorry, that was, like, very soapboxy. Does that-- did that answer your question? Okay, cool.

  107. 19:38

    Anything else?

  108. 19:41

    Please.

  109. 19:42

    Yeah. I have two follow-up questions about the context engine. So do you-- for example, if you have a Jira task, do you build the context and save it, or you build-- always rebuild the context on fly with one context? Another thing is, like, you get information from everywhere, right? But the information may conflict with each other. Is there a way you can manage these logs and find this right one and go back and fix it?

  110. 20:09

    Uh, so so I'll, I'll restate the question. So the first question was, uh, if we generate the context on the fly. Sorry, what was the second one?

  111. 20:17

    The second one is do you make it conflict information?

  112. 20:20

    Oh, how do we resolve conflicts, right? 'Cause, like, yes. Okay. That's great. Uh, and I think there's gonna be probably a bunch of talks at the conference about, about memory, and I think, uh, that's kind of one of the, the, the hotspots of, like, agentic memory. Like, you have a-agents that derive knowledge from, like, a bunch of different sources, but, like, at the end of the day, you need a human to tell, like, yes, this is actually true. This thing is, like, eh, incidentally true, or, like, it's true for, like, this specific case. Okay. Um, in terms of deriving the information, um, it's, uh, usually gonna be, uh, we don't snapshot it to some

  113. 20:50

    extent because of that. Like, I think the, the value of this ends up being that you have the information on the fly. It's available. Like, it's the latest, uh, latest and greatest. Um, if you have it-- if you cache it, then, like, it risks being stale, and, like, there's all this complexity around it. In terms of, um, what...

  114. 21:09

    The, the way that we've, we've historically dealt with, um, authoritativeness, I guess, for lack of a better word, um, has been to provide that as a, uh, as a feature for, like, the hu- the, the human in the loop to, like, be able to say, like, "Yes, cool. This is verified. This has higher authority than this other piece of content." Um, that's harder to do with things like, I don't know, Jira work items. I think Jira work items in general, you can do it, but it's just more manual work, and, like, the risk by automating that stuff is, like, oh, you end

  115. 21:39

    up, like, having things automated, uh, um, au- automatically end up being auth-authoritative, which is weird 'cause you can end up in that, in that same situation. All right. Are we internetted?

  116. 21:52

    I think so.

  117. 21:53

    Okay, cool.

  118. 21:53

    I think we should be internetted now, yeah. So the pa-- I think the page is, like, hopefully working for everyone now. Again, I'm gonna put the, uh, I'm gonna put the go link plus the, uh, QR code back up right now. Um, but just to clarify really quickly, everyone should have a number, um, and that will be your login. Uh, so we will be using something called, like, Atlassian University. So whatever number you have, it should be student inclu- and then the number of whatever number that, like, Shane provided you earlier. Um, that will be your login. Uh, that will be your login to test out the Jira coding agent,

  119. 22:23

    um, and kind of just play around with it within the Jira ecosystem itself. Uh, so please go to, uh... So, uh, from that Confluence page, you should have the link to our, uh, to our kind of, like, test Jira, Jira workspace. Um, as what-- And from that, you can kind of just, like, build whatever you kind of like. Um, we do have a starter repository for you guys. Um, uh, it's called, like, Atlassian Swag within Bibuck- Bitbucket itself. Um, I can show that in a little bit, but please feel free to, like, once everyone logs in,

  120. 22:53

    uh, start playing around with it and pla... start playing around with the agents directly.

  121. 22:58

    Are you using another network for Wi-Fi? Because it's-

  122. 23:02

    Oh, the we-- the network is still not working.

  123. 23:08

    Oh, you, you... Are you on the same network?

  124. 23:10

    I'm on the same network, yeah. Should be on the same. They take a little bit of time. They take a little bit of time to load. Yeah. We, we... Yeah, yeah.

  125. 23:19

    Yeah, yeah, yeah.

  126. 23:22

    I think we've been... We, we talked with the, uh, the IT folks here and to see if we can, uh, see if there is any, any resolution on that space. I, I do apologize for that.

  127. 23:36

    Yes, I can put up the QR code again.

  128. 23:40

    Yeah, no worries.

  129. 23:42

    Uh, numbers, numbers, numbers. Yeah, sorry. Let me... Did Shane go away with the numbers?

  130. 23:46

    Pardon?

  131. 23:47

    Uh, where's Shane's numbers cup?

  132. 23:49

    Oh, Shane's number cup.

  133. 23:54

    Good question.

  134. 23:58

    One second.

  135. 24:02

    Need more numbers for the numbers cup.

  136. 24:10

    Okay,

  137. 24:18

    okay. The best of numbers. I think that's prime. Maybe.

  138. 24:26

    Some of us are still unable to connect to the Wi-Fi.

  139. 24:28

    I don't think anybody's able to connect to the Wi-Fi.

  140. 24:30

    Yeah, yeah, yeah.

  141. 24:30

    I think that was, like, the, the, the great unsolved problem of, uh, twenty twenty-six, and I think if, if anything's gonna save us from, uh,

  142. 24:39

    AGI, it's gonna be the Wi-Fi. Or if they fix it, then we don't need saving, so we're good.

  143. 24:47

    Uh-

  144. 24:52

    It's just you gotta, you gotta tier the traffic, you know? You gotta optimize it.

  145. 24:55

    Mm-hmm.

  146. 24:55

    Uh, okay. Until we figure out the Wi-Fi, any other questions that I... Oh, please go for it.

  147. 25:02

    Yeah. Can you talk a little bit about the verification requirements aspect of this?

  148. 25:08

    Verification requirements. Okay. Sorry. So the question was like, can we talk a little bit about the verification of requirements aspect? Um, essentially that, that boils down to, uh, when we have, like, a specific work item that, uh, the Jira coding agents work-- agent works on, that goes through and, um, like, the Jira coding, uh, the-- we expect the work item to have a checklist of, hey, these are the, these are the acceptance criteria, and as the Jira coding agent, uh, generates the code for

  149. 25:38

    that particular task, it'll go in and, like, verify those specific things once it thinks it's done. Um, given that it has, like, a... The way that the Jira coding agent runs is, like, it has a full sandbox. It can install things. It can run things. It can do whatever the, whatever it is with that specific repository. So as long as you have the instructions in the repository in, in terms of, oh, this is how you run this, it can pop open a browser and then, like, go and, like, run that, uh, those verification steps.

  150. 26:04

    What is the sandbox?

  151. 26:06

    Uh, what is the sandbox?

  152. 26:08

    Where, where is it? Is it, like, hosted on-

  153. 26:10

    Yeah.

  154. 26:10

    -Atlassian?

  155. 26:10

    Yeah. Yep. Uh-

  156. 26:13

    Or is it something that we can bring in?

  157. 26:16

    We don't have that ability yet, so it's like it's a, it's a, it's a proprietary Atlassian sandbox. Uh, it's... Again, it's a container, so you can mostly run, like, whatever it is that you want. Like, it has Docker enabled and, like, the rest of the stuff. Yeah, go for it.

  158. 26:28

    Just related to billing and that type of thing-

  159. 26:29

    Yep, yep.

  160. 26:29

    Obviously, it's, it's bring your own key, it sounds like. And some... If you wanted to, all of these agents could use your API keys with, with, uh, Anthropic and OpenAI, or are they all internally hosted models? What's the-

  161. 26:43

    Uh, right now you can use, uh... So the billing is through Atlassian credits currently. Shane, am I wrong?

  162. 26:52

    No. It uses an API key.

  163. 26:53

    Yeah.

  164. 26:53

    So it uses your own API keys.

  165. 26:55

    So there's-

  166. 26:55

    Every, every one of these agents can be pointed off Anthropic or pointed off wherever. Okay. But they don't need to be.

  167. 27:02

    Yeah. The Jira coding agent supports, like, multiple... Uh, I think right now we have, uh, all the Anthropic models, all the OpenAI models, and, uh, I think that's it. Do we have Gemini as well? I don't remember.

  168. 27:13

    I think we can guarantee both the Claude and the OpenAI models.

  169. 27:16

    Uh, and, and it's, and it's as you said, it's per use. It's token usage.

  170. 27:20

    Yeah. Yeah. Yeah. It's credits.

  171. 27:22

    It's credits.

  172. 27:22

    It's slightly different, but like, yeah, same, same thing. It's like a pay-as-you-go.

  173. 27:25

    Subscription. Then-

  174. 27:26

    Hmm?

  175. 27:27

    Like, a per head subscription. And then on, on top of that usage.

  176. 27:30

    There's usage. Yeah. Yep.

  177. 27:32

    And is this all available now?

  178. 27:33

    Sorry?

  179. 27:34

    Is this all available now?

  180. 27:35

    Uh, Jira coding agent? Yes. It's out now. It's been out for, for a hot minute.

  181. 27:40

    Okay.

  182. 27:40

    Yeah, go for it, sir.

  183. 27:41

    So, uh, you mentioned in the slide like credits, like usage credit, like for the developer. Like, uh, like at the end of the month in terms of from a reporting accounting perspective, like do you need to report like where you spend this credit for and what, uh, kind of, uh, work that you have done, or it's just one, some ad hoc, uh, reporting that-

  184. 28:03

    Uh, the... If I recall correctly, and I may be wrong, I nee-- Well, I might need to follow up. Sorry. The question was, uh, how do we do, uh, credit reporting at the end of the month given that there's like multiple experiences that-- where people could u- be using AI credits for, right? Um, if I recall correctly, the way that that gets, that gets split, split out by product. So, like, specific user has used a JCA with like this specific, in this specific experience. Sorry, JCA being Jira coding agent, right? In this specific experience and like it, uh, that's kind of the, the

  185. 28:33

    level of, um, uh, detail you get right now.

  186. 28:37

    It's more like aggregating, not like a test base like-

  187. 28:41

    Yeah. No, no, not yet. Um, that is something that we're working on because at the end of the day, I think the thing that like will, uh... it's, it's kind of becoming apparent is, as, uh, we have, like, more and more people using, uh, uh, agentic coding, uh, you want to make sure that, like, the ROI is there. That like people... When somebody is working on something and is gonna, gonna spend like, I don't know, uh, one billion tokens on a thing, then you wanna make sure that, like, that is something that you actually want to have done as opposed to like somebody's OpenClaus running somewhere off in the, uh, in the

  188. 29:11

    periphery.

  189. 29:18

    Uh, sorry. So like what's the latest and greatest on the Wi-Fi?

  190. 29:31

    That's the latest.

  191. 29:33

    Uh, any other questions while AGI is coming? Yeah, sir. Go for it.

  192. 29:41

    Whoa. Sorry.

  193. 29:44

    Uh, login. Andy. There we go. Right, right here. So there should be a link. You can just like type this out yourself. Uh, one dash atlas dash dvao dot atlassian dot net. Um, with your, with your number. Uh, your login will be student, your number at Atlassian dot university. And the password is right here, uh, [REDACTED].

  194. 30:07

    On the academy, we're gonna get it wiped at the end of the, um, at the end of the session. So, like, if it's open-

  195. 30:12

    Yes. Some questions.

  196. 30:13

    It doesn't really matter.

  197. 30:14

    Doesn't matter? Okay.

  198. 30:15

    Yeah.

  199. 30:15

    Thank you.

  200. 30:16

    No worries, sir.

  201. 30:19

    I got you. There's no-

  202. 30:21

    Okay. To start it with some prompts.

  203. 30:25

    So let me see really quickly. Let me come down. Yes. Oh, man. Oh, God. I can't... Number. Can you go to Made With You? Made for You. Sorry. Made for You.

  204. 30:42

    Made With You here.

  205. 30:44

    Made for You. Yes. Oh, there it is. Oh, there's...

  206. 30:49

    It says go to software development.

  207. 30:51

    Mm-hmm.

  208. 30:51

    This is the closest-

  209. 30:52

    Oh, God.

  210. 30:53

    But there's no agent.

  211. 30:54

    God, one second, please. What is-- Which num-- What is your number? Ninety-five. Give it a second.

  212. 31:12

    Yes.

  213. 31:13

    Just related to model selection.

  214. 31:15

    Mm-hmm. Yep.

  215. 31:15

    Uh, is it smart about distributing this particular task? So people could go to Haiku, this task could be for Opus. How does it deal with model routing?

  216. 31:26

    That's a great question, actually. So I think right now, um, Andrei, could you-- Actually, I think you have a little bit more here.

  217. 31:32

    Uh, sorry, the, the question was, uh, whether we do anything smart about model routing. So right off the bat with, uh, the Jira coding agent currently, I think we let you select which model, like you want to route to.

  218. 31:45

    Relating to all the time.

  219. 31:46

    Yes, but I think that's the, uh-- You can also with, uh, um, sub agents and skills, you can k- decide like, oh, this particular, uh, skill needs to use like so and so agent. I don't think we do anyth- uh, sorry, so and so model. Uh, we currently don't have anything out, uh, that would do-- be doing like doing smart routing. That is something that we're working on with, uh, in, in auto dev to help you essentially figure out like, oh, this specific task. This is a Haiku level. We've seen success with it, and, like give you the metrics in order to

  220. 32:16

    be, to be able to like have that decision and ma-make sure that that's a policy that you want to enforce or not.

  221. 32:20

    Can I just follow up on that?

  222. 32:22

    Please.

  223. 32:22

    Just stacking items or uh, stacking then in terms of like you've got your agents, then you've got your skills. Can we define the agents or are those agents preset by you, and then we define the skills that they might auto select based on the prompt or maybe, you know, by the, by the second.

  224. 32:39

    Gotcha.

  225. 32:39

    How does that stacking work in terms of our customization with your kind of preset?

  226. 32:44

    Uh, the skills are basically up to you. Like, we have like a bunch of, a bunch of skills, but, uh, sp- specifically for the Jira coding agent, there's a, um, bifurcation to some extent between like Rovo and Rovo Dev-

  227. 32:57

    Try a different login, I think. So make sure

  228. 32:59

    ... uh, it's, as, as they were called previously. Um, and with the Jira coding agent, that's essentially we, uh, give you a harness, and there's a model selection at the top level of the harness, and then with the skills you can figure out like, all right, cool, like this is for this specific task, uh, for this specific skill, I want this model, this sub-agent needs to be using blah, blah, and blah.

  229. 33:19

    So will it depend on auto selection of those skills as needed to then direct your needs at that point when I'm doing .

  230. 33:28

    Yeah. Yeah. And that is up to, up to the-

  231. 33:32

    That's

  232. 33:42

    where we can model the correct-

  233. 33:42

    Yeah

  234. 33:42

    ... skill level.

  235. 33:43

    Oh, we're still doing Wi-Fi?

  236. 33:44

    Mm-hmm.

  237. 33:45

    Oh. Uh, okay. While we're still doing Wi-Fi, please.

  238. 33:52

    Can you keep the demo site

  239. 33:55

    open for a while so we can .

  240. 33:56

    Yeah. Yeah. That's probably what we're gonna do. Uh, sorry, the question was like, can we keep the demo site open for a hot minute so that like when people actually get to Wi-Fi, they can ac-actually go through it? And yes, I think that's a, that's a reasonable ask. Thank you. Um-

  241. 34:10

    How long will this be open?

  242. 34:13

    We can keep it open for as long as we really want. I think maybe for-- maybe I think like for the duration of AI, we're at, AI Engineering Fair.

  243. 34:19

    Yeah, that seems reasonable.

  244. 34:20

    Uh, we'll keep the, we'll keep the workshop open, and so when we do have Wi-Fi, I do apologize for the Wi-Fi issues. You can kinda like play around with it for yourself and kind of like play around with the different tools we, uh, we will-- we do have.

  245. 34:30

    Uh, one thing to sort of keep in mind as you're like inputting stuff onto these sites, as you can tell, the logins are like very secure. So like don't put in anything that you wouldn't be comfortable putting on a GitHub gist somewhere or like on a, a Bitbucket snippet. So yeah, uh, keep that in mind as you're kind of adding stuff to and, and messing around with all, all these things. Um, all right. Any other questions that we can go into?

  246. 35:00

    Please, sir.

  247. 35:05

    What's the importance of cleaning up stale context in Jira?

  248. 35:07

    What's the importance of cleaning up stale context? Interesting. Can you say more? Like what do you, what do you mean?

  249. 35:13

    Uh, I have an organization that's been using Atlassian for, you know, fifteen, twenty years. There's tons of product documentation which is no longer relevant to the product. How much is that-

  250. 35:23

    Out of all the things

  251. 35:26

    It's a good-- Okay, sorry. So like the... Good question. Um, the, the, the question essentially is like you have a large organization that's been using Atlassian for like ten, fifteen years, um, how important is it to like prune some of that stuff so that like it doesn't, uh, end up showing in search results or like the agent doesn't end up picking it up while it's looking for random stuff to give you an answer to the question? Uh,

  252. 35:47

    uh, our experience has mostly been okay with this by, in, in large part because we tend to favor like more recent results. Uh, I think that's where authoritativeness sort of comes in, where like if you have something that's been around for ten years and it's still like the whatever, tip of the spear is like that document from ten years ago, um, those, uh, I think we currently shipped a thing in, uh, well, shipped a thing a while back in, in, um, Confluence, that's the verified badge. Like that's basically the thing that we use internally to say like, "Yes, cool. This is like still the latest and

  253. 36:17

    greatest, and that this content sh- context should be favored, uh, across others."

  254. 36:28

    Normally, too, like for the United States, there's typically a

  255. 36:42

    Hello? Okay, awesome. I think we've had a few questions about standards. Uh, unfortunately, the standards aren't built into the demo itself. Uh, but I do wanna take a little bit of time just to like show you how standards kinda work within, uh, the Rovo Dev product itself, uh, and kinda, kinda like how we would be assigning standards overall, uh, to your specific repositories itself. Um, so just a quick demo here. Uh, so this is the standards page. Uh, we have a few built in already, but what I wanna show you right now is like, you know, how to create your own standards. Um, there's also a bunch of different templates you are able to

  256. 37:12

    select. Uh, but what I wanna do is just create a new one, uh, new standard. Uh, give a quick d- description of how, what the standard really is. Uh, so, so this one would be design token enforcement. So if we go to standard, standard name, go to d- call it design token enforcement, uh, add the description itself and add the rules. So after you add the standard

  257. 37:39

    and the rules itself, you can specify which repositories you want these standards to be applied to. Uh, you can select manually all the repositories or repositories matching a pattern. Um, so as these repositories load, you can decide, okay, let's apply to these following repositories, and then a- after every- all that is set up, you can just create your standard. Um, like I said, within software we have our own standards. Um, instead of trying to enforce it, uh, manually trying

  258. 38:09

    to, like, enforce that within the PR process itself, what we can do is we can set up the standard, set up to- set up which, which repositories you want the standard to, uh, be enforced on, and d- RovoDev Jira co- like the coding agent itself will be running through the pull request process and adding those, uh, adding comments to see if those pu- if your pull request is a-adhering to all the standards that, um, are kind of specified within the standard itself. Um, a few other things I did want to demo, uh, something called AI Planner as

  259. 38:39

    well as, like, AutoDev. Um, we can't give a full-fledged demo, but we do ha- what we do wanna iterate that, like, you know, we're trying to go from the left of right of code, and I would say le- like AI Planner and AutoDev are more on the left of code. So, um, I don't know if we have a full demo, but I can kind of talk about it with the, uh, slideshow itself.

  260. 39:08

    So we're gonna get start of, uh, AutoDev. Actually, Andrei, uh, you've been working on AutoDev pretty heavily. Can you kinda like give us a g- uh, brief, uh, brief overview of what the main goals you wanna accomplish with AutoDev, um, and kind of, kind of works as he sets up his mic.

  261. 39:23

    Sorry. I'm trying to figure out how the mics work.

  262. 39:26

    You aren't supposed to touch it.

  263. 39:29

    I'm not supposed to touch it? Oh, there we go. Oh, no.

  264. 39:31

    There we go.

  265. 39:31

    Thank you. Um, all right. Sorry, let me... I'll just be here then. Um, okay. So for, for AutoDev, the-- this is essentially our foray into like the AI SDLC orchestration space. Um, the thought process is to basically get you back some capacity from all the... in order to let your engineering team focus on feature work. Like the, uh, AI, the, for AutoDev, we, the initial, um, the initial release

  266. 40:01

    is gonna focus on grabbing work items from your backlog and grabbing the ones that we feel confident that, uh, the agents can handle autonomously, and then just putting up PRs for your team to review in order to make sure that, like, we're working on the right things, that we're abiding by the right standards, and then sort of iterating on your harness as well so that we can get code bases agent ready in a fairly light touch way. Um, do you wanna... Oh, sorry. Do you wanna... Okay. And this, this essentially kind of goes

  267. 40:31

    where, uh, uh, establishes where, where we're trying to go. So, um, we, we-- right now, again, the definition is gonna be like we will, we will grab your backlog, and then we will allow it to also help us identify which specific things you think Auto-- you would like AutoDev to, to grab. Um, we have some, some thoughts around like where we would like to-- this to go next. So there's standards enforcement, um, and I think Andy's gonna ta- probably talk about this in the context of the

  268. 41:01

    review. So the way that we think about that is, I don't know, standards are to some extent pretty similar to linting to some degree, but they're a lot more, uh, loose, uh, when you have the, uh, agents, uh, enforce them. We have one part of the, I guess, the, the, the linking workflow in forward-looking things in the reviewer, right? Like you add standards to code reviewer, and that takes care of any code that will end up landing in your code base going forward.

  269. 41:31

    Uh, we have a workflow for AutoDev where we would be able to scan existing part, like your existing code base, and then figure out how we land, uh, PRs progressively in order to get all of your existing stuff into compliance. There's some complexity there in terms of like, so nobody's gonna approve a PR that's like change half your code base because now you have a new standards. Uh, you know, or nobody's gonna approve anything that like causes like a high amount of churn. So with AutoDev, we wanna be mindful of how much work we're actually hoisting on your team. Uh, nobody wants to spend time reviewing,

  270. 42:02

    uh, fifty PRs a day. So like we have configuration for letting you say, "Cool, like my team wants to get assigned," I don't know, each individual gets assigned three, five PRs a week, and like those are the things. So that makes-- helps you get like incremental progress and also frees up your team to actually do the feature work that they, uh, they actually wanna do and like may move forward your, uh, uh, other initiatives. Um, and then, yeah, that kinda goes into like both initiatives as well. I think the, the space there is, I kinda think about

  271. 42:32

    it as organizational steering. So this happens a lot in, uh, bigger organizations where you have, I don't know, everybody's trying to move from whatever, some version of Rails to a different version of Rails, and it's a big thing, and we have like ten thousand services and like those are pretty similar. Uh, and some of the learnings, some of the memory, some of the workflows that you go through are fairly, uh, samey. So you would want something that is concentrated on one team, and they're just like spinning up PRs and like the agents essentially do the, do the work, and then you only have a human

  272. 43:02

    do the coordination, and then we also tie the loop around that with, uh, some sort of memory. Sorry. So again, that's, that's sort of the vision. That, that's where we see this going, and that's where like we see th-this being beneficial to our workflows because large organization, bunch of services, that's where we spend a bunch of time that like we would like to not have engineers be involved in that deeply, and we see agents as like a really big opportunity to, to move that ball forward. I think you can- Grab onto... Okay. Um, this is the other thing. Uh, if, uh,

  273. 43:32

    AutoDev is doing work, uh, on your team's behalf autonomously, you kinda ma- wanna make sure that, like, you are aware of, like, what it's doing, and want it to be, are able to interject when you want to... When it's either picking up the wrong thing, or, like, it's not assigning the wrong per, uh, the right person, and we will learn from that experience. And, uh, the reason why we want that to be in your Jira board is because that's the thing that most people stare at, like it or not, when they're trying to, like, figure out what's the next thing to, to work on. Um, and we were talking about this before. Uh, just

  274. 44:01

    the, um, the, the work in progress limit is the thing that we were, uh, that I was mentioning, where you want to make sure that, like, your team isn't getting, getting in- inundated with PRs or, like, other works that might not be necessarily the work that you wanna drive forward. Um, the other thing that we- we are also thinking through is, um, limiting cost, which I think is very much, uh, in the zeitgeist now. Like, you don't really want agents running roughshod. Like, if you, once you spin up a, a stream of work for AutoDev, you wanna be able to set

  275. 44:32

    limits for how much we wanna spend per ticket, how much we wanna spend per week. All that stuff seems like it's, uh, just table stakes at this point. Um, yeah, this is essent- like, the... Whenever we, whenever AutoDev sta- starts working on stuff, we will, um, give you, like, this, this broad overview. We're like, "All right, how much, how many things needs, uh..." Oh, man, I f- I forgot to mention this. Okay. Need requirements. Ah. Uh, for whenever we trawl through backlogs, there's, um, a very

  276. 45:02

    high likelihood that we have work items that are in your backlog that don't have, that are underspecified. Like, there's a thing that somebody put in, like, that has just one summary line that says, "Do the thing." Um, those can be valuable, but we don't know and we don't have the confidence that we can work on them because we don't know exactly what the goals of them are. And that's where, like, we will pull it a, pull in a human into the loop and say, "Hey, we have this work item. What is... What actually is this thing? Do we want it to work on it? Then can you help me specify it?" And then once we get to a li- a good level

  277. 45:32

    of specification, that's when, like, we can get to actually working on it. And that's where, again, needs review, is when we pull in a, a human to, to actually do the review. Um, the other bit that we've also noticed with some of these autonomous workflows is the, the, the reviewing step is where s- things go to die, um, because people, again, are, uh, busy with other things. Um, and that's one of the systems that we're putting together in order to reach out to people at the opportune time in order to pull them in and go like, "Hey, can you, like, take an

  278. 46:02

    i- take a look at this real quick, and, like, figure out whether, um, whether it's good to merge or, like, it's, it needs to go away?" And the, the chief vehicle for that is gonna be Slack for, for the, the initial release of AutoDev. Um, and then again, we were talking about this, the ROI insights. You making sure that, like, you're getting, um, you- you're not overpaying for the amount of work that we're doing, and that it's work that you actually wanna get done, and being able to, like, sort of push the limits of, like, how much stuff you actually want us to look at.

  279. 46:30

    Awesome. So I think the one, I think the one part that we wanna touch bo- touch upon again, uh, really quickly, is this part, the, the planning part. Uh, so we do have one more product out, coming out, called AI Planner. Uh, I would say this is more geared for, I would say, like, um, say, uh, if you have a spike, or project managers, or say you're a manager that wants to see if something is feasible for your current repository, that's where AI Planner comes in. You can kind of provide your idea of what you wanna build, and what the AI Pla-

  280. 47:00

    Planner will kinda do, again, goes through our context engine, kinda figures out, okay, what is in your repository, what is your plan, and is it feasible? And if it is feasible, it will tell you. And the second part is it will kinda give you a breakdown of what you need to implement. Um, if you do wanna build out the specif- specific, uh, specific feature or the specific, you know, idea that you do kinda have, it will give you the plan, uh, and it'll kinda give you a, uh, a, a few ways to execute it. Um, talked a lot about the context engine. Um, Shane is actually here. He's working a lot on

  281. 47:30

    code chat. Um, Shane, do you wanna talk a little bit more about the code chat capabilities and, like, all, everything within, like, a context engine itself?

  282. 47:39

    Sure. Are there slides?

  283. 47:40

    Hmm?

  284. 47:41

    Are there slides?

  285. 47:42

    Uh, there's no slides.

  286. 47:43

    All right. Um, yeah, so he's mentioning, uh, context engine code chat. The way we've been thinking about it, and at, at Atlassian we have many repositories, I think we have 15,000 repositories across the company, and asking a simple question like, "Where do I implement this change?" Or, "Where is X, Y, and Z implemented?" Or, "What services are using this other service?" are really, really complicated. And so at the core of the context engine, it is narrowing down the retrieval and the search space

  287. 48:14

    to scope it to, like, where this answer is most likely, uh, lives within the code, and then reaching out from there and, like, digging into the code to answer the questions. And then on top of that, layering in all of the, um, information from the teamwork graph. So documentation historically out of date, inaccurate. If you're searching only across documentation, you're going to get something that was true at some point in time, um, but it's also a lot of really valuable information. So this project built this thing at

  288. 48:44

    this point in time. It was true, it's no longer true, but the reason why those things are decided at the time are valuable for making changes in the future. And so we can leverage the code as it exists today, the decisions that went into the code as it existed at some point in the past, and use that to inform, um, implementation paths or, or, or planning for, you know, why we should change code in a certain way. Does that make sense? Any questions? But yeah, like

  289. 49:14

    historical information about why decisions were made are something that's often left out of, um, agent-generated code, but it's really important, um, historical context for, like, not res- remaking mistakes of the past. And so that's how we think about the context engine.

  290. 49:30

    Awesome. Thanks, Shane. We have a question over here.

  291. 49:39

    Yeah, it's, um, a lot of it is used, like AI Planner is leveraging it for a lot of things that

  292. 49:47

    I don't know if either of you can speak more about. But AI, AI Planner is using it a lot, right? So if you have something that you're trying to figure out, um, how to build, it can look at documents for projects related to it, context around it. So it's, it's kind of at the core of a lot of these new capabilities we're building out. Um, AutoDev uses it, um, Andy can probably speak more to it. Um, AI Reviewer doesn't use it a lot today, but we're starting to experiment with how to pull more, um, into there. And then the other place it's exposed today is within Rovo Chat. So if you're talking to

  293. 50:17

    Rovo and, um, we're in early access with a few customers now. We just announced it a couple months ago. But if you ask it code related questions today, it answers those through, um, mostly Confluent Search, some other, uh, connected tooling. And then if you have GitHub or Bitbucket, it will use their search APIs. Um, but if you are, you know, ha- have this new capability called code context enabled, it will have like a more cohesive understanding of the

  294. 50:47

    code grounded in the truth today, the historical decisions that went into it, and answer those types of code related questions more effectively.

  295. 50:55

    Is there like a, um... Sorry, is there like a public service around that, like maybe MSP access or like lists or use like their own-

  296. 51:03

    Yeah. So the Teamwork Graph CLI, um, if you've seen that, that's where we're starting to expose a lot of these capabilities. Um, the context engine itself is more agentic search, is the way to think about it. We have a lot of the core primitives that we use, uh, that we'll expose to your agents through the CLI, but I think over time, you know, we might consider moving more of those into there as well. Yeah, Teamwork Graph CLI has access to all of the, um, code context skills.

  297. 51:31

    Thank you.

  298. 51:31

    Yeah.

  299. 51:31

    Question in the back.

  300. 51:33

    Yeah, I had two questions. Uh, the first was on standards. Um, it looked like the standards were like prose and Markdown. Is that correct?

  301. 51:40

    That's correct, yes.

  302. 51:41

    Um, do you have any way to map those to something deterministic like a CI check?

  303. 51:48

    So kind of like, kind of like what I would say like a check, uh, like a checkbox kind of like s- uh, scenario, right? Um, I think just off the top of my head, what we would probably have to do is kind of like implement that within a, the, the Markdown itself. But that's actually a really interesting use case where you can just provide it like specific, like can, like binary, yes, this is satisfy, no, this is not satisfy. Um, so I current- currently, I don't think so. I don't think we can pro- we d- provides that out of box. But I will relay that over to the standards team to see if we can get that in the future.

  304. 52:18

    Yeah, like we really need to make it a little bit more deterministic on the standards.

  305. 52:21

    That'd be awesome.

  306. 52:21

    Because there's a lot planning.

  307. 52:23

    Right.

  308. 52:24

    Um, so, uh, do you have a way where if you have a large epic that you can break it down and decompose it into multiple agents, uh, like waves of agents? Usually there's, there's foundational work that will unblock more work down the line. So you can have like one wave implement the foundational work, and then that can, uh, uh, unblock a later wave of like a magnitude more agents that roll from the one. So do you have anything like that built in yet?

  309. 52:49

    Right. Just to reiterate, uh, I think your use case is kind of similar, like where you have an epic, um, and you maybe want that epic to be like broken down to like smaller issues. And then within those smaller issues, you can have like, you know, like a wave of agents kind of like execute each mo- smaller piece. Is that correct? Would you want like maybe like one step further once you implement like that first wave? Like is it, if the, like if we could get a second wave going?

  310. 53:11

    Yes.

  311. 53:11

    Okay, awesome. Yeah, yeah. Good que- great que- great question. So I actually played around with this yesterday. Um, with JCA, what you can do, you can take an epic, uh, you can get JCA, "Hey, can you break this down into like smaller issues for me?" And then, uh, it will be able... It, it is able to break it into like smaller Jira task if you provided a Jira epic. After that, what you c- what you are able to do, um, there's a few like automation rules that you can kind of do. Let's say, let's say like, uh, w- with an automation, let's say like you have the Jira epic kind of like be broken down. Once it's broken down, you can

  312. 53:41

    have automations kind of like re start a JCA, uh, instance, uh, start a JCA kind of session, and it is able to like autonomously kind of like develop each of that.

  313. 53:49

    And I don't think there's anything that would prevent you from kind of extrapolating that further, right? Like-

  314. 53:53

    Correct

  315. 53:53

    ... here's all the stories I want. Break these down into multiple epics, right? The foundational work, the like V0, V1, V2, and then just have it, you know, further refine the tickets into there. And so I think nothing would prevent you from doing that.

  316. 54:06

    No, you can keep going.

  317. 54:07

    So yeah, you can do... It's very flexible.

  318. 54:09

    You can keep going.

  319. 54:10

    Can you use Rovo as like a chief of staff to assign agents automatically to those sub-issues?

  320. 54:16

    Sounds more like a JCA automation kind of like sl- I'm not sure if Rovo directly could do it, but I definitely think you can do with automations.

  321. 54:23

    Yeah, and I think AutoDev might be able to do some of that.

  322. 54:27

    AutoDev, yes.

  323. 54:28

    Okay. I, I think that would be asked a lot. I know what you guys are doing. It's great. Thank you.

  324. 54:32

    Yeah, no worries. Question.

  325. 54:35

    Okay. Uh, I just want to understand that Rovo actually acts as a, um, tag additions. But I actually wanted to know that is it real time when I'm seeing the demonstration. Um, my code is, when I change the code in one of the file, is it real time it gets that, "Hey, you are doing it wrong"? Um, I hope the clarification is that, is it real time?

  326. 54:58

    So just to reiterate, uh, let's say you make a code change within like your IDE.

  327. 55:04

    Yeah.

  328. 55:04

    Oh, yeah. Um, so I think the... You have to think about with JCA that like it, it is isolated very much the agent sessions. So if you say like make a change within the agent session itself, um, then it will be real time. Uh, if you make it, if you make a change within the VS Code instance within the cloud, then yes, all those changes will happen real time and you'll be able, be able to ref- reflect that within the cloud session itself. Um, whatever changes you make on the IDE, it's a separate, kind of like a separate instance, right? Uh, so yeah, with, with agents, think about it like all within the cloud itself. Any change you

  329. 55:34

    make in the Jira session, Jira agent session itself within Jira, then, then, then all that will be real time.

  330. 55:40

    Yes,

  331. 55:42

    that's all. Thank you.

  332. 55:42

    Question over here.

  333. 55:46

    ... complicated, I guess, does, does your framework need to be like Dockerized basically in order to get it to run? Like, if you had some on-prem thing, like complicated-

  334. 55:56

    Yeah

  335. 55:56

    ... instance, like, I guess, would you be able to run these agents?

  336. 56:03

    So just to reiterate, like, so it sounds like your instance is more like on-prem, and you want to run a bunch of, like, the agents all, like, o-on-prem. Is that correct?

  337. 56:12

    Well, not, not exactly. I, I guess... Like, like how is the develop- development environment, like, expressed? Like, is, is there some like declarative config, like a Dockerfile that we would have to use to-

  338. 56:27

    I think-

  339. 56:27

    ... like create, or is it-

  340. 56:30

    That's-

  341. 56:32

    That's Docker, yeah.

  342. 56:33

    It is Docker, yeah, yeah.

  343. 56:34

    Okay. All right.

  344. 56:36

    Cool. I think we have time for one more question.

  345. 56:39

    For this framework, would you support AWS Skill, which is like the skill.mp?

  346. 56:44

    That's a great question. Uh, we actually just started, uh, supporting skills, I think, just not too long ago.

  347. 56:50

    Because one, one of the cool questions was like the CI building, and you can test large squares of AWS skills.

  348. 56:56

    Mm-hmm.

  349. 56:57

    So that seems like that's a horizontal challenge that you would be able to have, like, patterns for this kind of thing.

  350. 57:02

    Right, yes. So yeah, I think for just r- AI Reviewer itself, well, we do support skills like, uh, like I think less than a month ago we released that. Sounds good.

  351. 57:13

    Cool. All right. Thanks everyone. We gotta go. We'll be around if there's any other questions, but-

  352. 57:18

    Yeah. Thanks a lot. Thanks a lot everyone for joining, uh, joining our workshop. Thanks a bunch for the, uh, the tech staff for getting all of our Wi-Fi issues sorted out. Big shout-out to them. Um, hope you guys have a great rest of the week during the, uh, during the conference. Thank you so much, guys.