Faster Code, Same Bottlenecks: The AI Teammate for the Modern SDLC

How many of the engineers you manage are building the right thing, for the right market, at the right quality? Not shipping fast. Shipping the right work. Darryl Lee opened his Work Evolution Summit session with that question, and it landed because most leaders in the room could not answer it with full confidence.

Darryl works as a pre-sales solutions engineer at Atlassian, based in Amsterdam, where he has spent around six years. His session picked up exactly where Sven’s keynote left off. Companies adopted AI, yet the productivity gains hit a ceiling fast. He put numbers on it: almost 90% of the companies Atlassian interviewed report full AI adoption, and only 10 to 15% of their developers feel a real gain. If you have rolled out AI coding tools and watched your delivery metrics barely move, you already know the gap he means.

daryl lee Atlassian

Where the Time Really Goes Now

Darryl’s diagnosis is simple once you see it. The software development life cycle did not get shorter. The total time your teams spend did not drop. The time just moved. Writing code is far easier than it used to be, because most developers now lean on prompts and AI assistants to produce it. So the code itself stopped being the hard part.

Look at what surrounds the code and you find the real opportunity: planning, orchestration, review, and operations. Those are the stages AI has barely touched on most teams. Darryl was careful about what improving them means. He is not asking you to compress the calendar. He is asking you to use the process and the AI tools you already have to raise quality and speed at the same time, rather than trading one for the other. His talk walked through three stages where that happens, planning, building, and operations, plus the two things that hold it all together.

Planning: Stop Building Features Nobody Wants

Coding got easier, so the question at the front of the process matters more than ever. What are you building, and where did the spec come from? Where does the product requirements document come from? Darryl echoed a point from Sven’s keynote, that nobody enjoys writing those documents, and then made the case that they decide whether the next quarter of engineering hours pays off or evaporates.

Atlassian’s answer is the AI Planner. You start with a written idea, open a chat with Rovo, and ask whether it is feasible and how the market is likely to respond before you commit anyone’s time. Once you decide to proceed, the Planner helps you write the PRD, pulling context not only from your code base but from Confluence, your history, your backlog, your bugs, and your feature requests across the teamwork graph, which reaches into Microsoft and Google Docs as well. Then you break the plan into work your team can build.

Someone in the audience pushed on the obvious question: how does it judge feasibility? Darryl’s answer had two layers. First, your organization’s values, meaning your goals, your mission, and the benefit you are trying to deliver to the market. Second, where those signals live, which is the teamwork graph. Rovo reads what worked before and what failed, and uses that as a benchmark to estimate how a new idea might land. He grounded it in a real miss. Atlassian once shipped a feature in Jira Service Management that failed, and product managers had spent a long time interviewing, planning, and dedicating engineering hours to it without the AI and the teamwork graph they have now.

“we wasted a whole year of time and money investing in a feature that would never work”

A year. Read that back to yourself before your next roadmap meeting. The value of planning with context is that you can see the shape of a failure before you fund it, and spot where a weak idea might be turned into a strong one.

Building: An Autonomous Teammate That Still Asks You to Review

Customers keep asking Darryl the same thing. AI writes code quickly, so how do you know the code is actually right, and right against your acceptance criteria? That is the job of AutoDev, which he described as an autonomous engineering teammate that sits beside your product managers and engineers. Once planning is done and the work items exist, AutoDev breaks each one into detail, writes the code, opens a pull request, and then points a human to review it before anything ships.

The design principle underneath it is the one Darryl kept returning to all session.

“human is the biggest value in this AI era”

Fully autonomous and fully automated, with a person in the loop at the decision point. AutoDev meets your engineers where they already work, whether that is inside an editor like Cursor or as a Rovo Dev panel assigned into your workflows and tickets. That panel also gives engineering leaders a live read on what is happening, how many builds shipped and how many pull requests sit waiting for review. You can cap how many credits or tokens a conversation consumes, which turns AI spend into something you can measure against return and explain to your senior leadership in plain terms.

Operations: An SRE That Filters the Noise

Things go wrong in production. Alerts fire, and often they are false alarms or minor issues, yet the engineers pulled in to handle them had no part in building the thing and start from zero context. Darryl’s answer for this stage is an AI Site Reliability Engineer built into Jira, an always-on monitor for active and potential incidents that delivers root cause analysis and auto-triages alerts and bugs so your team stops drowning in noise.

Picture a spelling mistake on your website. Your monitoring system raises an alert, but does that deserve an engineer’s attention this minute? Probably not, and the teamwork graph may already hold the fix. The AI SRE steps in when the alert dispatches, analyzes it, groups related alerts, and hands back a solution for the small stuff so your engineers stay on the incidents that matter. For a genuine critical incident, it does more than wake someone up. It triages, finds similar past patterns and the builds likely connected to the problem, and compresses all of it into a single paragraph an engineer can read, fix, and roll out.

