You can see AI everywhere except in profit statistics

The 95% figure is by now well-known. MIT’s NANDA initiative found that around 95% of enterprise GenAI pilots have produced no measurable P&L impact, and in seven of nine major sectors heavy pilot activity has produced no structural change.[1]

Meanwhile there is an increasing scale of investment running alongside it. Enterprise AI spend tripled from $11.5bn to $37bn between 2024 and 2025.[2], while in Europe Eurostat recorded the largest year-on-year jump in EU enterprise AI use [3].

While spend on AI is rising, value capture is not. The burning question everyone has is — how can we make sure we’re one of the 5% that will get the “real value” out of AI?

To answer this, we need to understand why the value gap is appearing in the first place — and the history of enterprise tech offers clues.

We’ve seen this gap before

This same pattern emerged when computers were being introduced to businesses back in the 1970s and 1980s. Mainframes, minicomputers and PCs flowed into corporate America. IT investment surged through the decade. And yet US labour productivity growth slowed — from 2.9% per year in 1948–73 to just 1.1% after 1973.[4] In 1987, the Nobel laureate Robert Solow captured the mood of the era in a single line: “You can see the computer age everywhere but in the productivity statistics.”[4]

The paradox took roughly a decade to resolve. The empirical work that explained it - most influentially by Erik Brynjolfsson and Lorin Hitt at MIT and Wharton - found that the firms capturing real returns from IT were the ones that combined IT investment with deliberate organisational change: decentralised decision rights, team-based work, broader skills, redesigned business processes. Firms that did both saw productivity contributions from computerisation up to five times greater over five-to-seven-year horizons than over one-year horizons - a gap explained almost entirely by the time it took to make the complementary “organisational capital” investments alongside the technology.[6]

In other words: the technology didn't deliver the productivity. The reorganisation around the technology did. And it took roughly a decade because reorganising work is harder, slower, and more politically painful than buying technology. The US productivity surge of the late 1990s - when output per hour finally accelerated - is widely credited to the combination of IT diffusion with the business process reengineering wave that followed it.

We are in the early-paradox phase of AI right now. The investment is visible. The deployment is widespread. The productivity is largely absent. The lesson from the computer era is that the gap closes - but only when organisations do the harder work of reshaping how work gets done, not just which tools sit on the desks of the people doing it.

AI in software engineering is emerging as a break-away case

This diagnosis is backed up by evidence of where AI is now consistently producing results —the software engineering domain.

The Pragmatic Engineer’s 2026 developer survey reports 95% of developers using AI weekly, 56% for more than 70% of their work. AI-authored code is now around 26.9% of merged production code and time-to-tenth PR – a robust onboarding velocity metric – has halved between 2024-25 [7].

The explanation of why software engineering is the break-away case lies in how this function, unlike any other, has spent fifty years learning to reorganise itself - and it has two parts.

The muscle and the mode

One: the muscle for reorganisation. Software engineering has spent fifty years repeatedly restructuring how humans coordinate around the work, not just what tools they use. Waterfall, iterative, RAD, agile, lean, DevOps, platform engineering - each shift was a sociotechnical reorganisation: new roles, new handoffs, new team shapes, new ownership boundaries. While technology enabled the work; human coordination needed to change. And each shift compressed the feedback loop another order of magnitude - years under waterfall, months under iterative, weeks under agile, hours under DevOps, minutes under continuous delivery. Engineers are culturally accustomed to changing how they work, and to redesigning who does what with whom. Consensual workflow reinvention is a learned organisational reflex. No other function in a typical enterprise has this muscle. Marketing, finance, operations, HR - none have a 50-year track record of voluntarily tearing up their own playbook on a five-year cycle.

Two: the mode of systems thinking. Not only are development teams used to transforming their ways of working, software is a systems-thinking discipline by construction. Engineers are trained to see work as a system of building blocks that can be reconfigured - pipelines, dependencies, interfaces, feedback loops - not as a linear sequence of human tasks that can only be done in one way.

Most other functions typically think of work as sequential business processes. In campaigns, in reporting cycles and in approval chains. Linear, functional, sequential. To redesign work for AI you have to see the work as a system first. Most of the enterprise doesn’t, and isn’t trained to.

Put those two to1gether and we see again the diagnosis of what is required to produce value from AI. The technology is not the constraint. The constraint is the willingness to redesign work, and the cognitive mode of “systems thinking” required to do it.

A different shape of work

This is what many horizontal copilot rollouts I learn about in the market are getting wrong. Buying AI tools and dropping them into the existing workflow is, by construction, the version that doesn’t change anything. The real value coming out of AI is the shift it drives in occupational boundaries and the breakthrough across functional siloes. A field experiment at P&G (Cybernetic Teammate study) found that solo professionals using AI matched the quality of two-person teams without it, with a 0.37 standard deviation improvement over baseline.[6] In this study, AI users from R&D and Commercial converged on cross-functional answers their non-AI counterparts could not produce. The value wasn’t just acceleration. It was a different shape of work. The value of the 5% is coming from redesigning work operating systems.

