How to adopt AI into your software delivery - 6 principles to guide success
24 June 2025
Artificial intelligence is radically changing how we develop software and the speed at which we deliver value. For engineering leaders, the challenge is no longer should we but how do we adopt AI effectively.

AI adoption isn't a free lunch. At its best, it can amplify your team’s skills, accelerate delivery and reduce the time to value. But at its worst, it can magnify bad habits, degrade quality and erode critical thinking. The difference lies in the strength of your current engineering culture and how effectively you integrate AI into it.
If you are about to roll AI tools out across your teams in the hope that it will address some of your core cultural challenges, or that all your engineers will suddenly become 10x overnight, then you are setting yourself up for a fall. First, stop, take a breath and consider the following six principles to guide successful adoption.
1. Foundations - focus on core competencies
People with a strong understanding of their jobs use AI more effectively. If your teams are struggling with doing the simple things well, AI won’t make things any better. If anything, it will make things worse by accelerating the amount of poor choices, technical debt and flaws in your codebase. Remember, AI amplifies ability and inability.
AI will help your people move faster, but moving faster requires more discipline, more automation, more pairing, more checks, and more balances - not less. Investing in AI tools requires that you also invest more in your people and processes. Start by giving them the baseline skills to drive AI, not just ride it.
2. Mindset - keep AI human-centric
AI is not an authority or a substitute for judgement, human creativity or critical thinking. It can assist with all three, but it works best when used in a human-centred way, to enhance our abilities, not replace them.
The danger in throwing too much at the machine is that your team's cognitive and critical thinking skills diminish over time. Human-centric does not mean offloading most or all 'thinking' to AI. It’s a balance of staying in control of the wheel and leaning into the technology as heavily or lightly as the situation requires - AI is not a crutch.
“Anyone not using AI is a fool. Anyone who only uses AI is a fraud.” Gregor Hohpe
Your challenge is making sure every single team member finds the right balance between these 2 extremes - they must remain accountable for their decision making and in control of the wheel at all times.
3. Measure - what matters
Adopting any new technology - especially one as powerful as AI - should never be done blindly or without understanding its broader impact. AI is no exception; in fact, it demands even greater scrutiny. While AI may be transforming how we write software, it hasn’t changed how we measure good engineering. The core metrics still apply and must remain central to your adoption strategy:
Quality: Is application stability and code quality dropping as a result of adoption?
Velocity: Are you delivering customer value faster, not just coding faster?
Experience: Are your developers happier or are the tools adding unnecessary friction?
Any drop in these is a potential red flag that AI is not quite having the intended impact and that interventions may be required. Use these metrics as your compass and recalibrate as needed.
4. Context - your mileage will vary
There is no universal “right way” to use AI. It varies by industry and context. However, there’s a general correlation between how much you care about quality, and how much you’re prepared to throw at AI - the more you care, the more cautious you should be. It’s a sliding scale.
On one end, developers increasingly strive to write as little code as possible when building proof of concepts or prototypes, preferring to let AI do the bulk of the work. On the other end, large, mission-critical codebases, often developed over years by many hands, can expose the limits of LLMs, which can often offer incorrect or misleading guidance.
Broadly speaking, AI is proving highly valuable for early-stage prototyping, greenfield development, and application scaffolding. But it still falls short with large, legacy systems, highly regulated or safety-critical environments, and tasks requiring deep domain-specific knowledge.
So, adjust your use of AI to fit the context. Embrace it where speed and experimentation matter more than structure, but apply caution where accuracy, reliability, and long-term maintainability are critical.
5. Optimise - the entire system, not just coding
Writing code is only one step in the software delivery lifecycle. If your requirements capture, security reviews, testing procedures, or any one of the umpteen other activities required to deliver great software are constrained, then producing code faster won’t lead to faster overall delivery.
The hardest part of developing software is not coding. It's people, process, requirements... the messy, collaborative skills required to feed the machine. Focus on optimising the entire system of work, not just one activity within it. Otherwise, you risk applying AI to the wrong constraint, and wondering why delivery hasn't improved. Coding is not the bottleneck.
6. Share - build an internal community
We are still in the early days of AI-enabled software delivery. The tools are evolving rapidly, and everyone is learning as they go. Most of us are still at that forming/storming/norming stage, figuring out our relationship with the technology.
But it takes time. You can’t just switch the tooling on and expect everyone to be magically proficient from day one. You need to build an internal mind share of how to get the most from these tools - the patterns and techniques that enable engineers to fly.
Start with the folks who drive your engineering culture. Their insights and lessons will be invaluable and need to be shared intentionally and freely. Equally, the whole team should be exploring this new frontier, willing to share what works, and critically evaluate what doesn’t.
Adopt, without fear
Your goal with AI adoption isn’t to replace what makes us good engineers. It is to enhance your teams’ core capabilities and to free them to focus on what matters — designing better systems, solving harder problems and creating better user experiences.
But to succeed, teams must learn how to balance the competing tensions of offloading and staying in control. Adoption must remain human-centred and tailored to your specific context and objectives. Get that balance right, and your teams will thrive.