If you've spent any time at technology conferences recently, you've probably heard the same story repeated over and over again.
AI is transforming everything. Teams are delivering ten times faster. Organisations are achieving extraordinary ROI. The future has already arrived.
And yet, talk to engineering leaders afterwards tends to be a little different.
There's curiosity. There's excitement. But there's also scepticism.
Because for many organisations, those transformational stories simply don't match their day-to-day reality.
At Dootrix, we've spent the last two years deliberately transforming how we build software. That journey has given us a useful perspective on where the industry really is, where it isn't.
Despite the headlines, relatively few software organisations have fundamentally changed how they build products.
Broadly speaking, we see four stages of AI maturity.
These organisations haven't developed a strategy.
Developers may be experimenting individually with tools like Claude or ChatGPT, but adoption depends entirely on personal enthusiasm rather than organisational direction.
You'll often see this reflected in recruitment too. Engineering roles still describe software development exactly as they would have three years ago, with no mention of AI capabilities or expectations.
This is probably where the majority of organisations sit today.
Leadership understands AI matters. Teams are encouraged to experiment. Friday afternoons become "AI time". Knowledge-sharing sessions begin to appear.
But there isn't a clear operating model.
Adoption is inconsistent, standards don't exist, and concerns around job security can create resistance rather than momentum.
This is where much of today's AI FOMO lives.
More mature organisations have moved beyond experimentation.
They know AI works. They want consistent ways of using it. They want governance, shared tooling, common practices and repeatable delivery.
The challenge is no longer convincing people AI is valuable.
It's working out what good actually looks like.
Very few organisations have reached this point.
These businesses aren't simply using AI to write code faster.
They've redesigned how software gets built.
Specialist teams own AI capability. Internal standards exist. Engineering revolves around harnesses, context engineering, reusable skills and continuous improvement rather than individual prompting.
Most importantly, they've recognised that AI changes the operating model—not just developer productivity.
Many organisations begin by asking:
"How can AI make our existing development process faster?"
It's a reasonable question.
It's also the wrong one.
The real opportunity isn't making today's SDLC 20% more efficient.
It's recognising that the SDLC itself is changing.
Modern AI engineering shifts the role of developers away from manually producing code towards designing systems that consistently generate high-quality software.
The focus becomes:
In other words:
You're no longer building the software.
You're building the software factory.
One of the biggest misconceptions is that AI adoption will naturally spread through an organisation.
In reality, it rarely does.
Every successful transformation we've seen has required deliberate investment.
That means:
This becomes the new business as usual.
Perhaps the hardest conversation for leadership is recognising that AI changes more than developer workflows.
It changes roles.
The highest-value engineers increasingly spend their time:
Communication, product thinking and systems design become even more valuable than writing elegant code.
The best engineers become multipliers.
This may be the most reassuring insight of all.
Despite the constant stream of AI success stories, relatively few organisations have completed this transformation.
Most are still experimenting.
Most are still looking for standards.
Most are still trying to work out how AI fits into software engineering.
The important thing is whether you've started the journey.
Because organisations that deliberately invest now will spend the next two years building capability.
Those that wait may find themselves trying to catch up with competitors who have already redefined how software gets built.
The future of software engineering isn't about doing today's work faster.
It's about fundamentally changing what software engineering looks like.