So to drive value from AI investment, the CxO question for 2026 becomes how to build the transformation muscle for reorganisation and the mode of systems thinking that many software engineering teams have for granted.

The few early cases of intelligent transformation that are actually driving value point to a common orientation. We call it Refoundership. The distinction it draws is between redecorating and refounding. Most transformation programmes leave the underlying work intact. They often change the surface structures around it -reporting lines, governance, technology stacks, sourcing arrangements — without redesigning the workflows, roles and hand-offs from first principles thinking. Refoundership asks leaders to act at the fundamental level: if we were building this function from scratch, knowing what AI can now do, what would we actually build? A founder of a new company isn’t constrained by how the work has always been done. They construct the operating logic from zero. That is the posture this requires - and it is structurally different from the tool-led, copilot-rollout, “let’s see what sticks” programmes that are currently producing the 95% of projects with no impact. Although it’s early days, the learnings from these cases point to three moves that separate the programmes operating with this mindset from the ones that aren’t.

Three moves for Refoundership

1. Run AI as a deliberate transformation with change leadership and coaching. Engineering teams haven’t reorganised their ways of working solely on their own. The agile and DevOps transformations of the 2000s and 2010s were deliberate change programmes - led by transformation leaders (sometimes with engineering backgrounds, but no longer professional devs themselves), sustained by coaches (a new profession that didn’t exist beforehand), and protected by executive sponsorship. Those programmes were, in the language used here, a refounding of software development: old roles and handoffs were retired rather than layered over.

The most promising route to building the same muscle in marketing, finance, operations or HR is to run AI with the with the same intent to refound, not redecorate - and to treat AI as both a top-down work system and bottom-up behavioural transformation.

The individuals appointed to lead such programmes must first and foremost be experienced in driving transformation - being a technology or AI wizard is secondary. It also means investing in workflow and redesign coaches who sit alongside business teams and help them with practising the rituals of redesign until they become habitual - behavioural coaches for systems thinking, not technology trainers. Neither of these guarantees results. But both are conspicuously absent from most current AI programmes, which typically install copilots, run a steerco, and call the change managed.

2. When running your pilots make sure the unit of scope are workflows and value streams, not tools and platforms. Most enterprise AI programmes are organised around copilots and platforms - Microsoft 365 Copilot rollout, Salesforce Einstein adoption. That is a dimension of procurement. The dimension of reinvention organises around end-to-end value streams or workflows: supplier onboarding, end-to-end claims handling, demand forecasting. A workflow has owners, customers, inputs, outputs and SLAs. A tool does not. Ensure your pilot can name the workflow it is reinventing. If it can't, it isn't a transformation - it's a deployment.

3. Create explicit criteria and sponsorship to kill outdated workflows and policies. This is the hardest discipline, and the one most absent from current programmes. Agreement up front - before the pilot starts - on which workflows should cease to exist if the AI version proves out, rather than be augmented. Without kill criteria and sponsorship, every pilot becomes additive: a new tool layered on top of the old work. Humans are great at adding more processes and more policies - not so good at removing them - which is why this has to be set up explicitly.

Once the "kill process" is in place, intelligent transformation can start to do what software engineering has done to itself for fifty years - eliminate any work, role or handoff that creates friction and reduces speed.

These three moves, taken together, are what Refoundership looks like in practice. Each one is a condition of the founding act: the mandate to lead it as a transformation (not a deployment), the blueprint of end-to-end workflows from first-principles (not tools), and the discipline to retire what no longer needs to exist. Most current AI programmes have none of the three. Refoundership has the discipline of a transformation programme but applies first-principles thinking to the work itself: reinventing or removing workflows, removing obsolete ones, refounding how a function operates rather than redecorating it.

Our premise is that the enterprise AI opportunity isn't a technology programme. It is a re-founding of how work is done, brought about by the first-principles systems-thinking discipline the rest of the enterprise has never been required to develop.

The 5% of pilots that produce P&L impact aren't running better technology than the 95%. They're operating in environments where the muscle for reorganisation and the mode of systems thinking are prioritised and brought into the centre of the room.

The CxOs who can mobilise Refoundership - and not just another transformation - will compound the advantage for a decade. The ones who can't will spend 2026 automating workflows they should be eliminating.

References

1. MIT NANDA,State of AI in Business 2025.

2. Menlo Ventures,State of Generative AI in the Enterprise 2025.

3. Eurostat,Use of artificial intelligence in EU enterprises, December 2025.

4. Fortune, February 2026, citing US Bureau of Labor Statistics data.

5. Solow, R.,New York Times Book Review, July 1987.

6. Brynjolfsson, E. & Hitt, L.,Beyond Computation: Information Technology, Organizational Transformation and Business Performance, Journal of Economic Perspectives, 2000; andComputing Productivity: Firm-Level Evidence, Review of Economics and Statistics, 2003.

7. The Pragmatic Engineer,2026 AI Engineering Developer Survey, March 2026.

8. DX,AI code authorship and onboarding velocity research, February 2026.

9. Dell’Acqua, F. et al.,The Cybernetic Teammate: A Field Experiment on Generative AI Reshaping Teamwork and Expertise, HBS/NBER Working Paper 33641, 2025.