Want real AI transformation? Stop tinkering at the edges and fix the system

5 June 2026

AI adoption has entered a critical phase. Organisations now need to step back and reconfigure how they work to avail of its benefits.

Craftsman v3

For the past few years, AI transformation has largely been about early-stage adoption - getting people comfortable with new tools, building basic competency and experimenting with new ways of working. That phase is coming to an end. 

While many organisations can point to genuine productivity gains, they have been largely limited to specific business units, most notably engineering - they are not reliably translating into higher organisational throughput.

In the case of software delivery, engineers are producing code faster than ever, but business and product are increasingly struggling to keep up. AI is improving parts of the system, but the system has not adapted accordingly.

Confronting some hard realities

This challenge is not unique to software delivery, but it is where the problems are surfacing first. Systems design, Theory of Constraints, whatever you want to call it, you cannot increase throughput of a system without first addressing its bottlenecks. 

After a sustained period of clearing down their sizeable backlogs at an accelerated rate, teams are now hitting the same wall - they can’t feed the machine fast enough. Business and product can’t keep pace with engineering. 

Which is forcing some difficult boardroom conversations: do we freeze hiring and decrease the size of the engineering function - surely we can do more with less, and the bean counters need to find budget from somewhere for those increased token costs - or do we take the red pill and change the system?

A forcing function for improvement

AI has hit like a tsunami, but most organisations are still structured for antediluvian times. You’ve seen this play before - siloed teams separated by Chinese walls with discrete budgets, work handed off through formal approvals, slow cycle times, the wrong thing being built, etc etc. 

This was just about fine when every part of the organisation moved at roughly the same pace, but it’s no longer a sustainable operating model. Something needs to give. Actually, it wasn’t fine, but if AI has given us anything, it has been to act as a forcing function to drive improvement.

But AI is more than a forcing function. It exposes the good and bad at the individual and system level. It accentuates the positive without eliminating the negative. Those bottlenecks, long hiding in plain sight, have only become visible as the cost of coding has trended to zero. And they exist throughout the software delivery lifecycle, both upstream and downstream from coding. 

An entirely new rulebook?

It is tempting to believe that agentic engineering (and more widely, AI adoption) demands an entirely new rulebook and that this new rulebook will paper over the issues. In reality, two almost opposing ideas are true at the same time:

  • Traditional foundations still matter. Many of the disciplines and practices adopted by high-performing teams before the advent of AI still apply today. AI or no AI, the best teams deliver continuously and are optimised for flow, feedback and learning.
  • New foundations are emerging. The patterns and practices of how we use AI technology are still forming, and will do so for years to come. Undoubtedly, some of these practices will challenge received wisdom - they already are - but it will take time, research and evidence to prove that these new ways are indeed better ways.

Small batch sizes, rapid feedback loops and cross-functional ownership were valuable before AI and remain valuable now. The teams succeeding with AI are not abandoning these fundamentals - they are doubling down on them, even whilst they experiment and adopt new approaches within the overarching delivery system.

Fix the system, then optimise for AI

Organisations attempting to inject AI into a broken system will eventually hit the same proverbial wall. They therefore need to treat the delivery system as a whole - not as discrete units of “business” and “technology”, but as a single team, with a single, shared purpose. 

That does not mean that every enterprise needs to tear down the walls between business and technology. They can still run as separate units - after all, their activities don’t entirely overlap, but they do intersect. Both exist to serve the organisation and its customers. When tasked with working on a common business objective, they must park the us-and-them mentality and work together as a team, free of barriers and united by a shared culture, behaviours and values. 

Ultimately, this means creating a system of work that is a) optimised for what is important in driving business success (in software delivery, that is flow, feedback and learning), and b) geared towards continuously improving itself from within.

Small teams are showing the way

The most compelling examples of agentic delivery done well is coming from small teams. Two or three capable people with complete purview over a problem can now achieve outcomes that larger teams could only dream of in the past. 

Their advantage is not purely technological. It is the reduced friction and communication overhead that slows big teams down. It is the time being saved in ceremony and handoff, all that unnecessary performative ritual that kills productivity once more people get involved. 

With small teams, product and technology decisions happen in real time. Feedback loops are measured in minutes rather than weeks. Stuff just gets done. This is AI’s great gift - it’s freeing your best people to work in a way that they’ve always wanted to work, with less administrative nonsense and more value being delivered.

Transformation is a stack

There is obviously a lot more to AI transformation than simply fixing the system and optimising for AI. It needs to be built on a foundation of domain expertise and individual competency - I’ll cover this in an upcoming post - but the central point holds: don’t adopt AI over a broken system and expect throughput to “times X” in the long run. 

Yes, you will see some localised gains. You may even experience some short-term increases in throughput, but eventually the system will fight back. The true measure of throughput is the time it takes to go from concept to the customer saying thank you. All that messy stuff in between is where the real work is, and if any part of the system is dysfunctional, broken or slow, no amount of speeding up the rest of the system will improve overall throughput. 

The next phase of this collective AI transformation journey will have less to do with agents, models and prompts, and much more to do with fixing existing and antiquated operating models, organisational design and value streams. The winners will be the ones who focus on removing friction, shortening feedback loops and aligning business, product and technology around shared outcomes.

Tara Simpson

Founder / CTO