To ship software with AI agents, redesign the workflow rather than adding an agent to the old one. Write small, clear tasks. Let the agent draft. Have a named person review every change. Run automated tests as a gate. Measure rework and failure rates, not output volume. Teams that do this get the benefit. Teams that skip it get faster bugs.
This is the day-to-day version of the idea. It is written for owners and engineering leads who want a workable routine, not a theory.
Key takeaways
- Redesign the workflow around AI agents instead of adding them to the old one: small tasks, written specs, mandatory review and automated tests.
- DORA 2025 describes AI as an amplifier of existing team practice, so fix review and testing habits first.
- Measure lead time, change failure rate and rework, not lines of code or tickets closed.
- Keep a named human accountable for every merged change.
01Why Does the Workflow Matter More Than the Agent?
Because the agent amplifies whatever it is placed inside. DORA's 2025 research found AI adoption now near universal and described AI as an amplifier of team strengths and weaknesses. It also reported that throughput has risen while delivery instability has risen with it (DORA 2025 report).
McKinsey found a similar pattern outside software. Its AI high performers were nearly three times as likely to have redesigned workflows (McKinsey, 2025). The lesson transfers: the tool is not the lever.
An agent amplifies whatever it is placed inside.
02What Does an AI-Agent Delivery Workflow Look Like?
Think of five stages, each with an owner. The table shows a version that works for a small team.
Adjust the gates to your risk. A payments module deserves stricter review than an internal report.
| Stage | What happens | Human owner | Gate |
|---|---|---|---|
| 1. Spec | Write the task in plain sentences with acceptance checks | Product owner or lead | Another person can restate it |
| 2. Draft | Agent proposes code and tests for a small slice | Engineer | Slice fits in one reviewable change |
| 3. Review | Engineer reads the diff line by line | Reviewer who did not write the prompt | Reviewer can explain every change |
| 4. Test | Automated tests and checks run | CI pipeline | Failures block the merge |
| 5. Release | Staged rollout with monitoring | Release owner | Rollback tested |
03How Big Should a Task for an AI Agent Be?
Small enough that a person can review it in 15 to 20 minutes. That is our working rule, and it is a judgement, not a research finding. Large agent-written changes are hard to review honestly, and review is where the value is protected.
Stack Overflow's 2025 survey shows why. 66% of developers named solutions that are almost right but not quite as their top frustration (TechRepublic, summarising the survey). Almost right is the hardest kind of wrong to spot in a long diff.
04What Should You Measure When Agents Join the Team?
Measure outcomes the customer feels. Lead time from idea to release. Change failure rate, meaning the share of releases that need a fix. Time to restore after a failure. Rework, meaning how much merged code is rewritten within a month. Avoid counting lines, commits or tickets, because agents inflate all three.
METR's trial is a reminder to measure rather than trust impressions. Its developers believed AI made them 20% faster while the clock showed 19% slower (METR, July 2025). METR's 2026 update says speed-ups are likely larger now, but its data is weak evidence for how much (METR, February 2026). Time your own team before and after.
19%
Measured slowdown for experienced developers using AI tools in METR's 2025 trial, who believed they were 20% faster
05What Should Never Be Delegated to an Agent?
Production credentials, final approval of a release, decisions about what to build and anything involving customer money without a human checkpoint. OWASP's excessive agency guidance recommends minimum permissions, human approval for high-impact actions and logging of tool activity (OWASP LLM06). The same logic applies to a coding agent with access to your repository and your servers.
We cover the guardrails in more detail in agentic engineering explained.
06How Do You Introduce This to a Small Team?
Pick one low-risk project for a month. Write the five stages on a whiteboard. Time the baseline first. Hold a 30-minute retrospective weekly and note where review caught problems. After a month, keep what worked and drop what did not.
If you outsource delivery, ask your studio for its version of this workflow in writing. Ours is built around the checks in the 6-pass audit. To compare notes on your own process, talk to us.
07What Does Review Look Like When an Agent Wrote the Code?
It looks like review of any code from a colleague you do not yet fully trust, with one change: the reviewer must be able to explain every line to someone else, because the author cannot be questioned about intent. If a reviewer cannot explain a block, it goes back with a request for a simpler version, or it gets rewritten by hand.
Ask reviewers to check three things first. Does the change do what the task said and nothing more? Do the tests assert behaviour that matters, or do they merely pass? Did the agent touch files, settings or dependencies outside the task? Unrequested changes are the most common surprise, and they are easy to miss when the diff is long.
Frequently asked questions
They write small, clear tasks, let the agent draft code and tests, review every change by hand, run automated tests as a gate and release in stages with monitoring.
No. They shift effort from typing to specifying and reviewing. A named person must still understand and approve each change.
Lead time, change failure rate, time to restore and rework. These show customer impact, unlike lines of code or ticket counts.
Give it minimum permissions, keep production credentials away from it, require review and tests before merge, and log what it does.
Not without human approval. Keep release authority with a named person and a tested rollback.