Individual engineers can get faster with AI-DLC quickly. Delivery does not automatically get faster with them.
The constraint shifts into the surrounding delivery system. Product decisions still need to keep pace. Generated changes still need to be reviewed. Context still needs to stay current. Automation still has to respect repository boundaries, quality controls and handover requirements.
Across DiUS, we have learned these lessons through client engagements and carried them into the way we now approach AI-DLC. The patterns below are practices we apply when the delivery context calls for them.
1. Match the harness to the client’s decision loop
Dallas Johnson, Senior Consultant Engineering, ran into this while introducing AI-DLC practices into a client engagement.
The team started with a detailed specification workflow. It could generate thorough artefacts quickly, but requirements were still developing through conversations and rough designs, and the people making product decisions were not always able to confirm those decisions at the same pace.
By the time feedback arrived, some of the specification work had already lost its value.
So the team stripped the workflow back. A lighter requirements interview surfaced open questions, a person reviewed the result before technical design, and another approval point sat before implementation.
That changed how we assess the right level of structure. We now match the workflow to the speed at which product decisions can actually be made.
Before choosing the workflow, we look for:
- who can confirm the requirement
- which decisions must be resolved before implementation
- when those people can review the work
- what happens when the requirement changes
If implementation moves faster than product decisions, some of that speed comes back as rework.
2. Keep unresolved product thinking out of the implementation loop
Carl Thompson, Lead Consultant Experience Design, draws the boundary one step earlier.
A vague feature brief still contains unresolved choices about the user problem, intended outcome, domain language and constraints. An implementation agent can keep moving, but it has to make assumptions to do it.
That is why we now keep exploratory product work separate from the implementation loop when the intent is still forming.
AI can still help shape the problem, test options and challenge assumptions. Implementation starts once there is enough clarity to describe:
- the outcome the feature should produce
- the users and important states
- the domain language
- the constraints that affect the design
- how the team will know the result works
We also keep feature slices small enough to clarify and review before they move into implementation.
3. Treat stale context as a defect source
If agents use documentation to make implementation decisions, stale documentation becomes a defect source.
That can include architecture guidance, domain language, repository instructions, setup documentation and other project rules. Once those sources drift from the working system, an agent can follow the guidance correctly and still produce the wrong result.
Sergei Matheson, Principal Consultant Engineering, experimented with a deliberately narrow maintenance agent.
On a schedule, it compared documentation with the code. Where they disagreed, it proposed a documentation change through a pull request. It could not quietly change the application to make the mismatch disappear.
We now use the same principle when the context warrants it: keep context maintenance inside a reviewable engineering control, and check guidance against the working system rather than assuming documentation is still authoritative.
For setup documentation, one of the simplest checks is still the most useful: run the commands.
If the documented setup fails today, it is no longer reliable context.
4. Put design behaviour somewhere the agent can read it
A static design does not tell an agent how a component behaves. It may show appearance without explaining responsive changes, interactions, transitions or which existing component should be reused.
That means the design context has to be made explicit when AI is part of implementation.
We use guidance such as:
- when to use one component rather than another
- responsive variants
- interactions and transitions
- structured design annotations
- product-specific component decisions
One approach Carl discussed was publishing that guidance with the versioned design-system package. Another is keeping it beside the component code in a monorepo.
The important part is that the instructions and the implementation move together.
Where contribution volume increases, we also revisit design-system governance so one designer or system owner does not become the next bottleneck.
5. Keep repository rules local when automation crosses boundaries
Dallas’s team was working across frontend, backend and infrastructure repositories. A change could start in one repository and require a related change in another.
The agent could reach the files. The problem was that it carried the source repository’s context with it, which meant the wrong verification commands, pull-request structure or local rules could follow the agent across the boundary.
The team moved feature-level coordination above the repositories.
The orchestration layer tracked the shared feature state and knew which repositories were involved. Each repository still supplied its own commands, branch conventions and pull-request practices.
We now preserve that separation when work spans repositories: coordinate the feature above them, but keep delivery rules local to each codebase.
6. Split generated work before review becomes the queue
Grace Wu, Lead Consultant Engineering, saw this with a change that touched around 50 files in a financial system.
The implementation could be produced as one change, but nobody could sensibly review it that way. The team split it into eight pull requests of roughly seven or eight files.
As Grace put it during the session, “human is the bottleneck.”
That lesson now shapes how we structure generated work. We keep feature slices and pull requests small enough to understand, separate changes with different risks, and place human review before expensive rework.
The same principle applies to generated artefacts. Requirements analysis, technical designs and test material can all be produced quickly, but someone still has to read and trust them.
If review is backing up, generating more output does not increase delivery throughput.
7. Ask whether the code should exist before reviewing how clean it is
James Menzies, Lead Consultant Engineering, starts his first AI code review with a different question:
“Should this code even exist?”
The first pass is deliberately adversarial. A fresh agent or model looks at the proposed change without carrying the same reasoning that produced it.
The questions are higher level:
- Is this the right change?
- Is this the right place for it?
- Is there a simpler approach?
- Has the solution made the problem larger than it needs to be?
We now use distinct review passes where that extra challenge is warranted, rather than asking every reviewer to do the same job.
The final decision still belongs to the team.
8. Find failures with agents, then make the protection deterministic
James also uses agents to explore APIs because they are good at trying combinations people may not think to test manually.
Give the agent a test environment, the API specification and the goal of the integration, and it can probe beyond the obvious happy path.
The same technique works against an API the team owns.
For example, an empty field combined with another empty field might produce a 500 where the contract should have returned a 400. A multi-step flow may fail only in one unusual state.
Once the agent finds a failure that matters, we turn it into a deterministic regression test.
James was clear on that point: “you should write deterministic tests.”
The agent helps find the gap. The delivery pipeline then checks that same gap every time.
9. Put limits around unattended loops before increasing autonomy
A human-orchestrated workflow naturally pauses because someone reviews the requirement, approves the plan or decides whether implementation should continue.
Once those hand-offs are automated, the system needs explicit conditions for when to stop, when to escalate and when to return control to a person.
For unattended loops, Sergei defines controls such as:
- a maximum cost for the run
- a time limit
- a retry limit
- restricted tools and execution environments
- conditions that require human intervention
We also make the run observable. The person responsible for it should be able to see what stage it reached, what tools it used, why it stopped and what decision is needed next.
If the loop cannot continue, it should fall back to a human-orchestrated path with enough evidence for someone to pick up the work without reconstructing the run from scratch.
10. Hand over the delivery harness with the software
On AI-DLC engagements, handing over the delivery harness is now part of the handover.
Grace’s team had built project skills for requirements analysis, technical design, implementation, review and pull-request creation. Those skills improved over time as the team used them and found where the instructions needed tightening.
If that work stays in individual developers’ environments, the client receives the software without the delivery practices that helped produce it.
So the shared skills were checked into the repository, where they could be versioned and reviewed during the engagement, then maintained by the client team afterwards.
Grace described them as “part of the assets that we hand over to the client.”
That handover needs to answer practical questions:
- Who owns the project skills?
- Who can change them?
- How are changes reviewed?
- What quality gates remain mandatory?
- What happens when the underlying model changes?
- Which parts are specific to this client and this codebase?
A client should not need the original DiUS team, or one developer’s local setup, to reproduce the way its software was built.
What these patterns have in common
The lesson across all ten is that faster implementation does not automatically produce faster delivery.
The gains only hold when the surrounding system can keep up: product decisions, context, review, repository rules, testing, escalation and handover.
These are the practices we now carry into AI-DLC engagements when the context calls for them.
The tools will keep changing. Our job is to keep testing what holds up, share those lessons across DiUS, and apply them where they improve the way the client team can deliver and own the work.
