AI-Native SDLC: Redesigning How Software Gets Built - Dhaval Moliya

In this talk, the speaker, Dhaval, discusses the shifting landscape of software development and the integration of AI into the software development lifecycle (SDLC). He outlines how traditional SDLC processes, which rely heavily on human coding, are evolving as AI technologies become more sophisticated. Dhaval emphasizes that organizations are moving from AI-assisted and AI-augmented stages to an AI-native SDLC, where AI takes on more execution responsibilities while humans focus on intent and judgment. He presents a practical framework of shifts that define AI-native SDLC, showcasing Atlassian's approach within a large-scale engineering environment, and highlights the importance of building supportive infrastructures for governance and AI tool integration. The talk concludes by encouraging developers and leaders to embrace AI tools and rethink their software processes in light of these advancements.

Hello and very warm welcome to everyone. My name is Dhaval and I I'm working as a head of engineering at DevInfra's AI Foundations group at Atlassian. For the next 25 minutes, I want to challenge a few assumptions about how we build software and share what we are learning at scale. Let me start with a simple question that I want all of you to sit with for next

25 minutes. What is a sprint for? Two weeks, planning, stand-ups, review, retro? We We all have been doing this for over 20 years now. And for most of the time, answer is obvious. The sprint is the smallest unit of time in which team delivers a working software. But here is what has changed. I've seen teams take the well-defined user story, not a simple one, but the one

with lot of edge cases and business rules, and give it to coding agent, and what they get is working, tested, documented code in under an hour. Not a prototype, not a skeleton, working code. PR already open and link back to the Jira ticket. So I want to ask this question again. I'm not here to tell you sprints are dead. I'm also not here to tell you AI

will replace your engineers. Both those narratives are wrong and lazy. But the SDLC that most of us are used to is the is for it was designed for the world where humans were the primary producers of of the code. But that world is changing very fast and irreversibly. So today, I want to walk you through what AI native SDLC looks like. Also, I want to talk about

how AI native how AI native SDLC looks like in one of the largest engineering organizations organization of the world when it is implemented at scale. 100 million lines of code, three mono repos, hundreds of teams, not a startup, not a clean green field, but the real thing. Before anything else, let's be precise here. Most of the organization organizations are at level one in their AI maturity adoption,

but they call it as level three in their boardroom meeting decks. Let's look at what are these three levels. Level one is AI assisted. Developer opens the tool and AI auto completes the code. This is so so AI is acting as a faster keyboard, but process doesn't change. This is where the most teams are today. Level two is AI augmented. AI completes the whole task. It writes

the function, it writes the test, it explains the bug, and it summarizes a PR. Useful, but process is only changing around edges. Level three is AI native. The process itself is redesigned around AI's capabilities. Humans define the intent, set the constraint, and handle the judgment, but AI handles the execution at the speed. Atlassian is already moving towards AI native ways of working. The gap between where we

aspire to be and where we exactly are today is exactly the gap that most engineering or most most large-scale engineering organizations are facing today. The difference is we are building the infrastructure to close it. So this this are the five five shifts that define the AI native SDLC. For each of this shift, what Atlassian offers today, and what still what that still doesn't solve at our scale.

Think of this as your mind map for the next eight In traditional SDLC, a developer's primary output is the code, but in AI native SDLC, it's precisely the intent. Look at the difference on the left-hand side. When you are giving a vague prompt like write a login API, then it gives a generic output. Wrong patterns, and three rounds of the correction. But for the same task, if

you're specifying a very precise prompt, write this jot jot API endpoint, uh use the middle use our standard middleware patterns, and validate against our Zod schema, and cover some H cases uh for test like expired tokens, then in the first pass itself, the output that you get matches the convention, very minimal back and forth. So, think about what it takes to get great results from the coding

agent. This is not prompt engineering. This is specification engineering. Decomposing a problem, articulating the constraint, and defining the success criteria. This is precisely what you need to feed to AI AI coding agent, so that it can act upon it. This is a learnable skill, and this is quickly becoming the most valuable thing a senior engineer can do. And here is a practical shift underway. Build prompt libraries

and the specification templates for your domain, which is and this is a reusable intellectual capital, which not only makes you, but your entire entire team more effective with AI agents. Traditional SDLC sequential. Each step requires uh to wait on the previous one. And there is a human-to-human handoff required at every single step. The whole delivery is not slow because your developers are slow at writing the code,

but it is slow because there is a human-to-human handoff involved at every But AI doesn't have that constraint. AI native SDLC breaks this sequentiality completely. You can write the code with AI, while in parallel, you can also write the test with AI, and once the PR is open, then AI I review your PR also in parallel. Right? So, AI native SDLC breaks the sequentiality completely into concurrent

work streams. But what still doesn't What this still doesn't solve at our scale is at 100 agents also also needs to find things more efficiently. Traditional grep-based search tools, they start timing out at our scale. And and because of that agents agents starts crashing and it doesn't produce any meaningful output. So, what we did to what we built to solve this, we'll come to that little later.

