One of my biggest areas of discomfort when projecting the impact of AI on software development is the role of the software engineer. If the maxim is true that any job guided by rules, patterns, or principles can be assisted, and eventually replaced, by AI, then most software engineering roles fall into that category.
The counterpoint is that while a large part of software engineering is the application of established rules and patterns, there is still a more sophisticated skill set in the development process that AI will likely struggle with for some time:
- Requirement gathering and needs translation.
- Creativity in design.
- Abstract problem-solving.
These require a more nuanced mindset and usually benefit from a long track record of experience, including failure. The problem, based on my own 35 years leading software teams for large multinational companies, is that we humans are far from perfect at these tasks ourselves. We have built such a complex abstraction layer between need and solution that even when we identify a simple requirement, we instinctively overcomplicate it with edge cases, overengineering, rigid SDLC methods, and a glut of self-imposed constraints.
The software engineer is not the only role in the process. Stakeholders, business analysts, project managers, architects, testers, and user-acceptance teams all bring their own views of what a great solution looks like, and those views are often misaligned with each other and with engineering goals. I have worked on countless projects over the years and can count on one hand the times everyone came away believing they got exactly what they wanted.
So yes, AI will not always improve the quality of software outcomes, but it will improve speed, and that matters. One thing I consistently see agreement on in the developer community is that AI enables faster turnaround, allowing teams to move quicker and reduce the loaded cost of software delivery. That speed and cost shift should also flow through to the other roles in the lifecycle.
Faster, cheaper software, even when it is not necessarily better, will be significant for two reasons. First, there is already high tolerance for speed over quality, compounded by the acceleration of change during this phase of digital transformation. Speed to market is key. Solutions that are 80% complete but first to market often beat solutions that are 100% complete but late. Second, the cost savings of AI-assisted development should not be underestimated. Teams that previously needed broad, generic features to remain commercially viable could instead deliver bespoke, tailored solutions and still remain financially sound.
Turning around a single customer's needs, rather than taking months to build for a broader customer base, could change the shape of software development and lead to a world of bespoke solutionisation. Pay less and get a faster solution that meets your needs fully, or pay more and wait for something that meets only part of everyone's needs. There are, of course, sectors where high quality thresholds are non-negotiable, such as air safety, healthcare, and financial services. But there is a much larger base where those thresholds are lower, and I expect this shift to AI-assisted, lower-cost, rapid bespoke software development to happen there first.
Then comes the real challenge: we humans, with our overly creative, overengineered, abstracted ways of working, might be the thing that slows all of this down. We could end up blocking the path to good-enough, rapid deployment of lower-cost bespoke solutions. So, ironically, rather than being replaced by AI, software engineers' biggest risk may be failing to adapt to the market's accelerating demand for faster, lower-cost, tailored outcomes. The very habits that made engineers valued in an age of complexity — rigour, thoroughness, defensiveness about scope — may become liabilities in an age that rewards speed and flexibility above all.