The AI SDLC: Shipping Software With Agents in the Loop

The developers who felt faster

In early 2025 the research group METR ran a careful study. Experienced open-source developers worked on real issues in projects they knew well, sometimes allowed to use AI tools and sometimes not.

With AI tools allowed, they took 19 percent longer to complete issues. The result went against what the developers themselves expected and what experts had forecast.

METR has since said it is changing its study design, and the tools have improved. One study is not the final word.

But the gap between feeling faster and being faster is the point. It is easy to see the code appear and hard to see the time spent checking, fixing, and re-explaining it.

That is why an AI software process needs measures, not impressions.

What Google's DORA research found

DORA, Google's long-running research program on software delivery, looked at AI in its 2024 report.

It found that AI adoption raised individual productivity, flow, and job satisfaction. It also found that a 25 percent increase in AI adoption was associated with an estimated 1.5 percent drop in delivery throughput and a 7.2 percent drop in delivery stability.

The report's reminder was about fundamentals. Small batch sizes and robust testing remain crucial.

Read the two findings together. AI makes it easy to produce more code, faster, and larger changes are harder to review and more likely to break something.

So the job is not to add AI to the old process. It is to change the process so the extra code arrives in small, tested, reviewed pieces.

What an AI SDLC looks like

The software development lifecycle is the sequence every change goes through: plan, build, review, test, release, and watch.

In an AI SDLC, agents do more of the work inside each step. They draft a spec from a ticket, write code against tests, suggest tests, and summarize what changed.

People own the gates between steps. A person approves the scope, reviews every change before it merges, and decides when it ships.

Keep the batches small. An agent that changes three hundred lines across ten files has produced something nobody can review properly.

And keep the tests first. Code written against tests that already exist is far easier to trust than code with tests written afterward to match it.

For how this looks with one specific tool, see Claude Code in the enterprise.

Prove, Transfer, Scale

Most rollouts go wrong in the order of operations. A tool gets licensed for everyone, usage climbs, and nobody can say whether delivery improved.

Prove. Pick one team and one kind of work, such as bug fixes or small features. Measure for a month before and a month after: how long changes take, how often they break, how much rework they need.

Transfer. Write down what the first team learned: the instructions given to the agent, the review checklist, the kinds of task that worked and the ones that did not. A second team runs that playbook with the first team's help.

Scale. Only when two teams have shown the same result do you roll it out widely, with the same measures and guardrails.

Each stage has a question. Does it work, can someone else make it work, and does it keep working at size?

Choose the first kind of work carefully. Good starting points are tasks where mistakes are easy to spot and cheap to undo: writing tests for existing code, small bug fixes, documentation, and routine updates.

Poor starting points are tasks where mistakes hide: security-sensitive code, billing logic, and large changes across many parts of the system.

Start where the review is easy. Move to harder work only after the team has learned what the agent gets wrong.

Write those lessons down as you go. The list of what the agent misunderstood is the most valuable part of the playbook you will transfer.

Guardrails that do not slow you down

Every change gets human review. Code review is the gate that catches what the agent misunderstood. Make it required, not optional.

Small batches only. Set a size limit for agent changes. Large changes get split before review, not after.

Least privilege. Agents get access only to what the task needs. No production credentials, no secrets in prompts, no permission to merge on their own.

Tests run on every change. If the tests do not run automatically, the agent is building on sand.

Easy rollback. Release in small steps with a clear way back. The cost of a mistake is mostly the time it takes to undo it.

None of these is new. They are the fundamentals DORA keeps finding matter, applied to a faster producer of code.

"Our developers say it makes them much faster."

They may be right. They may also be in the gap the METR study found, where people expected to be faster and were not.

You do not have to choose between believing them and doubting them. Measure.

Track three numbers per team before and after: time from start to release, how often releases cause problems, and how much work gets redone.

If all three improve, you have a result to transfer. If speed improves but problems rise, the batches are probably too large or the review too light.

For the cost side of the same question, see controlling AI token spend.

What to read next, and why

METR's early-2025 developer study (research summary): The careful study behind the 19 percent finding, with its limits.

Announcing the 2024 DORA report (Google Cloud blog): The delivery throughput and stability findings on AI.

DORA 2024 report page (DORA): The fundamentals, small batches and testing, that still decide results.

Code review (encyclopedia entry): The human gate every agent-written change should pass.

So the simple takeaway is this: pick one team, measure a month before and a month after, and do not roll out further until the numbers, not the feeling, say it works.