AI native SDLC makes the quality more predictive, not reactive. Look at the left-hand side chart. The best engineer the best senior engineer in your team at 9:00 a.m. on Monday morning with with sharp mind uh when when he when they go for the PR they'll tend to catch 92% of the things in the PR. But same engineer come on Friday evening under constant deadline pressures even the

best of these engineers, they will end up approving the things that they should not be approving. AI review produces consistent quality every single time. No fatigue no deadline pressure. What Atlassian offers today is Roadie, AI reviewer. AI powered code reviewer agent. It reviews every single PR in Atlassian and it it it produces consistent quality But this auto review agent as we call it, it has some critical

blind spots. It can see code in this PR, but what it doesn't know is why this code was written in a specific way. It It has no memory of past architectural decisions and it has no awareness of incident that led to a certain convention in coding. At our scale with years of PRs and millions of review comments the history is an extraordinary asset. And we have built

a PR knowledge graph to mine that asset. When an area receives any PR for the it calls this graph. And what this graph surfaces is, this specific pattern was flagged eight time in last 1 year on this file, and here is why. And this is the valuable asset which keeps on compounding. Every team says that they'll do the documentation properly. But almost nobody no no team does

that. What Atlassian offers to rate Row chat across Atlassian products including Confluence, Jira, and other products. In natural language, you can ask question like, "How does payment retry work?" And what you get is grounded answer from your Confluence and Jira docs in seconds. But here is a deeper problem. The click. Oops. So, my bad. Yeah. Thanks. Row chat retrieves the knowledge, but what it does not do

is it cannot enforce it to the coding agents. Your ADRs, your package boundaries, and your security standards, all these are invisible to AI agent at the time of code creation. And AI agent hold told this to when you are asking your AI agent to told to to respect certain coding boundaries or or certain convention and all, but it doesn't know what those convention are exactly or where

they are sitting. So, we are building the code governance engine to solve this problem. ADRs, standards, and package boundaries, all these are exposed as a MCP tool to So, that coding agent can query them in real time. Whenever a new security threat is published in Confluence pages, it is propagated within few minutes, not in weeks. In in minutes it gets propagated and agent agent coding agent is

aware of that. And this is the most important shift that I want leaders in this room to focus on. Today, humans are the gatekeepers. Every step requires approval or handoff, as we discussed earlier. And this is why delivery is slow. Not because developers are coding slowly, but because there is a there is a process which is full of handoff at But in AI native SDLC world, humans

becomes the governor. AI handles the all mechanical steps in its own. And humans are involved only when there is a decision point and and human really needs to give some input or judgment uh to move forward. What Atlassian offers today is Rover Dev in Jira, agentic pipelines, and auto review. Combined together, they enable this pattern. But at our scale, hundreds of teams running it Rover Dev CLI

alongside Cursor, Copilot, Codex, uh Cloud Code, tool diversity is not a problem to have, but it's a necessity and it's an area to govern. You cannot govern that tool by tool. And therefore, what we have built is context shield, and we'll come to it a little later what exactly it is. So, everything from here onwards is Atlassian's internal engineering tooling, and these are not customer-facing products. The

reason I'm sharing this is not because uh I want to do any pet product showcase or catalog, but because whenever you go for large-scale AI native SDLC adoption in large organizations, these are the precisely problems that you will also hit. So, there are these three problems. Problem one, AI does not know your world. Problem two, governance doesn't scale And problem three, you can't change existing code at

scale. So, some of what we have built is already shipped. Some of these are already being built right now, but all of them is necessary. AI does not know your world. And this is the core limitation of every single uh vendor AI tool that are there today in market. That's because, you know, these tools are trained on public code. They know Java, they know Python, they know

React, but they don't know your Java. They don't know your patterns, your history, and your decisions. At our scale, this is not a this is not a minor inconvenience. It's a difference between AI which is useful and the one that confidently generates the code that looks right, but it is wrong in three specific way that only someone who has worked on this code base for 2 years

can catch. So, what are the three tools that we built to close this gap? Semantic code base search. It's a vector based search across our entire code base. Task dropped from nearly 6 minute to just over two. Not because AI got smarter, because AI started AI stopped thrashing. PR knowledge graph. As we discussed little earlier, built from years of PR review discussions. When AI reviewer opens the

PR, it queries the graph. And reviewer flags this pattern eight times over past 1 year. Here is why. So, value starts And code governance engine. Your ADRs are exposed as MCP tools so that any coding agent can query them real time. Intelligence is not the same as knowledge. Smarter AI models make governance more important, not less. A smarter model writing 10 times more code right without knowing

your architectural boundaries, it will produce 10 time more architectural drift. There are two more tools worth naming. Repo mind. It auto generates structured briefing from repo history so that agent arrives briefed like a senior engineer. Think about a complete bespoke AI ML pipeline that we have set up for each of the major repo so that based on your past repo history, your ADR ADRs, your convention, etc.,

