Most conversations about AI in engineering start with code generation.
Fair enough. Copilots and coding assistants have become normal in many teams. But when we started experimenting with AI internally, coding turned out not to be the most interesting place to look.
The bigger opportunity showed up earlier in the process.
Requirements.
User stories.
Test cases.
Documentation.
Release notes.
All the things that surround development.
A colleague recently presented an experiment where AI agents help drive these tasks across the entire development lifecycle. The goal was simple: see how far we could push automation before human review becomes the limiting factor.
The results were interesting enough that the team started discussing a larger question.
What happens when AI helps manage the entire SDLC pipeline, not just the code?
Anyone who has worked with agile teams knows the routine.
A feature idea appears. Then someone turns it into a user story. Someone else breaks it down into tasks. QA prepares test cases. Documentation gets updated later — sometimes much later.
None of this work feels optional. The process exists for good reasons.
Still, a lot of time goes into repetitive formatting and rewriting.
A product owner might spend half an hour structuring a user story. A QA engineer may spend an hour writing tests. Release notes usually come together right before deployment.
That work adds up.
During the presentation, one of the engineers put it simply:
“We spend a surprising amount of time describing software instead of building it.”
That observation became the starting point for the experiment.
Rather than asking one AI model to do everything, the team broke the workflow into smaller pieces.
Each stage of the lifecycle gets its own AI agent.
The agents follow instruction files written in markdown. Each file describes how that agent behaves, what context it should read, and what output format to produce.
Think of them as small assistants that understand one specific task.
The pipeline looks roughly like this.
Feature Idea
↓
Feature Agent
↓
User Story Agent
↓
Jira Agent
↓
Technical Analysis Agent
↓
Test Case Agent
↓
Documentation Agent
↓
Release Notes Agent
The agents connect to tools the team already uses:
Once the system has access to those sources, it can read existing tickets, scan documentation, and create new records automatically.
The experiment begins with something intentionally vague.
A short prompt describing a feature.
For example:
“We need a dashboard that shows project metrics and allows export.”
The feature agent reads that request and produces a structured response.
Instead of a single suggestion, it proposes alternatives.
Option A: a simple dashboard with basic metrics.
Option B: a more advanced analytics view.
Each option comes with a short explanation of trade-offs and possible implementation details.
At that point the product owner decides which direction makes sense.
From there the next agent takes over.
The story agent converts the selected feature into properly structured user stories.
Here’s a simplified example.
User Story
As a user
I want to export dashboard metrics
so that I can analyze them offline.
Acceptance Criteria
Edge Cases
Non-Functional Requirements
One practical detail the team appreciated: before generating anything new, the agent checks Jira for similar tickets.
Duplicate stories show up often in large backlogs. This step avoids adding more.
Once the stories look reasonable, the Jira agent handles the mechanical work.
It creates the epic, attaches the stories, and populates the required fields.
The links appear immediately on the board.
No one has to copy-paste descriptions or reformat text.
This part of the workflow felt almost trivial after a few runs.
Another interesting piece involves architecture analysis.
The technical analysis agent reviews the user story and scans the code repository if access is available.
It then produces a short technical note covering things such as:
It also proposes a rough story-point estimate.
One engineer mentioned that during internal tests the suggested estimates matched the team’s estimates roughly nine times out of ten.
The analysis does not replace design discussions. It works better as a second perspective during backlog refinement.
Testing turned out to be one of the biggest wins.
The test agent reads the acceptance criteria and generates a set of test cases automatically.
Example entries look something like this.
Test Case
Expected Result
Export metrics
CSV download begins
Empty dataset
system returns validation message
Unauthorized user
export blocked
Those tests appear directly in the test management tool.
The QA engineers noticed something useful here. The agent often suggested edge cases they had not thought about yet.
That alone made the exercise worthwhile.
Documentation usually falls behind development.
Everyone intends to update it. Deadlines tend to win.
The documentation agent takes a different approach.
It reads the new user stories and compares them with existing Confluence pages. If documentation does not exist for a feature, it proposes an update.
With one confirmation, the new content appears in Confluence.
No extra meeting required.
Release notes normally happen right before deployment.
Someone goes through Jira tickets and writes a summary.
The release notes agent handles that process automatically. It scans the tickets associated with a release version and composes the notes.
One small bonus: it also flags tickets that remain unfinished.
That simple warning helps teams catch problems earlier.
Precise numbers depend on the project.
Still, the team estimated rough comparisons.
Manual workflow:
Task Typical Time
User story creation 20–30 minutes
Test case writing 30–60 minutes
Documentation update ~20 minutes
Release notes ~15 minutes
AI-assisted workflow:
Task Time
User story draft ~10 seconds
Test cases ~15 seconds
Documentation summary ~20 seconds
Release notes ~5 seconds
The human still reviews everything. The mechanical work disappears.
After several weeks of experimentation, a few patterns emerged.
Context matters.
The system performs far better when it has access to documentation and source code.
Human review remains necessary.
AI produces drafts. Product decisions stay with humans.
Instruction files take time to tune.
The first versions rarely behave exactly the way teams expect.
Once the instructions stabilize, the workflow becomes predictable.
One of the engineers summarized the shift nicely during the discussion:
“AI won’t decide what product to build. Humans still own that.
What AI does well is filling the gaps around the work.”
In other words, product managers still define the feature.
AI helps shape the backlog and prepare the groundwork.
Developers then spend more time implementing and less time clarifying requirements.
Most headlines focus on AI writing code.
That part matters.
Another transformation may end up just as important.
AI now assists with the layers of work that surround software development:
Those tasks rarely get attention, yet they shape how quickly teams deliver software.
If the current experiments hold up, development teams may soon rely on AI not only as coding assistants, but also as workflow partners throughout the entire SDLC.
The experiment started as a small internal demo.
It may turn into a new way of running engineering projects.
Let's talk about where you are today and where you want to go - our experts are ready to help you move forward.
