The AI-Native SDLC: Seven Pillars
Adopting coding agents is the easy part. An AI-native software lifecycle also rebuilds the work before and after the code - planning, design, review, and maintenance - on top of two platform investments: connected context and continuous measurement.
Last reviewed: October 2026
Coding Went Multi-Threaded
Atlassian's "The AI SDLC transformation playbook" (10-01-2026) starts from one observation: as less code is written by hand, coding stops being a synchronous, single-threaded task and becomes an asynchronous, multi-threaded one. One developer now directs several agents and several streams of work at once.
That moves the bottleneck. The steps before and after the code - planning, design, review, and maintenance - become the largest constraints and the largest opportunities, and team collaboration gets harder as the rate of work rises. It is the same conclusion the Productivity Paradox page reaches from telemetry: authoring got cheap, and everything around authoring did not.
Atlassian's answer is to invest in two platform foundations at the same time as five workflow shifts, so that together they become what the report calls "the modern software factory": faster, more autonomous, more event-driven, and reshaped around the decisions that still need human judgment. This page lays out that framework in vendor-neutral terms and maps it onto the rest of this site.
The Seven Pillars
Two platform investments and five workflow shifts. The platform investments are shared infrastructure; the workflow shifts are changes to how each stage of delivery runs.
Platform investments
Context
A connected, permission-aware graph of code, work, documents, decisions, and people that every agent can query.
Measurement
Feedback loops that make agent and team activity observable, so you can tell real gains from hype.
Workflow shifts
Planning
Specs drafted from real code and customer context.
Design
Live prototypes and standards that sit next to the code.
Development
Quality from context, velocity from orchestration.
Review
AI first pass on shared standards, humans decide.
Maintenance
Agents triage and clear routine work, escalate the rest.
Systems of record tie the pillars together
The two halves depend on each other. New workflows only work well when they are backed by connected context and feedback loops - and context and measurement are only reliable when the metadata from those new workflows is consistently captured and reachable.
Systems of record - the tracker, the repository, the docs, the incident tool - are where that capture happens. People use them to plan, decide, and ship; agents read the same structured data to do their part. And the interactions between developers and agents become a new kind of context in their own right, so the whole loop gets smarter the more it is used.
Traditional vs AI-Native, Workflow by Workflow
The left two columns summarize the shift Atlassian describes. The right column is where to start on this site.
| Workflow | Traditional SDLC | AI-native SDLC | Build this first |
|---|---|---|---|
| Planning | Requirements written by hand with partial knowledge of the code; weeks spent aligning teams; specs miss architectural constraints and debt | Agents synthesize customer needs and code context into requirements, kept as versioned spec files in the repo; people refine and decide | The ticket contract and spec files an agent can test against |
| Design | Static mockups and written briefs handed off for every change; even small layout tweaks wait on a developer | Live prototypes replace static frames; design standards live beside the code; designers ship UI code and small fixes themselves | Design standards in the repo's instruction files, and a low review tier for copy and style |
| Development | A developer researches, plans, and writes the code; velocity and quality are capped by one person's throughput and skill | Developers plan, generate, and test with agents; quality depends on the context supplied, velocity on how well agents are orchestrated | Plan-first work and an orchestration control plane |
| Review | People review every change; standards vary by reviewer; feedback is slow; intent is not checked until staging | AI reviews first against shared standards across new and existing code; people make the judgment call | Versioned review rules and risk-tiered review |
| Maintenance | Incidents and errors triaged by hand; keep-the-lights-on (KTLO) and reliability work deprioritized for lack of capacity | Agents triage, resolve, and document routine work and escalate only when needed; capacity moves to new capabilities | Safe work classes and the bug-to-failing-test pattern |
Platform Investment One: A Context Graph
Agents may be capable of writing, refactoring, and reviewing code, but they face the problem development teams always have: making sense of the context around each task. People build that context over years in the same system - what the code does, the product strategy, past architectural decisions, the standards and constraints nobody wrote down. An agent starts every task without it, so it has to be supplied every time.
What good looks like, in Atlassian's description, is a context graph: interconnected data spanning repositories, work items, documentation, technical standards, meeting recordings, and chat, reachable by both people and agents through a permissions-aware layer. The point is that AI acts as a knowledgeable teammate instead of guessing at the shape of the system. With code at the center, the graph can answer the questions a new teammate asks on day one.
Why is this method important?
The work item, the decision, and the spec that explain why the code exists.
What else needs to change?
The linked pull requests, pages, and tasks that move with this code.
Who owns this?
The people and teams accountable for it, so an agent knows who to ask or route to.
Which services depend on it?
The downstream blast radius that a review or a refactor has to respect.
Permissions at the data layer
Governance has to be enforced where the data lives, so that what a person can see is exactly what an agent acting for them can act on - no more. Exposed through MCP or a CLI, the same graph is reachable from the IDE, the terminal, and any agent surface, and the activity from those surfaces flows back into it.
Context that compounds
Because every agent run writes more structured context back, each later run should be better and cheaper. Atlassian reports that in its internal benchmarks, agents with access to its Teamwork Graph delivered 44% more accurate results while using 48% fewer tokens than agents without it - a vendor's own measurement of its own product, so treat it as a hypothesis to test against your baseline.
A context graph is the organizational layer above context engineering, not a replacement for it. Repo instruction files, skills, and curated retrieval still decide what reaches a given session; the graph decides what is available to retrieve. Start with the instruction files - they are cheap and immediately useful - and connect the systems of record behind them as the second step.
Platform Investment Two: Measurement From Day One
When the way teams work is changing this fast, nobody can tell what is working without data. The right feedback loops let an organization track the impact of AI tools and workflows alongside cost, productivity, and return - and let each team improve its own process instead of waiting for a quarterly verdict.
That requires work and agent activity to be observable in the first place. Data from systems of record, third-party APIs, and agent sessions gives near-real-time visibility into effectiveness and cost; qualitative signal from the developers doing the work explains it. Atlassian says it uses DX for this, combining quantitative data from tools such as Jira, Cursor, and Claude Code with qualitative developer feedback, and benchmarking the result to set targets and guide investment.
Quantitative
Cycle time, review latency, change failure rate, escaped defects, agent spend per merged pull request - pulled from the tracker, source control, CI, and vendor usage exports, compared against a pre-AI baseline.
Qualitative
A short, regular developer survey on perceived productivity, trust in agent output, and friction. Measured and perceived speed diverge, so you need both to see the gap.
The Measuring Impact page has the metrics to report, the ones to ignore, and the quarterly paradox test that tells a real gain from a review queue.
Planning: Grounded Specs, Not Committee Consensus
The friction
Planning runs on manual effort and consensus. Product managers and analysts spend weeks drafting requirements and aligning stakeholders, and because the people defining the work rarely know the codebase well, specs miss architectural constraints and technical debt - which surfaces as rework during implementation.
The shift
Agents synthesize customer needs and organizational context into requirements and specs, drafting from a real understanding of both the business and the code. People stop writing specs from scratch and spend their time on judgment: refining, deciding, and making sure the plan is grounded before engineering starts.
Build first
Specs as versioned files in the repository, and a ticket contract with acceptance criteria an agent can test against. Run an ambiguity check against the spec before a ticket is accepted. This is the Analyze and Ideate work.
Atlassian's implementation: ideas evaluated against customer feedback in Jira Product Discovery, then specs, PRDs, and technical blueprints co-created in Jira and converted into tracked work items.
Design: A Continuous Thread, Not a Hand-Off
The friction
Design is an isolated phase between requirements and implementation. Designers craft static mockups and written briefs and hand them to engineering, and because they cannot touch the codebase, even a minor visual tweak waits on a developer - a recurring bottleneck that drags out releases.
The shift
Design becomes a continuous thread through planning and development. AI-assisted tools let designers build live, interactive prototypes, generate UI code, and commit small fixes themselves, and the resulting code is treated as the design spec. Agent sessions follow design standards stored alongside the code.
Build first
Design-system rules in the repo's instruction files so every agent session applies them, and a low risk tier for copy and style changes so a designer's pull request does not queue behind feature work. Keep a named reviewer on anything that touches behavior.
Atlassian's implementation: design artifacts connected to code and work in flight through its Teamwork Graph, with Loom video feedback transcribed and fed to AI as prompts for the next revision.
Development: Context and Orchestration Set the Ceiling
The friction
Work is scoped and logged in a backlog before any code is written. Code quality is limited by an individual developer's skill and domain knowledge, and velocity by human throughput - how fast one engineer can write, test, and refactor.
The shift
Development turns fluid. Tasks are spawned from operational signals and captured as work happens. Code quality depends less on raw individual skill and more on the quality of the context supplied to the agent; velocity depends on orchestration - coordinating several agents working alongside engineers.
Build first
Plan-first work with a senior human approving the plan, then a control plane that decides which agent runs, when, and with what context - see Agent Orchestration. This is the Develop phase.
Atlassian reports that AI-native development processes cut its own issue cycle time by nearly half, from 11.5 days to 6.7 days, and attributes the gain to tighter feedback loops, faster reviews, and agents handling routine work in parallel. That is a company measuring itself; the useful part is the mechanism, which you can check against your own cycle-time baseline.
Atlassian's implementation: coding agents connected to the Teamwork Graph through a CLI, with each session's decisions written back to the graph so knowledge compounds across teams rather than staying in one repository.
Review: Agents on the Critical Path
The friction
Manual review is a standing bottleneck. Pull requests sit for hours or days, scrutiny varies from reviewer to reviewer, and code is checked for correctness while the intent and requirements behind it are not validated until staging or production.
The shift
Agents sit on the critical path for review, so pull requests move in minutes instead of days. Engineering standards are encoded into shared context and applied continuously to new and existing code. Human reviewers still make the call, but they arrive better informed, with the routine feedback already handled.
Build first
Versioned review rules, risk-tiered review, and traceability from each pull request back to the ticket and spec that shaped it, so the reviewer can check what was asked against what was built. Never let an AI approval stand in for the human one.
Faster review is only a gain if review depth holds. Faros AI's 2026 telemetry, covered on the Productivity Paradox page, found pull requests merged with no review up 31.3% and incidents per pull request up 242.7%, so track no-comment merges per tier alongside review latency.
Atlassian's implementation: platform leads define, enforce, and monitor standards centrally, and its AI reviewer works alongside third-party tools such as Cursor to catch gaps between what was asked and what was built.
Maintenance: From Reactive to Governed Loops
The friction
Maintenance is reactive and labor-intensive. Engineers triage production errors by hand, read stack traces, and route tickets between teams. Capacity is finite, so KTLO and reliability work keeps losing to new features, and technical debt and operational risk pile up.
The shift
Maintenance becomes proactive. Agents classify incoming errors and draft a root-cause analysis before a person engages, escalating only when needed. Routine maintenance, dependency updates, and recurring fixes go to autonomous coding agents, so the backlog stops growing and engineers move to higher-value work.
Build first
The safe work classes for unattended agents, the rule that a bug fix starts with a failing test, and an audit trail of what each agent loop did and why. This is the Curate phase.
Atlassian reports that agent loops in Jira automatically resolve 51% of its potential vulnerabilities, leaving engineers the work that needs human judgment. The word that matters in its description is "governed": loops that are scoped to well-defined work, apply the same standards as people, and write every action back to the system of record.
Atlassian's implementation: incident triage in Jira Service Management, with governed agent loops that scan the backlog and codebase for well-defined KTLO work and turn backlog items into pull requests.
Five Moves for Engineering Leaders
The report closes on a warning that matches the Playbook's first rule: an AI-native SDLC is an operating-model change. Leaders who treat it as procurement - picking agents, licensing models, switching IDEs - should expect incremental gains at best. Its five recommended moves, in order:
Anchor on context
Treat connected, permission-aware organizational context as the foundation. Without it, every workflow shift underperforms.
Invest in measurement early
Put quantitative and qualitative feedback loops in place before scaling adoption, so a real productivity gain can be told apart from hype.
Choose one starting workflow
Pick the stage where AI-native work unlocks the most value for your teams, and go deep there before broadening.
Preserve accountability
Keep people clearly in charge of judgment, quality, and governance while AI handles execution and enforcement. The agent loops that scale are governed ones: scoped, standards-aware, and recorded in systems of record.
Build the operating model, not just the toolkit
Update rituals, roles, and success metrics alongside the tools. The biggest gains come from how AI changes the way teams work together.
Moves two and three line up with the Rollout Playbook: a baseline in the first three weeks, then one workflow at a time with exit criteria. Move four is the Governance page's ownership model in one sentence.
How the Pillars Map to AIDLC
| Pillar | AIDLC phase | Go deeper |
|---|---|---|
| Context | All five - the shared input to every phase | Context Engineering |
| Measurement | All five - the feedback loop around every phase | Measuring Impact |
| Planning | Analyze, Ideate | Engineering Practices |
| Design | Ideate, Develop | Prompt Library |
| Development | Develop | Agent Orchestration |
| Review | Develop, Launch | AI Code Review at Scale |
| Maintenance | Curate | Agents in the Pipeline |
Reading the Vendor Numbers
The three figures on this page - 44% more accurate with 48% fewer tokens, issue cycle time from 11.5 to 6.7 days, and 51% of potential vulnerabilities resolved by agent loops - are Atlassian's measurements of Atlassian, published in a report that also positions Atlassian's products. None has been independently replicated.
That does not make them wrong. It makes them hypotheses. The framework - context and measurement first, then one workflow at a time, with people accountable for judgment - is portable to any toolchain, and the honest way to use the numbers is to write down your own baseline and see whether your version of the change moves it. The Research Library lists this report beside the independent studies so you can weigh them side by side.
Frequently Asked Questions
Two platform investments and five workflow shifts. The platform investments are context - a connected, permission-aware graph of code, work, documents, and decisions that agents can query - and measurement. The workflow shifts are planning, design, development, review, and maintenance. Systems of record tie them together, and what the workflows capture feeds back into context and measurement.
No. An instruction file is a short set of repository rules an agent reads every session. A context graph connects code to the work items, documents, decisions, owners, and dependencies around it, behind a permissions layer, so an agent can ask who owns a method or which services depend on it. Start with instruction files; a context graph is the organizational layer above them.
With context and measurement, then one workflow. Establish a baseline and feedback loops before scaling adoption, pick the stage where AI-native work unlocks the most value for your teams, and go deep there before broadening. Keep people accountable for judgment and governance throughout, and change rituals, roles, and success metrics alongside the tools.
Start With One Workflow
Score where your organization stands today, then pick the one workflow where an AI-native change would move your baseline most.