The Two Things That Hold It Together

After three stages and, as Darryl put it, more than 10 agents and a hundred workflows, he named the fair question: how is anyone supposed to remember all of this? His first answer is automation. Atlassian rebuilt Jira automation around the SDLC, so you can embed Rovo agents to build code, review it, and open a pull request directly inside an automation. What used to take a week of wiring together multiple steps now takes two, a trigger and the code that gets developed and remediated from it.

His second answer is the one he wanted everyone to carry out of the room: context. Coding agents were already strong before this, tools like Copilot, Claude Code, Codex, and Antigravity. Their weakness was the absence of context, which left them giving generic answers your engineers then had to fix or extend. The context problem is real for anyone with sprawling code across GitHub, Bitbucket, and self-hosted GitLab. So Atlassian is building a context engine that reads your code base as a whole and learns from how your teams actually code. You plug your code base and development tools into the teamwork graph, keep your engineers in the tools they love, and connect the two through MCP or the command line so they gain context without leaving their editor.

Keeping Your Code Yours

The moment coding enters the picture, security becomes the first question, and the room asked it directly. One attendee wanted to know how to keep intellectual property from leaving the organization.

Darryl laid out several controls. Rovo asks permission before certain tasks. Atlassian does not share your data with outside LLMs. A self-hosted Atlassian LLM is coming, and you decide what gets indexed when you connect a code source. He also confirmed that in 2026 Atlassian rolled out bring-your-own-key for Rovo, so you can supply your own AWS key to manage how your data is handled.

Permissions carry over from your existing structure too. Another attendee asked how the system spans GitHub, GitLab, and Bitbucket across teams that do not share knowledge. Darryl’s guidance started with discipline rather than tooling: document your process, roles, and permissions, because the teamwork graph indexes your data and serves it according to those rules rather than reading everything at once. If one department works in GitHub and has no business seeing GitLab, Rovo respects that boundary and will not surface context across it.

You Can’t Improve What You Don’t Measure

Darryl closed the substance of his talk on a discipline many teams skip – “you cannot improve without measuring the things”

Atlassian’s answer here is DX, which supplies benchmarks and developer surveys so engineering leaders can gauge how their organization performs and how AI adoption is moving through real engineering cycles. You can see how many pull requests AI created and how many AI agents reviewed, then turn that into a report your leadership actually understands. Without that feedback loop, you are guessing about whether any of this works.

What to Do Next

Darryl ended with a call to action you can act on without buying anything new this week. Encourage your engineers to plug the teamwork graph into the coding tools they already use, and enrich the context flowing into those tools. When developers resist, and he was honest that they will, keep them in their favorite editor and connect it for context rather than forcing a switch. The more they use it, the more data accumulates on both sides, and the decision about new tools can wait for a moment when the data makes the case for you.

He also pointed the room toward solution partners to design the rollout, and named Life in Codes directly as the partner on site to sit down with teams and plan their AI SDLC. That is the work worth starting now. Map where your time actually goes across planning, building, and operations, decide which stage leaks the most value, and bring context to that stage first. Your engineers are already coding faster. The gain you are looking for lives in everything that happens before and after the code.

About Life in Codes

Life in Codes is on a mission: to support organizations of all kinds to work in a more productive way. That means smart tools, healthy practices, and training the people. As an Atlassian Solutions Partner active in Romania, Estonia, Belgium, UK and the UAE, with our team spread across Europe.

Our client roster includes start-ups, SMEs, large financial institutions like SWIFT, government organizations like the European Commission, and logistics providers such as DHL.Our expertise spans a wide range of solutions, including ITSM, Agile Project Management, Digitalization, Knowledge Management, next-level customer support, DevOps, cloud migration and Rovo AI agents.

We firmly believe that working smart is universal – regardless of industry, company size, or team composition. – our diverse client base is a testament to this philosophy. Whether you’re a tech-focused team or not, Atlassian tools, coupled with our expertise, can significantly enhance your productivity and collaboration.

At the end of the day, we believe in the power of teamwork and we aspire to help people reach their full potential.  By partnering with Life in Codes, you’re not just adopting new tools – you’re embracing a more efficient, collaborative, and successful way of working. Schedule an appointment

Table of Content

Share this content:

Discover the joy of collaborative working

We are your experienced and certified local partner and we are determined to find the best solution for your challenges. 

Download PDF

Please leave your details below to download your free copy.

    Email address

    Full name

    Company name