Most engineering leaders are past the point of wondering whether their teams should have AI tools. They already do. Claude Code, Cursor, Copilot, a few experiments in flight, a handful of people getting strong results.
The harder question is what happens next.
That was what came through in our recent expert session with DiUS Principal Consultants and Software Engineers Serge Matheson and Warner Godfrey. The audience questions showed where the pressure is building now: not around access, but around confidence, scale, and what ‘good’ actually looks like once teams start moving faster.
Serge put the core problem plainly: engineering leaders often mistake access to the tools for a valid operating model. He shared an example from a large organisation that had standardised on an AI coding tool, paid heavily for tokens, but after two months the delivery results were still underwhelming. The problem was not the tool. It was everything around it.
That is the shift leaders need to make now. Tool rollout is not the milestone. The real work is deciding where AI should improve delivery, which workflows it should change, and what has to move around it for that improvement to stick.
The bar has risen
One of the first questions was really about what good looks like now.
Leaders are seeing maturity models, agent demos and bold claims about where AI-assisted engineering is heading. Warner’s answer was helpful because he pointed out what those models tend to leave out. They can show a path, but they say much less about the conditions needed to get there safely. And that matters, because once teams move beyond simple tool use into more agentic ways of working, the challenge changes.
Do not use individual productivity as the benchmark. Use delivery performance. The real test is whether teams can handle more complexity, move faster, and still improve outcomes in a way the business can trust.
Serge made a related point from the delivery side. In many teams, one or two engineers get dramatically faster, but testing, review, product decisions and operations still move at the old pace. That is where things start to wobble. Not because the tool is bad, but because the rest of the system has not caught up.
That also means looking beyond code generation. In the session we mapped where AI is already affecting delivery across the lifecycle: shaping requirements, exploring design options, scaffolding and refactoring code, generating tests, supporting operations, and helping teams understand legacy systems.
The more useful move is not to spread AI everywhere at once, but to start where faster iteration is most likely to create real delivery value.
Agents increase pressure before they create relief
A few questions circled the same issue from different directions: multi-agent workflows, permission checks, review load, and what happens when you relax control in order to move faster.
Warner’s answer was pretty direct. Running agents without permission checks is risky, and should not be taken lightly. The technical reason is straightforward enough: AI vendors have offloaded responsibility to the user. Without applying least privilege to your agents, bypassed approval checks are dangerous.
If your delivery system already relies on rubber-stamp reviews, brittle test suites, or long pre-release verification phases, agents will expose it. Not in some abstract future-state sense. In queue length, delay and bottleneck terms.
Warner’s answer was not to slow down, but to push more evidence into the pipeline before human review: stronger automated tests, static checks, dependency scanning and clearer signals that a change is safe.
If you want to use more agentic workflows, move validation earlier. Break work into smaller units. Make pipelines do more than move code, use them to prove a change is safe before it reaches review.
Warner also used an analogy that stuck with me. If you are driving faster, the risks go up, so you drive to the conditions. You do not unleash an agent into highly regulated code and hope for the best. You start in lower-risk areas and build confidence from there.
That is really a sequencing decision. Start where the cost of being wrong is lower, and where the team can learn quickly.
Confidence is becoming the real leadership problem
Serge came at the same issue from a different angle. He described a kind of “cognitive debt”: code that works, but that nobody really understands. The problem is not just bad output. It is output that quietly becomes harder to own, reason about and safely change later.
You need confidence in your delivery pipeline. If something passes through it, it should be genuinely ready for production. And you need metrics that tell you whether the team is actually delivering more value, not just generating more activity. Adoption metrics may tell you whether people are using the tools, but delivery and quality metrics tell you whether anything is actually improving.
Hold generated code to the same standard as human-written code. If a reviewer cannot explain what it does, or why it is safe, it is not ready.
Warner made a similar point from the architecture side. The more modular and loosely coupled the codebase, the easier it is for humans and AI to comprehend. That is not a new software principle. But it matters more when you are increasing the frequency of change.
Use architecture to decide where to start. Well-bounded, lower-risk parts of the system are often where teams can move fastest and learn most safely. In more tightly coupled or heavily regulated areas, the same tooling can create more review overhead than delivery benefit.
Warner also pointed to a broader enterprise challenge: getting enough context across a distributed fleet of services to reason about cross-cutting change. That is where architecture, context and safe access to organisational knowledge start to matter just as much as the coding tool itself.
Use engineering discipline as the control system for AI-assisted delivery. AI does not remove the need for it. It raises the cost of not having it.
This is not just an engineering story
One of the better audience questions asked how to involve non-engineers, the business analysts, designers and product owners, who often see AI as something just for coding. That question matters because it exposes another bottleneck. If only engineering gets faster, the rest of the delivery system stays slow.
Serge’s answer here was one of the most practical in the session. If you want BAs and product owners to contribute in ways that strengthen delivery, give the tools access to the product value signals that matter. That might be through an MCP server. It might be through reports or outputs AI can reliably consume. But the idea is the same: if outcome data is part of the context, it becomes easier for non-engineering roles to use AI in ways that connect to product decisions, not just documentation or admin work.
He also gave a simple example that sticks. A client had put in place a traffic light system for contributions. Red meant leave it alone unless you really know what you are doing. Green meant a non-technical contributor could safely make progress there.
If you want broader participation, those kinds of safe lanes matter. Teams need clarity on where experimentation is fine, where extra review is needed, and what context people need in order to use AI well.
Structure matters more than access
Late in the session someone asked whether organisations see better success when they provide in-process guidance and coaching, instead of just opening up a buffet of tools and leaving teams to self-serve.
Warner didn’t hesitate. Yes, you will get a very large token bill if you do it the second way.
That line got a laugh, but the point was serious: experimentation without structure is just a more expensive way to rediscover the same problems.
Serge made the same point with another good comparison: rolling out AI tools and expecting delivery impact is a bit like installing Jira and expecting agile ways of working to appear. The workflow does not change itself. What does work, in the examples discussed, is process guidance: exemplar teams, visible patterns, constraints that make work easier to verify, and coaching aimed at actual bottlenecks rather than generic prompt tips.
The goal is not tool access on its own. It is repeatable workflows that improve delivery.
During the session we shared a simple pattern we’ve seen work well with teams:
- Start with a real delivery bottleneck.
- Try one AI-assisted workflow in that area.
- Measure the impact using existing delivery metrics.
- Capture what worked as a pattern.
- Scale that pattern across teams.
That is a much more useful place to begin than trying to transform everything at once.
If you want the fuller discussion, including more on measurement, skills, workflow design and where teams are seeing traction, the webinar recording is available.
And if your organisation is trying to move from scattered experimentation to an approach that scales, we can help. DiUS works with organisations to assess their current maturity in using generative AI for software delivery, identify where it can create the most meaningful value next, and apply practical patterns that make that value repeatable across architecture, delivery and team practice.
