Over the last few decades, software engineering has continuously evolved through improvements in the tools, practices, and environments we use to build software. We moved from manual deployments to automated pipelines, from on-premise infrastructure to cloud platforms, from siloed delivery teams to product-focused ways of working. Each shift changed not just the technology, but also how teams worked together and how organisations delivered value.
AI is another significant shift, but I think it is different from many of the changes that came before it.
The reason is that AI is not simply improving the tools engineers use. It is beginning to change the relationship between an idea and the software that implements it. For much of my career, a significant part of software delivery has involved translating intent into execution: understanding a problem, designing a solution, writing code, testing assumptions, and iterating until we create something valuable.
AI is starting to compress parts of that process.
This is clearly exciting. The opportunity to reduce repetitive work, accelerate delivery, improve quality, and help teams solve problems faster is significant. But the more interesting question for me is what happens when the ability to create software increases faster than our ability to decide what software we should create.
Because many of the constraints we experience in software organisations have never really been about writing code.
They have been about alignment, decision-making, understanding customer needs, managing complexity, creating shared context, and building organisations that can continuously learn.
This is why I think the impact of AI on software engineering will be much broader than the tools we adopt.
A team can have access to the best AI assistants available and still struggle if the organisation around them is not designed to take advantage of them. If teams are unclear on outcomes, if decision-making is slow, if architecture creates friction, or if governance relies on manual processes, AI will not remove those constraints.
In some cases, it may actually make them more visible.
When the cost of producing software decreases, the cost of producing the wrong software becomes more significant. When teams can deliver more quickly, the importance of choosing the right problems to solve increases.
The bottleneck moves.
This changes what we need to think about when we talk about engineering capability.
Technical skills will continue to matter. Understanding systems, architecture, quality, security, and reliability will remain essential. But the capabilities that differentiate effective engineers and leaders will increasingly include curiosity, judgement, communication, and the ability to work across boundaries.
The engineer of the future will not just be measured by how much code they can produce. They will be measured by how effectively they can understand complex problems, use the capabilities available to them, and create outcomes that matter.
This is not a new idea. The best engineers have always done this. They have always been problem solvers rather than simply code producers.
AI just changes the environment in which those skills are applied.
For technology leaders, this creates a different challenge.
The question is not only how do we introduce AI tools into our organisations?
The more important questions are:
Do our teams have the operating model required to benefit from these capabilities?
Do our platforms and architectures reduce friction or create it?
Do our governance practices enable responsible experimentation?
Do we have enough organisational adaptability to absorb this change?
This is why I believe the future of software engineering is not primarily a tooling problem.
It is an organisational design problem.
The organisations that benefit most from AI will not necessarily be the ones that adopt the technology fastest. They will be the ones that have built the foundations that allow people, teams, and technology to work together effectively.
AI may change how we build software.
But our ability to benefit from it will depend on how well we have designed the organisations that build it.