Lately, our team at TitanApps has been experimenting with an AI-native SDLC in Jira. We wanted to go beyond using generative AI for individual tasks and see which parts of our process agents could run on their own. One of the first results is a workflow that takes care of the sprint and release routine for the team behind Smart Checklist - one of TitanApps' process management solutions.
The workflow we set up creates sprints and versions and adds work items to the right release. A Rovo AI agent then prepares work item summaries and release notes, so release documentation is ready right when the team needs it.
In this article, we show how this workflow is configured, step by step, with the prompts and automation rules behind it. We also cover other Jira AI features worth trying and the limitations to keep in mind.
What Makes an SDLC AI-Native?
Definition: An AI-native SDLC is an approach to software delivery built around AI agents as regular contributors. Agents powered by large language models (LLMs) handle hands-on tasks in each phase of the software development lifecycle, from specs to release notes and maintenance. People define the direction, review what agents produce, and approve the result.
This is different from AI-assisted work, which most teams already practice. For example, when a developer asks Claude to explain a stack trace or gets draft code from an AI code assistant. Such things raise developer productivity on individual tasks, but the process around them stays unchanged.
An AI-native SDLC reshapes the process itself. In practice, this involves:
- Agent-ready work items. Descriptions and acceptance criteria leave no room for guessing, so an agent can act on them
- Agents in the team's workflow. Agents pick up work through the same assignments as people and can also be triggered from status transitions and automation rules
- Frequent checkpoints. The team reviews agent output at every stage instead of waiting until the release
Six Stages of an SDLC: Traditional vs. AI-Native SDLC Approaches
The new software development lifecycle still covers planning, design, development, testing, documentation, and deployment. What changes is how work gets done. Here's how traditional processes compare with an AI-native workflow, including practical examples from Atlassian tools.
Stage | Traditional SDLC | AI-native SDLC | AI-native SDLC with Atlassian tools |
|---|
1. Plan | Product managers gather requirements, prepare specs, and break work down manually. | Agents ask clarifying questions, combine customer needs with project context, and create plans that coding agents can execute. | Jira Planner asks clarifying questions, drafts a Confluence plan, and creates agent-ready work items with acceptance criteria and repo links. You can also draft specs and work items in Rovo chat. |
2. Design | Designers prepare mockups and hand off static specifications to developers. | Agents can turn design intent into interactive prototypes and implementation tasks. People review and refine the result. | Figma Make and Claude Design can help create designs. Figma for Jira links them to work items; Figma MCP lets coding agents read them. Loom can turn a recorded design walkthrough or feedback into an agent-ready prompt. |
3. Build | Developers write and integrate code, usually working through tasks sequentially. | Coding agents can implement multiple well-scoped tasks in parallel, using requirements and team standards as context. | You can assign a Jira work item to GitHub Copilot, Codex, Cursor, Claude, or the Jira Coding Agent. Claude Code can also connect through Atlassian's MCP server. |
4. Test | Developers and QA engineers write tests, run checks, and investigate failures. | Agents can create and run tests, compare results with acceptance criteria, and suggest fixes. People approve the final result. | The implementing agent can also write integration tests. With Playwright MCP and Atlassian Rovo MCP, Claude can read Jira acceptance criteria, run browser tests, and update the work item. |
5. Document | Teams manually (or in an AI-assisted way) summarize changes, maintain technical documentation, and write release notes. | Agents can prepare summaries and documentation from the work completed, with human review before publication. | Rovo agents can turn Jira work items and connected GitHub context into issue summaries, Confluence pages, and release notes. |
6. Deploy and maintain | Teams manage releases, investigate failed builds, and handle recurring maintenance work. | Agents and automation can handle routine release tasks, investigate incidents, and suggest fixes while people retain approval checkpoints. | Rovo Dev can analyze failed Bitbucket Pipelines builds and suggest fixes. Coding agents can also help address vulnerable dependencies flagged by Dependabot. |
In our team, we review AI output at each critical checkpoint, from requirements through code and tests to final approvals:
As you can see from the overview table above, agents are a critical part of any AI-native SDLC flow. Jira allows you to work with a wide range of different agents, from its native out-of-the-box Rovo agents to third-party agents (such as Claude) and to custom agents that you can configure yourself in Atlassian Rovo Studio.
In the example that we cover in this article, we share a workflow that is based on using Rovo agents and other AI features offered by Atlassian.
Hands-on Example: Automate Sprint and Release Management With Rovo
Teams working in Scrum go through the same release routine with every sprint. They create a new sprint and version, add finished work items to the correct version, and turn tickets into readable release notes. Each step is quick, but together they take time away from product work.
Our Product Lead, Oleksandra Sokol, decided to hand this routine over to AI and automation. The setup she built now runs for the Smart Checklist team. Oleksandra also showcased it as a speaker at ACE Chernivtsi 2026, an Atlassian Community Event, and the online ACE Stuttgart 2026 event.
The setup relies on two kinds of automation, each doing what it's best at:
- Classic Jira automation rules handle the predictable part: new sprints and versions, fix versions, and status changes.
- A Rovo agent handles the part that requires judgment: reading work items, summarizing changes, and writing release notes.
The image below shows how these responsibilities are divided:
This split lets you keep predictable operations in automation and use Rovo for tasks that need context and judgment. Here's how to configure the workflow in six steps.
Step 1: Map the Workflow With Rovo
We started by mapping the complete workflow in Rovo Studio before opening the automation editor. You can describe the process in plain language and ask Rovo to draft the agent and rules.
In our example, the prompt covered four Jira events and what should happen after each of them:
Rovo answered with a draft of the agent and a written outline of every automation rule. After checking this outline, we asked Rovo to create the rules themselves.
Starting this way gives you a plan to review before anything runs on your Jira site, so you can spot gaps early.
Step 2: Create an Agent in Rovo Studio - One of Jira's Key AI-native SDLC Features
Rules can move work items around, but they can't explain what a work item changes for users. That takes reading, interpreting, and writing, which is a job for a Rovo agent.
Think of a Rovo agent as an AI teammate with a single job description. You configure it once in Rovo Studio, and then you can call it from the chat, from a work item, or from an automation rule.
When you build your own agent, its configuration has three parts:
- Instructions: the agent's role, the way it should approach tasks, and the expected output format.
- Knowledge: the sources it may consult, including the Teamwork Graph that links context from Jira, Confluence, code, and connected apps.
- Tools: the actions it's allowed to take, such as creating a Confluence page, posting to Slack, or commenting on a work item. You can also add skills, which are reusable multi-step instructions built on these tools.
For example, you can name the agent Sprint & Release Manager and connect it to the organizational knowledge it needs. This is how we configured ours.
We gave Rovo a short brief covering:
- the format of the release notes
- the sources to analyze, including comments and linked work items
- how to interpret work item types, with stories as user-facing features and tasks as technical improvements
- a strict rule never to make up details missing from the work item
Rovo can turn this brief into detailed instructions, with principles like "be skeptical" and "quality over quantity." Here's how they appear in our Rovo Studio, alongside the original brief:
Step 3: Automate Sprint and Version Setup
Not every step needs an AI agent. Creating a sprint follows predictable logic, so you can use a classic Jira automation rule for this part.
We configured the first rule to trigger when a sprint starts. It creates the next sprint and a matching release version. We use a smart-value variable to keep the numbering consistent.
As a result, the next sprint and version will be ready when the team needs them.
Step 4: Add Work Items to the Release
Complete release notes need every shipped work item in the right version. However, people often forget to set the fix version by hand, especially for small bug fixes.
The second rule removes this risk. Each time a work item reaches the Ready for Testing status, the rule sets its Fix versions field to the next unreleased version. Because the first rule creates a version for each sprint, this is the version of the sprint in progress.
Step 5: Add a Rovo Agent to an Automation Rule - Another Step Crucial for an AI-native SDLC
With the third rule, the agent joins the workflow. Once a work item enters the Ready for Release status, the rule adds a comment explaining what this work item changes.
Jira automation offers two ways to add AI to a rule:
- Use Rovo sends a prompt that you write inside the rule itself
- Use agent calls a preconfigured Rovo agent that already has its own instructions in Rovo Studio
You can start with Use Rovo and place the full prompt inside the rule, as we did initially:
We found two drawbacks to this approach:
- The prompt lived in one rule only, so no other rule or chat could reuse it.
- The comments appeared under a person's name rather than the agent's, making attribution confusing.
To avoid both issues, you can move the prompt into the Sprint & Release Manager agent's instructions and switch the action to Use agent. The rule then needs only a short request, and comments appear under the agent's name:
This switch turns a classic rule into a building block of an AI-native SDLC. The agent's knowledge lives in one place and works wherever you call it. Here's one of its comments on a work item:
Step 6: Let a Rovo Agent Write Release Notes
Releasing a version in Jira triggers the fourth and final rule in our AI-native SDLC workflow. It does three things:
- moves every work item in the version to the Released status
- asks the Sprint & Release Manager agent to write notes covering all these work items
- saves the notes to the version description
After the rule finishes, the notes are available on the release page:
Every statement in these notes comes from the work items of that version, so you can always trace it back to its source.
Lessons From Our AI-Native SDLC Setup
Based on this experience, here's what we'd recommend to teams building their own AI-native SDLC:
- Let Rovo chat draft the agent instructions. A brief from a person who knows the process works better than a prompt written from scratch.
- Store instructions in the agent, not in the rule. One well-configured agent can serve several rules, Rovo chat, and individual work items. When the process changes, you update it once.
- Keep predictable steps in classic automation. Rules handle sprints, fix versions, and status changes reliably, while the agent focuses on reading and writing.
- Add one rule at a time. Give each new rule several sprints, adjust the instructions, and only then move on. A short feedback loop like this catches weak spots early.
- Review what the agent writes. The agent's instructions forbid made-up details, but someone on the team still needs to read the summaries before each release.
- Monitor rule runs in the audit log. Getting a workflow like this right usually takes a few rounds of testing. The audit log of each automation rule lists every run with its status, such as "Some errors" or "Config change," so you can spot failed runs and fix them quickly.
The result for our team is far less manual release work. And because the workflow runs in Jira, summaries and release notes stay close to the work items.
Pro Tip: Use checklist templates to make your AI-native SDLC processes more robust
The more code agents write, the more important it becomes to check it against clear standards. In our team, we keep these standards as checklist templates in Jira. A checklist template is a reusable list of steps or criteria for a recurring process, such as code review, Definition of Done, or regression testing. We create these templates with our solution, Smart Checklist for Jira, and add them to work items.
Here's what this gives our team:
- Consistent quality criteria. Every work item goes through the same checks, whether a developer or an agent did the work.
- Less manual setup. Smart Checklist can add the right template to new work items automatically, for example, a Definition of Done to every story.
- Clear progress. Reviewers and QA engineers can see at a glance which checks are done and which are still open.
For example, our Definition of Done checklist covers everything a work item needs before it counts as finished. The items range from code coverage and peer review to documentation and deployment. With this checklist in every work item, it's easy to confirm that nothing was skipped before a release.
Our code review checklist gives reviewers one set of criteria for every pull request, including architecture, maintainability, security, and performance. This matters more now that AI coding agents open more pull requests than before. A shared checklist keeps each review thorough, however many of them land in the queue.
There's another benefit for teams working with agents. Smart Checklist keeps each checklist as Markdown in a Jira custom field, so AI assistants connected to Jira through Jira MCP can read it. For example, a coding agent working in Claude Code can compare its changes with the Definition of Done and fix obvious omissions before review.
Underused Jira AI Features You Should Try
Our workflow uses several of Jira's AI capabilities: Rovo Studio, Rovo chat, a Rovo agent, and AI steps in automation rules. However, Jira has more to offer for an AI-native SDLC. These features weren't part of our example, but they're useful to know when you design your own setup:
- Agents in the Assignee field. Jira lets you pass a work item on to an agent in the same way you would assign it to a colleague. A coding agent, for example, can take a minor bug and come back with a draft pull request. To make a Rovo agent assignable, turn on the Work items surface in its Rovo Studio settings.
- Agents on workflow statuses. An agent can be linked to a status or a board column. Dragging a work item to that column / transitioning to that status then starts the agent automatically.
- Agents in the work item view. For a single task, you can start an agent from the Agents menu of any work item. For example, it can condense a lengthy comment thread.
- My agent sessions. This view on Jira's For You page lists every agent session in one place, including the ones waiting for your input.
- The Agentic Engineering template. With this template, you get a new Jira space where workflows, statuses, and agent steps are already set up.
There's no need to adopt all of them at once. Start with the one that fits your most repetitive task.
Third-Party AI Agents in an AI-Native SDLC
Atlassian's own agents and the ones you build in Rovo Studio aren't the only options. Marketplace vendors also create AI agents that work with their apps' data in Jira. Such agents bring app-specific information into the same AI workflows and extend what an AI-native SDLC can cover.
For example, our team built an AI agent that works with our solution, Smart Checklist for Jira. You can call it in Rovo chat and ask it to:
- find work items by checklist status, such as checklists with items assigned to you or checklists that aren't completed yet
- show checklist progress for all work items in an epic
- create a checklist template, like a Definition of Done, and save it for one space or globally
This way, you can see how far your team has progressed without opening each work item. For instance, before a release, you can check the checklist progress of every work item in the release epic. A short prompt is also enough to turn a recurring process into a reusable template.
The agent works with checklists like this one, which our team adds to Jira work items:
You can find example prompts and more details in the Smart Checklist agent documentation.
Downsides of Implementing an AI-Native SDLC in Jira
AI capabilities in Jira are evolving quickly, but there are still limitations to consider when you plan an AI-native SDLC:
- Limited control over agent permissions. Not every agent lets you decide exactly what it can access. Claude Agent for Jira, for example, works with one configuration for the whole site. After an admin connects it, people can assign work to it or @mention it from any work item . Each session then runs with the same GitHub service account. As a result, the agent can work in every repository this account can reach, no matter who started the session. Rovo agents offer finer control because they can run on their own agent account, with access limited to specific apps and spaces. However, an admin needs to set this up first. Otherwise, a Rovo agent runs on the account of the person who triggers it and inherits all their access.
- Compliance limits in regulated environments. These depend mostly on the platform rather than on a specific agent. Rovo agents aren't available in Atlassian Government Cloud. On HIPAA-enabled sites, you can ask Atlassian Support to provision Rovo chat and Rovo agents. However, some tools, such as the Rovo MCP Server and Rovo CLI, aren't HIPAA-compliant yet. Third-party agents can add their own limits. For example, Claude Agent for Jira doesn't support zero data retention.
- Guesswork on vague tasks. Agents act on what they receive. If a work item lacks key requirements, the agent fills in the blanks with its own assumptions and builds based on them. Running in the wrong direction still costs you tokens and can be costly.
- A heavier review load. Agents can produce code faster than teams can check it. According to Tricentis' 2026 Quality Transformation Report, 6 in 10 organizations report deploying untested code. In addition, 30% say the amount of AI-generated code is too large to test fully. As this volume grows, a consistent review and testing process becomes essential.
That's why it makes sense to start your AI SDLC with low-risk processes, like release documentation, and keep people in the loop.
AI-Native SDLC FAQ
Is an AI-Native SDLC the Same as an Agentic SDLC?
In most discussions, yes. Both terms describe a lifecycle in which AI agents carry out a large share of the work under human supervision. The difference lies in focus. "Agentic SDLC" highlights the agents and what they can do. "AI-native SDLC" highlights the process: roles, checkpoints, and metrics are designed around agentic AI. Some sources also use the shorter term AI SDLC.
Which AI Coding Agents Work in Jira?
Jira lets you hand work items to GitHub Copilot, Codex, Cursor, Claude, and Atlassian's Jira Coding Agent. Atlassian also offers Rovo Dev, a coding agent that works in Jira, the IDE, the terminal, GitHub, and Bitbucket. Developers who prefer Claude Code can connect it to Jira through the Atlassian Rovo MCP Server. For a comparison of some of these options, see our article Claude AI Agent in Jira: Full Guide and Use Cases.
Can Rovo Agents Run Inside Jira Automation?
Yes. The Use agent action adds a Rovo agent to a rule as one of its steps. The prompt can include smart values like {{issue}}, and the next actions can reuse the agent's answer through {{agentResponse}}. In an AI-native SDLC, this is the simplest way to combine agents with classic automation.
What Do CLAUDE.md and spec.md Files Do?
Both files give coding agents context that's stored alongside the code:
- CLAUDE.md contains persistent instructions for Anthropic's Claude Code, such as coding standards and common commands. Claude Code reads it automatically when a session starts.
- spec.md is part of spec-driven development. In GitHub's Spec Kit, it describes what a feature should do, while plan.md outlines how to build it.
In our workflow, the instructions of the Rovo agent serve a similar purpose for tasks inside Atlassian apps.
Do AI Agents Replace Code Review?
No, but they can make reviews faster. Rovo Dev, for example, can check pull requests in Bitbucket and GitHub against the acceptance criteria of the linked work item. Still, the decision to merge belongs to your developers. To keep reviews consistent as AI-generated pull requests pile up, a shared code review checklist helps.
