AI doesn’t fix a weak engineering team, it amplifies what’s already there: strong foundations get stronger, weak ones fail faster. That’s the finding from Google’s new DORA research, based on nearly 5,000 engineers. The teams gaining most from AI aren’t the ones with the best tools, they’re the ones who understand their systems well enough to catch AI’s mistakes.
AI can make your engineering team faster.
It can also make your engineering team’s problems arrive faster.
That is one of the most important findings in Google’s latest research into AI-assisted software development. Google’s DORA research programme, DevOps Research and Assessment, is separate from the EU’s Digital Operational Resilience Act. It has been studying software delivery and engineering performance for more than a decade.
Its 2025 report, based on responses from nearly 5,000 technology professionals, points to a conclusion that should make every engineering leader pause before measuring the success of an AI rollout purely by productivity.
AI is an amplifier.
It makes existing strengths more powerful. It can also expose existing weaknesses at greater speed.
The research does not suggest organisations should slow down their adoption of AI.
Quite the opposite.
Around 90% of respondents reported using AI at work, with more than 80% reporting a productivity benefit.
Developers are already using AI to generate code, explore unfamiliar codebases, write documentation, troubleshoot problems and accelerate parts of the software development lifecycle.
The question is no longer whether AI can make developers faster.
The more important question is what happens to everything around the developer when that speed increases.
DORA found a negative relationship between AI adoption and software delivery stability across the industry.
That sounds contradictory.
If developers are more productive, why isn’t delivery becoming more stable?
The answer is in the foundations underneath the development process.
DORA points to the importance of robust control systems, including automated testing, version control, and fast feedback loops. When AI increases the volume and speed of change, those foundations become even more important.
Put simply: if your engineering system can safely absorb faster change, AI can create significant value.
If it cannot, AI can make the consequences of weak foundations arrive faster too.
This is where the conversation needs to move beyond AI tooling.
An engineer who understands a system can use AI to work faster.
An engineer who does not understand the system can also use AI to work faster.
The difference is what happens next.
When an AI-generated solution looks plausible, someone still needs to decide whether it is appropriate. Someone needs to understand the architecture it is being introduced into. Someone needs to recognise when a technically valid solution creates a performance, security, maintainability or operational problem somewhere else.
That requires engineering judgement.
And engineering judgement depends on capability.
At Mallon, we see this pattern most often across current engagements in financial services and other regulated environments. One of the most common gaps is straightforward:
“The most common gap we see across current engagements is engineers who can describe systems clearly but can’t justify them. AI accelerates that gap rather than closing it. The teams pulling away aren’t the ones with the best AI tooling. They’re the ones whose engineers know why the system works the way it does, so they can spot when AI doesn’t.” — Mike Clarke, CEO, Mallon Associates
That is the distinction that matters.
Information tells an engineer what a system does.
Capability helps them understand why it works that way, and recognise when something is wrong.
Independent research is now pointing towards the same conclusion we see in engineering environments every day: AI does not remove the need for strong engineering foundations. It makes them more valuable.
For a financial services organisation, delivery instability is not simply an inconvenience.
Changes happen within complex technology estates, regulatory environments and operational processes. Systems often have dependencies that are difficult to see from the code alone.
Increasing the speed at which changes are produced does not remove those complexities.
It increases the importance of understanding them.
An organisation that introduces AI-assisted development on top of weak documentation, inconsistent testing or concentrated technical knowledge may find that it can produce changes faster without necessarily being able to assess those changes faster.
That is where the amplifier effect becomes important.
AI can increase throughput.
Engineering capability determines whether the organisation can safely absorb that throughput.
So what should organisations focus on?
Not less AI.
Better foundations around it.
Technical documentation is one part of that foundation. But effective documentation needs to capture more than what a system does. It needs to preserve the decisions, assumptions and reasoning that allow another engineer to understand the system properly. That is one reason contextual technical documentation and certification matter.
The same applies to developer onboarding and engineering education.
Engineers need to understand the environment they are joining before AI becomes another layer of abstraction between them and the technology. Practitioner-led learning gives them exposure to the systems, decisions and engineering practices that underpin the work they will eventually be expected to do independently.
AI can then become an accelerator rather than a substitute for understanding.
EThis also changes how engineering leaders should evaluate AI adoption.
If the only measures on the dashboard are lines of code generated, development time saved or tickets completed, it is possible to conclude that an AI rollout is succeeding while missing the more important signal.
What is happening to stability?
What is happening to defects?
What is happening to incidents?
What is happening to the amount of engineering time spent reviewing, fixing and explaining AI-generated output?
If change volume increases while stability deteriorates, the answer is not necessarily to use less AI.
It may be to strengthen the engineering foundations that allow the organisation to benefit from it safely.
That is the difference between adopting AI and becoming capable with AI.
The organisations that get the most from AI will not necessarily be the ones with the most advanced tools.
They will be the ones whose engineers understand the systems those tools are being asked to change.
That means building capability deliberately.
It means developing engineers who can question an answer rather than simply accept one. It means creating documentation that preserves organisational knowledge. It means giving new developers enough context to understand the environments they are joining. And it means creating opportunities for experienced engineers to transfer judgement, not just information.
None of this is theoretical for Mallon.
For more than three decades, we have worked inside complex financial services technology environments, including a continuous practitioner-led programme for a leading global investment bank that has been running since 1990.
The technology has changed repeatedly.
The underlying requirement has not.
Engineers still need to understand what they are working with, why it works the way it does, and when something does not look right.
AI can accelerate engineering.
But it cannot build that capability for you.
The organisations that understand that distinction will be the ones best placed to turn AI’s speed into sustainable engineering performance.
Building AI capability starts with understanding the foundations underneath it. For more than thirty years, Mallon Associates has helped financial services organisations build the engineering capability they need to operate in complex technology environments.
Every engagement starts with a conversation.
Talk to us about your AI engineering capability.
Michael Clarke is the Chief Executive Officer at Mallon Associates. With over two decades of experience, including deep technical expertise in C/C++, Java, and complex proprietary frameworks, Michael now focuses on technical leadership and scaling engineering operations for financial services firms. He is a recognised expert in developer onboarding strategy, dedicated to bridging the gap between high-level technology and sustainable business growth.