AI coding tools have made engineering teams faster. A working prototype that once took a sprint can now appear in an afternoon.
They’ve also shown that AI amplifies the expertise already in the team. Someone new to a domain can produce a convincing proof of concept. Turning it into a service that stays secure, performs under load and can run reliably 24×7 depends on engineers who understand what it takes to run production systems for real.
The gap between the two isn’t model capability; current models can write most of the code. The gap is in the delivery process around them: how work is specified and tested, what evidence it leaves and how much of it anyone can trust without reading every line.
An agentic software development lifecycle (SDLC) is a way of closing that gap. It changes who does most of the delivery work while keeping the engineering practices you already rely on. People still make the decisions that matter, and the workflow has to earn enough trust before anyone stops reviewing every diff.
What an agentic SDLC covers
In an agentic SDLC, AI agents carry out large parts of delivery while following your organisation’s own standards and processes. That can include drafting use cases and requirements, turning them into tests, writing the code that makes those tests pass and running the checks that decide whether a change can be released.
This goes further than a coding assistant in the IDE. A coding assistant makes individual engineers quicker at writing code. If nothing else changes, the extra code arrives at the same review queue, the same test environments and the same release process, and the constraint moves there. Many teams have watched their pull request queues grow since adopting coding assistants for exactly this reason.
Applying agents across the lifecycle deals with that constraint directly, because the same workflow that writes the code also produces the specification, the tests and the evidence that the change is fit to release.
The engineering practices stay the same
An agentic delivery process looks a lot like the practices high-performing teams already use: trunk-based development, continuous delivery, test-driven development, Clean Architecture and domain-driven design.
There’s still a backlog of work items. Code still goes into GitHub or another version control system. Continuous integration and continuous delivery (CI/CD) pipelines still build it, run the tests, apply linting and security scans, and block changes that fail.
What changes is who does most of the work. Agents pick up the work items, guided by workflow rules, and people are involved at the points where judgement is needed.
Teams with established engineering practices are therefore in a stronger position to adopt agents. The agents have tests to run against, boundaries to work within and standards to follow. Where those practices are missing, agents tend to reproduce what they find in the codebase, only faster, so putting the basic practices in place first is usually the better starting point.
Good architecture now has a running cost
These practices still keep a codebase manageable as it grows and make refactoring safe enough to do regularly. With agents doing the work, they also determine how many tokens each task consumes.
An agent has to read code before it can change it. If understanding a change means opening 20 files, tracing tangled dependencies and rereading modules whose purpose isn’t clear, the agent pays for that context in tokens on every task. A codebase that’s slow for a person to navigate is expensive for an agent to navigate, and that expense now appears on an invoice.
Clear module boundaries let an agent load the part of the system it needs and leave the rest alone. Small, cohesive modules keep the context for each change small. A dependency rule that predicts where a change will land means the agent doesn’t have to search for it. Architecture decisions that were once justified on maintainability alone now have a cost argument as well.
Tests behave the same way. A suite that runs quickly and fails with a clear message lets an agent make a change, check it and correct it without a person stepping in on each cycle. A slow or flaky suite uses more compute and pulls people back in to interpret the failures.
Line-by-line review was already under strain
The most common objection to agentic delivery is code review. If agents write the code and nobody reads every line, it looks as though an important control has gone.
In practice, thorough line-by-line review is already uncommon. Quick “looks good to me” (LGTM) approvals are routine, especially on large changes. A reviewer given 900 lines they didn’t write, with their own work waiting, will usually check the parts that look risky and approve the rest.
The research supports this. In SmartBear’s study of code review at Cisco, reviewers found defects most effectively on changes of under 200–400 lines, and their detection rate fell away beyond that summary. A Microsoft Research study of review across Microsoft teams found that reviews turned up fewer defects than developers expected, and delivered more of their value through knowledge transfer and team awareness (Bacchelli and Bird, 2013).
That isn’t a criticism of reviewers, or of teams that have built a strong review culture. Review spreads knowledge and catches real defects. But an approval records that someone looked at a change, not what they checked, so the assurance it provides has always been limited.
Agents make that limitation harder to work around. In Faros AI’s 2025 telemetry from more than 10,000 developers, teams with high AI adoption merged 98% more pull requests, while review time rose 91% and average pull request size grew 154% (Faros AI, 2025).
Scrutiny also slips as the volume grows. A 2026 study of 11,429 human reviews of AI agent pull requests, across open-source GitHub repositories over 7 months, found that reviewers approved more agent changes the more of them they had reviewed, while leaving 22% fewer inline comments (Yu et al., 2026). Another study of the same dataset found that most AI-generated pull requests received no review at all (Duma et al., 2026).
Requiring a person to read every agent-written line either slows the agents to human speed or turns review into approval at a much larger scale. The more useful question is what control should take the place of line-by-line review.
Review the workflow that produces the code
In an agentic SDLC, the main thing you review is the workflow agent itself: the rules it follows, the standards it applies, the checks it runs and the evidence it records. Assurance comes from examining that process, rather than inspecting each change it produces.
The level of rigour stays the same; it moves to a different place. A reviewer’s approval says a person looked at one diff. A workflow you’ve examined applies the same checks to every change and records that it did. It doesn’t get tired, and it isn’t under pressure to approve a change late on a Friday before a release.
It also changes where senior engineers spend their review time. An improvement to a workflow rule applies to every later change, whereas an hour skimming a diff affects only that diff.
Teams don’t start here on day one. Trust in a workflow is built the same way as trust in any other system: by running it, testing it, finding where it gets things wrong and fixing those cases.
Moving through the trust stages
Trust in an agentic workflow builds in stages. A team moves to the next stage when it has evidence that the workflow meets the condition for it, not after a set period.
| Stage | What the human reviews | What must be true to move on |
|---|---|---|
| 1 | Every line of the diff | The agent reliably follows your standards |
| 2 | The specification and the tests, with spot checks of the code | The tests faithfully cover the scenarios they claim to cover |
| 3 | The specification and the evidence chain | The workflow can be shown to turn a requirement into a test that can fail |
| 4 | The requirement, and the exceptions | The chain is complete, and the pipeline’s result is accepted as final |
Each condition in the right-hand column can be checked. “The team is comfortable” and “it’s been 6 months” aren’t conditions.
Teams also need to be clear about which stage they’re actually at. The usual failure is to stop reading code at stage 2 without having built the evidence chain that stage 4 depends on. The team then has neither review nor evidence, and tends to find out during an incident or an audit.
Most teams will spend time at stages 1 and 2 while the workflow proves itself. Different parts of a system can also sit at different stages. A team might rely fully on the workflow for internal tooling while still reading every line of a payments module.
Where people make the decisions
Human-in-the-loop is essential to an agentic SDLC. The aim is to give people the decisions that need their judgement and keep routine checking away from them. Those decisions fall into three areas.
Defining the specification. People decide the business requirements: the use cases and the behaviour each one should produce. An agent can draft requirements, refine them and point out missing edge cases or contradictions. It can’t decide what the business needs.
Recording significant decisions. Some decisions have consequences that outlast the people who made them, such as a data model, an integration pattern or a trade-off between consistency and availability. These are recorded as architecture decision records (ADRs), with the reasoning, so later engineers and agents can work within them rather than undo them by accident.
Signing off. A person judges whether a requirement has been met, meaning a user can now do what the requirement describes. Passing tests show that a requirement is ready to be judged. They aren’t the judgement.
People own intent, acceptance and significant decisions, while agents translate requirements into tests and code and carry out the work. For senior engineers, that means less time as a bottleneck on individual changes and more time on decisions with lasting effect.
Turning requirements into executable specifications
If people own the specification, it has to be written down properly. Requirements are a primary artefact in an agentic SDLC, rather than a ticket description read once before work starts.
You don’t need a new format. Use cases, actors and goals, and scenarios written as given, when and then are well-established practice. Agents work well with them because they’re structured: a scenario that names an actor, a starting state, an action and an expected outcome can be turned into a test with little interpretation.
The agent converts each scenario into a test, then writes the code to make the tests pass. Keeping requirements and tests in step is bookkeeping that tends to drift when done by hand, and an agent can check it on every change.
Agent-written tests have a specific weakness. A test can pass for the wrong reason: it was written after the code, or it asserts against a fixture built from the same misunderstanding as the implementation. The workflow then runs cleanly and confirms the mistake.
Two checks reduce the risk. Fixtures should come from outside the implementation, for example from real business examples or from data stated in the requirement. The workflow should also confirm that each test can fail, using a technique such as mutation testing, which changes the code under test and checks that the test catches it. A test that stays green when its code is broken provides no evidence.
The human-in-the-loop steps are what stop this reaching production. Because a person owns and signs off the specification, a test can only certify behaviour someone has agreed is correct. The checks above then confirm that the test genuinely exercises that behaviour.
The specification step also works in the other direction. In our experience, agents consistently read a use case more completely than it has been written down. They propose scenarios and acceptance criteria that the person writing it missed or hadn’t thought of: an error path, a boundary value, an actor nobody mentioned. The person still decides which of those belong in the requirement, but the specification that results is more complete than either would have produced alone.
Deliver in small increments
Agents don’t remove the need for small increments and fast feedback, so the workflow has to be built to support them.
Giving an agent a large part of the backlog and leaving it to run overnight is a tempting shortcut. Sometimes the result is good. Often it’s a large, plausible change built on an early misunderstanding that nobody was there to correct, and unpicking it takes longer than the time it saved.
The opposite risk is writing every scenario in detail before building anything. That’s a waterfall approach, and the information needed to write the scenarios well usually doesn’t exist that early.
An agentic SDLC doesn’t need a complete specification upfront. Agents can help refine it as the work progresses, proposing scenarios and flagging gaps, with a person reviewing and signing off each change. A practical loop looks like this:
- Specify a small piece of behaviour.
- Let the workflow build and test it.
- Review what it built and what you learned from it.
- Use that to refine the next part of the specification.
Small increments keep people involved often enough to steer the work, without asking them to review every step.
Compliance: validate the process, then inspect the evidence
Regulated organisations have to document their controls, implement them and show evidence that they’re operating. Many leaders assume that rules agents out, because an auditor will ask who reviewed the code.
Regulated industries already rely on validated processes rather than inspecting every output. In pharmaceutical manufacturing, the UK’s Medicines and Healthcare products Regulatory Agency (MHRA) inspects manufacturers against good manufacturing practice (GMP), including Annex 15 on qualification and validation, which also applies across the EU. It treats validation as documented evidence that a process will consistently produce a product meeting its specification. Quality is built in by validating and monitoring the process, rather than established by testing finished products alone.
These are manufacturing requirements, not rules for software delivery. The point is the principle: assurance comes from validating and monitoring the process, rather than inspecting every output.
Closer to software, ISO/IEC 27001 certification works the same way. In the UK, certification bodies accredited by the United Kingdom Accreditation Service (UKAS) audit whether an organisation’s information security controls are in place and operating, by examining evidence and sampling records rather than re-inspecting every change the organisation made. SOC 2 Type 2 reports, which some international customers ask for, rest on the same principle. If your customers already ask for either, you already work this way.
An agentic SDLC asks auditors to apply that familiar approach to a different process: validate the workflow, check that its controls operate and inspect the evidence it produces.
In a well-built workflow, controls are attached to requirements, and the evidence is produced as the work is done:
- a requirement stating the expected behaviour
- a test that covers a named scenario from that requirement
- a pipeline gate that blocks the build if the test fails
- a commit linking them, with a record of who signed off the requirement
When an auditor asks how a control is met, the answer can come from a query across that chain, rather than a search through tickets, wikis and email.
A reviewer’s approval usually records a name and a time. A linked chain from requirement to release records what was checked and how, which makes it more useful evidence.
This supports compliance; it doesn’t produce it. Your organisation still has to decide which controls its obligations require, and the workflow has to be validated against them. What changes is that much of the evidence is generated during delivery instead of being assembled before an audit.
Engineer the workflow like any other system
If the workflow is what you rely on, it needs the same engineering discipline as the software it produces. It has requirements, failure modes and regressions, and changing one of its rules changes how all later work is built.
Version its rules, test changes to it before rolling them out and watch for fixes that cause new problems elsewhere.
Use it on real systems with real users. A sandbox pilot with a sample application won’t expose the failure modes that matter, or the pressure to cut corners that comes with real delivery. Each trust stage is a claim about the workflow that only real use can support.
To serve more than one team, be strict about standards and flexible about how each project meets them. The standards are fixed: code is linted, types check, secrets are never committed and every requirement has a test. The choice of linter, framework and test runner belongs to each project.
Expressing standards as outcomes lets one workflow support several technology stacks. It also keeps the standards checkable, because an outcome can be verified, while a mandated tool only shows what was installed.
How Catapult CX builds agentic delivery
At Catapult CX, we’ve built and run an agentic SDLC on real client and internal work, and refined it as we went. It runs in alignment with our AI management system (AIMS), which has passed Stage 1 of ISO/IEC 42001 certification. Our engineers set it up in four parts.
Standards loaded into every agent session. Each agent starts every task with the same rules on how code is structured, tested and secured, so consistency doesn’t depend on who picked up the work item.
A delivery loop that keeps documents current. Requirements, decision records and documentation are updated as part of each piece of work, so they describe the system as it actually is.
Guardrails matched to the project’s stage. A new service and an established regulated platform need different controls. We set the guardrails for where the project is and record what’s still to be put in place, so nothing is skipped without anyone noticing.
An evidence chain from requirement to release. Every requirement links to the tests that cover it, the gates that enforce it and the change that delivered it, so audit questions can be answered from the chain.
We apply the same approach beyond delivery, to operational work. Agents pick up and process tickets, from service requests through to incidents, and others carry out the analysis and problem-solving behind them.
We work with your engineers to set this up, starting at the trust stage your team is genuinely at, and hand the workflow over so they can run and improve it themselves.
Case Study Results at a glance
- Audit preparation: weeks to days. An operational observation from the people who prepare Catapult’s audits, not an instrumented measurement.
- 45 requirements and 240 test files. The research platform, built entirely under the workflow between 26 August and 22 October 2026, with 39 decision records.
- 11.5-minute median ticket. Measured across 137 autonomous build runs from the agents’ own transcripts.
Read about our Agentic SDLC Case Study: AI Delivery & Compliance
Where to start
The prototype has always been the quick part. Getting from there to production depends on how work is specified, checked and evidenced. An agentic SDLC changes all of that while keeping the engineering practices you already have.
A practical first step is to work out which trust stage each of your systems is at, and what evidence would let the team move it to the next one.
Talk to an engineer about where agents could take on delivery work in your systems, and what you’d need in place first.
Frequently asked questions
What is an agentic SDLC?
An agentic software development lifecycle is one where AI agents carry out large parts of delivery, following your organisation’s own standards. That can include drafting requirements, turning them into tests, writing the code and running the checks that decide whether a change can be released. People still own the specification, significant decisions and sign-off.
Is an agentic SDLC the same as using a coding assistant?
No. A coding assistant helps individual engineers write code faster, and if nothing else changes, the extra code piles up in review, testing and release. An agentic SDLC applies agents across the lifecycle, so the same workflow that writes the code also produces the specification, the tests and the evidence that a change is fit to release.
Does it mean nobody reviews the code?
Not at the start. Teams begin by reading every line, and move to reviewing the specification, the tests and the evidence chain only as they gain evidence that the workflow can be trusted. The main thing reviewed shifts from individual changes to the workflow that produces them.
How do we know when we can trust the workflow?
Each trust stage has a condition someone can check, such as showing that the tests genuinely cover the scenarios they claim to. A team moves on when it can show the condition is met, not after a set period. Different parts of a system can sit at different stages.
Do we need to change our engineering practices first?
If you already use trunk-based development, continuous delivery, test-driven development and clear architectural boundaries, agents fit into what you have. If those practices are missing, agents tend to reproduce what they find, only faster, so putting the basics in place first is usually the better starting point.
Why does architecture affect the cost of using agents?
Agents have to read code before they can change it, and that reading is paid for in tokens on every task. Clear module boundaries and a predictable dependency structure let an agent load only what it needs. A fast, clear test suite also lets it check and correct its own work without a person stepping in each time.
Can an agentic SDLC be used in a regulated industry?
Yes, provided the workflow is validated and its controls produce evidence. Regulated industries already rely on validated processes rather than inspecting every output. A workflow that links each requirement to its tests, gates and sign-off gives auditors a clearer record than a reviewer’s approval. It supports compliance; your organisation still has to decide which controls its obligations require.
Can we leave agents running overnight on large pieces of work?
It’s better not to. Large unsupervised runs tend to produce plausible changes built on an early misunderstanding that nobody was there to correct. Small increments with regular human review keep the work on track and avoid the cost of unpicking a large change later.
