In this article
If you're expecting a coding tool to make the whole organisation deliver faster, it's worth following a change beyond the developer's laptop. The code might be finished sooner and still spend most of its time waiting for review, testing or approval. The tool can be doing a good job while the delivery date barely moves.
I think we need to distinguish between two modes of using AI in the software development lifecycle, often abbreviated to SDLC. One helps people work faster within the process they already have. The other changes that process, along with the responsibilities and ways of working around it.
I'm calling these Mode 1 and Mode 2. Both have a place, but they involve quite different amounts of change. We should be clear about which one we're asking a team to adopt before deciding what we expect to get back.
Mode 1 works within the existing process
In Mode 1, the team still works from its usual backlog, reviews changes in the usual way and follows the same release process. AI helps people with the work along the way.
Think about picking up a bug in a part of the application you don't know well. You might ask an agent to explain the relevant code, work through a possible fix with it, then have it draft tests for you to check. You're responsible for understanding and maintaining the result, but you've spent less time finding your way around. The same approach can help turn a rough requirement into something the team can discuss, or bring the documentation up to date as the code changes.
People can learn on real work without having to reorganise the team or renegotiate every approval first. They still need guidance on what they can give the tools access to and how to check the output, but the disruption is relatively small.
The gains in delivery time are likely to be more modest than the improvement in any one task. If the change still waits for a test environment and a specialist review, making implementation faster only removes part of the delay.
That doesn't make the effort wasted. Less repetitive work and easier access to knowledge can improve a developer's day and leave more time for the difficult parts. For some systems, that may be enough to justify the investment. I wouldn't change a delivery model just to earn an AI-native label.
Mode 2 changes the way the work gets done
Mode 2 asks how we'd organise delivery if we expected AI to do a substantial part of the work. That means looking at the handoffs between people and teams, as well as what happens inside an editor.
For example, once the product owner and engineers agree what a change needs to achieve, an agent can help develop the plan and implementation using the same approved requirements and design decisions. Tests and policy checks run as the work progresses. By the time a reviewer gets involved, they have the proposed change, the test results and the questions that still need an answer. The next stage can use that work directly, rather than someone having to explain it all again.
AWS's AI-DLC method describes one approach to this, with AI proposing and breaking down work while people validate the decisions. You don't need to adopt every part of a new methodology to use that idea.
There are operating-model decisions here that a tool rollout won't resolve. Who maintains the agent workflow? Who owns the requirements it works from? Which checks can run automatically, and who can approve a release? Product, engineering, security and operations need to work through those questions together.
This is where I see the potential for a much bigger improvement. We can reduce the time spent handing work over, reconstructing context and waiting for someone to perform a repeatable check. However, getting there takes effort. Teams need reliable tests, shared instructions and time to learn how to delegate and review the work.
I'd plan for delivery to slow down while people adjust. Expecting the existing commitments to carry on unchanged while the team learns a new way of working is a good way to make the transition harder than it needs to be. The bigger gain is possible, but it still has to be demonstrated in your environment.
Where does the time go?
Take a team that starts producing changes faster while the security reviewers are already fully occupied. The queue grows. Reviewers either need more time or come under pressure to give each change less attention. If releases also depend on a weekly approval meeting, finishing on Tuesday instead of Thursday may make no difference to when the change reaches users.
This is the problem described in Anthropic's SDLC playbook. The surrounding work has to keep up with implementation. Start by limiting the work entering the queue and making changes easier to review. Adding more agents at that point can leave the organisation with more unfinished work and very little improvement in delivery.
So where else can AI help? Before anyone starts coding, there's often work in finding the relevant requirements, tracing dependencies and understanding why something was designed a particular way. An agent can help assemble that information and expose questions the team needs to settle. That gives engineers a better starting point, and may avoid building something on a mistaken assumption. Choosing the problem and making the important design trade-offs still belongs with the people responsible for the product.
An agent can also suggest test cases we might have missed, but a test that simply confirms the behaviour of its own generated code isn't much reassurance. We need tests that check what the feature is supposed to do. The same applies to review. As OpenAI's engineering team guide points out, finding a real problem can make a review take longer. That's still valuable. The avoided defect and rework should be part of the business case, even when the pull request didn't move any faster.
There's also useful work after release. Keeping runbooks current, gathering release evidence and relating an error spike to a recent deployment can save time that would otherwise be spent moving between tools. Suppose an agent identifies that deployment as a possible cause and recommends a rollback. The designated incident lead needs to approve the rollback before it happens, with the proposed action, evidence and approval recorded. The agent's permissions should prevent it from skipping that decision. Similar care is needed when changing production data, access or infrastructure.
The best starting point depends on the system. If changes mostly sit in review, make them smaller and give reviewers better evidence. If nobody is confident about changing a legacy application, start by documenting dependencies and testing the behaviour that needs to stay the same. Those are different problems, and they need different investments.
Making it work for more than one person
An effective workflow shouldn't depend on having its creator nearby to explain how to use it. The next engineer needs to be able to pick it up, understand its limits and get a result they can check.
That means keeping the instructions and context somewhere the team maintains. Agents need the right requirements, current architecture decisions and working build and test commands. If two documents disagree, someone needs to decide which one is authoritative. Microsoft's article on agentic delivery extends this across the lifecycle, connecting the original goal with the implementation, validation evidence and what happened in production. Collecting all of that is only useful if it helps the next task go better.
The platform needs the same attention. Teams should have an easy way to use approved tools and isolated environments, with suitable data access. Permissions, secrets, logs and spending limits need to be handled consistently. Asking an agent to be careful doesn't carry the same weight as preventing it from taking an action it isn't authorised to take.
This is where Hypervelocity Engineering (HVE) is relevant. Its Research, Plan, Implement, Review cycle treats the platform as something we keep improving. Teams reuse approved environments and delivery patterns, with infrastructure and policy as code making the controls repeatable. Automated checks give reviewers evidence to work with. Findings from production then inform changes to the shared platform, so the next team benefits from what the previous team learned.
Each team shouldn't have to rediscover how to set up an environment, protect its data and prove a change is ready. A maintained platform gives them a consistent starting point without removing their responsibility for the decisions they make.
The product owner still owns the product decision, engineers still own the change, and someone needs to accept the production risk. Those people need time and enough understanding to exercise their judgement properly. They're the ones who will be accountable and dealing with the consequences.
Where I'd start
Before changing the process, follow a few representative pieces of work from request to production. Look at how much time was spent working and how much was spent waiting. Include the fixes, repeated reviews and effort from other teams. That will tell you much more about where AI could help than counting how much code it writes.
Mode 1 gives people a way to learn while that work is happening. Let them try it on tasks where the result can be checked and a mistake is manageable. Make time to share what worked, what didn't and when doing the task manually was easier. Otherwise, the useful knowledge stays locked in one person's head.
Where there's a worthwhile opportunity to change the process, pick something specific for a Mode 2 pilot. Routine dependency updates for a well-tested internal service would be one example. The owning team agrees which updates are eligible, the checks required and who approves a release. It can then replace separate ticket preparation, implementation and evidence-gathering handoffs with one supervised workflow that prepares the change, runs compatibility and security checks, and presents the results for approval.
For that to work, the agent needs the supported dependency versions, build and test commands, architecture constraints and examples of previously accepted updates. Keep those instructions with the code. When the pilot reveals a missing rule, update them so the next run benefits. Keep a route back to the existing process just in case.
Once that works, see whether someone else can use it and whether it holds up on less convenient examples. Recheck it when models, prompts or tools change. Allow for training and platform maintenance, and give people capacity to make the transition. A successful pilot is a reason to expand carefully, not a reason to assume every team will get the same result.
Measure whether changes reach production sooner, how long they wait and how much rework comes back. Check defects, reliability and the workload on the people reviewing and operating the system. Most importantly, did users get something useful? Code volume and accepted suggestions can explain tool usage, but they don't answer those questions.
Saved time also needs somewhere to go. You might use it to work through the backlog, improve quality, deliver more for customers or avoid additional hiring as demand grows. It creates capacity, which doesn't automatically become a cash saving. The cost of models, platform maintenance and review still belongs in the calculation.
I don't think every team needs to move through Mode 1 and graduate to Mode 2. The same team might use a redesigned workflow for routine maintenance and keep its existing design and approval process for a sensitive migration. Risk, the state of the system and how much change people can absorb all matter.