we we produce the harness which is very relevant for your repo, and we keep on auditing this harness and updating it on a periodic basis, in an automated way. Skill builder. It mines thousands of AI coding conversation happening every single day across the organization. It clusters the pattern and it distills the reusable skills. Developers don't change their behavior. The system learns from what they are already doing.

So, we run multiple coding agents, not by accident, but by design. Different developers are meaningfully more productive with with different coding tools. Mandating only single coding tool and losing the adoption is worse than governing diversity very well. And that leads us to that leads us to the diversity and and governance So, these are the three tools that we built. Codeless chain, it is our own coding uh

ID plugin. It's agent agnostic ACP compliant coding plugin. Uh it runs on any ACP compliant agent you can govern the whole platform. So, we don't have to govern which agent that developers want to use, but we govern the whole platform that they run on. Contextual. It's a proxy intercepting every prompt and response under 80 milliseconds. This is very, very important for securing the AI produced code. And

hallucination detection, direction. And this is the one that I want you to remember. When AI touches any of your internal services, it infers what your APIs do. And those inferences are often directionally correct, but they're specifically wrong. It generates particular uh REST endpoint, which would be which which might have been deprecated, let's say, 8 months ago itself. Or it ends up using command in pounds, whereas our

service would expect uh currency or or amount in pence. So, what happens is the code looks right, it compiles, test cases is pass, but it's wrong in a way. It will take few weeks to surface that. So, what we have done is we have built CI pipeline component and it it compares every AI generated internal API call against the live catalog of our our actual services definition.

So, all these type of issues are quoted at PR time. And this tool has no commercial equivalent. this problem only exists when you have a very large code bases. And which is why nobody talks about this in conferences. So, writing a new code with AI is a relatively solved problem. Everyone does that. But changing existing code base at a very large scale, it is not. Think about

migrating one version of React to the other version and and solving that with AI with minimal human intervention. A single deprecation campaign at our say one library, one security fix, it can affect thousands of code sites across hundreds of teams. Today, let's say the people create the tickets and wait for weeks or months and chase the stragglers and accept it it never fully completes. But what we

are doing is we are building the AI migration platform. Agents discover every affected code site, execute changes in batches, and apply learnings from earlier batches. So, fix merge conflicts and early CI failures automatically. The role of the human reduces to define the campaign, review the strategy, and handle the exceptions. So, why engineers walk away from AI? Engineers who tried AI and they walk away, they don't do

so because AI is bad, but they walked away because AI hallucinated on internal API. It violated the team's conventions and produced the code that broke things that that they didn't know they were connected. Context engine, governance engine, and hallucination detector. These are not the nice-to-haves, but these are the adoption infrastructures. These are very much needed to go to level three. Now, let's take a look at honest

scorecard. What is reality versus what is hype? I would give you very honest opinion here. What are the proven things today? AI score generation and completion. It is genuinely very, very useful. Roadmap auto review and pipelines. All these products are used internally very heavily. Semantic search at Semantic search at a mono repo scale. It's genuinely very, very useful. It reduces your token consumption also, and it makes

AI more efficient and effective. There are a few things which are improving fast, but it requires continuous human supervision. Think of end-to-end agentic dev at a very large repo, at a very large scale to build some complex features. It does require some But there are a few things which are overhyped. That AI will replace your engineers. No. That That won't happen. Demand for people who can direct,

review, and govern AI-generated software is only increasing, not decreasing. The second one is across the board, AI makes productivity 10 times more. That's again wrong. Two to three three time productivity across teams, yes, that is what we are already seeing, but not 10 times. And the third one is AI code is safe by default. Absolutely AI-generated code is It It hallucinates a lot on APIs. It generates

the insecure and it It introduces subtle bugs which are hard to debug at a later stage in production. So, review and governance are non-negotiable, and this is precisely why we built what we built. Every major technical shift has Every major techno technological shift has triggered same fear whether it will make engineers' job obsolete or not. Compilers, IDEs, and no-code tools. Each time engineers who adapted this wholeheartedly,

they've become more valuable, not less. And AI is the same shift, but with much, much larger magnitude. So, here are the two things that I would like ask you to do. If you are a developer, pick one task that you are doing repeatedly. Do it I entirely with AI for 2 weeks. Not to do it faster, but to understand where AI help AI helps and where it

fails and where your judgment is very much needed. If you are an engineering leader, take a look at your sprint board. Ask which step would you change if AI agent were a full team member. Map it. Don't implement or change it yet, but the map shows you your highest leverage change that you can make. So, the sprint is not disappearing, but what happens inside the sprint is

changing completely. The question isn't whether your team will be part of this redesign or not, but the question is whether you'll be ones who will be doing this change or leading this change, or you'll be the ones who will be reacting after someone else all else has already made this All right. Thank you. >> [music] >> Woo!