# AI Adoption Without Organisational Change Is Just Expensive Noise
**Date:** 2026-05-14
**Author:** Dan Maby
**Categories:** Marketing & Business, AI, Development
> Buying Copilot seats and ChatGPT Enterprise does not make an organisation smarter. Without redesigning how work, learning and incentives flow, AI tooling just adds cost and noise. Here is what actually shifts the curve.
[Marketing & Business](https://blue37.com/blog/category/marketing-business) | [AI](https://blue37.com/blog/category/ai) | [Development](https://blue37.com/blog/category/development)
[View on blue37.com](https://blue37.com/blog/2026/05/ai-adoption-without-organisational-change)
---
## The bill is arriving, the productivity is not

McKinsey's November 2025 State of AI survey put a number on something a lot of operators have been quietly muttering for a year: almost nine out of ten companies had deployed AI in at least one business function, but 94 percent of respondents report not seeing "significant" value from those investments. PwC's 2026 Global CEO Survey of 4,454 CEOs lands in the same place - [TheNextWeb's coverage](https://thenextweb.com/news/mckinsey-ai-productivity-paradox-enterprise-roi-capex) notes that 56% say they have gotten 'nothing out of' their AI investments, and only 12% report AI both growing revenues and reducing costs.

This is not a story about bad models. GPT-5.5, Claude Opus 4.7, Gemini 3.1 - the tools are extraordinary. The story is about organisations buying licences, declaring transformation, and changing nothing else. We think that is the central business mistake of this cycle, and we think it is going to get more expensive before it gets cheaper.

## The Solow Paradox, rerun with GPUs

McKinsey's own analogy for this is electricity. When electricity first arrived in factories, many businesses simply replaced the steam engine with an electric motor, capturing efficiency gains but leaving the line-shaft layout unchanged. The real productivity gains came decades later, when factories were redesigned around what electric motors made possible - distributed power, modular layouts, assembly lines.

The same pattern is playing out now. Most current AI applications are 'tools that accelerate existing work' but 'largely preserve underlying workflows', and the larger productivity gains will only emerge once organisations redesign processes around AI rather than simply bolting it on top. The McKinsey high performers - around 6% of respondents - are not winning because they picked a better vendor. The distinguishing characteristics were not better technology choices but better organisational practices: redesigning workflows, scaling faster, embedding AI into business processes, tracking KPIs for AI solutions, having senior leadership demonstrably committed to the work.

MIT's NANDA project found the same thing from the other direction. The widely-quoted finding that 95% of generative AI pilots produce no measurable P&L impact has been picked apart for methodology, fairly. But the underlying diagnosis is hard to dispute. As [Virtualization Review summarised from the report](https://virtualizationreview.com/articles/2025/08/19/mit-report-finds-most-ai-business-investments-fail-reveals-genai-divide.aspx), the core barrier is learning rather than infrastructure, regulation, or talent: "Most GenAI systems do not retain feedback, adapt to context, or improve over time."

A tool that does not learn, dropped into an organisation that has not changed how it learns, produces exactly what you would expect: shiny demos and flat numbers.

## What "the company still learns nothing" actually looks like

Robert Glaser captured the texture of this better than anyone in [his recent essay on AI and organisational learning](https://www.robert-glaser.de/when-everyone-has-ai-and-the-company-still-learns-nothing/):

> People may get faster, write better, analyze more, automate more, or quietly become cyborg versions of themselves. The company may still learn almost nothing.

That is the gap. Individual employees absolutely are getting more productive with Claude, ChatGPT, Copilot. They are also, in many cases, doing it invisibly, on personal subscriptions, with no mechanism for those discoveries to travel beyond their own laptop. Only 40% of companies say they purchased an official LLM subscription, yet workers from over 90% of the companies reported regular use of personal AI tools for work.

Glaser's framing is that the interesting AI work does not wait for the next community meeting. It appears inside a code review, a sales proposal, a research task, a product prototype, a production incident, a test strategy, a compliance question. By the time it surfaces as a best-practice slide, the lesson is stale. The organisations that will pull ahead are the ones that can metabolise these micro-discoveries into shared capability faster than their competitors.

Most cannot, because nothing about how they run has changed. The same approval chains, the same quarterly planning, the same incentive structures that rewarded individual hero-coding now reward individual hero-prompting. The org chart treats AI as an IT procurement line item, not a redesign trigger.

## The maintenance-cost trap (where this gets painful for engineering)

For anyone running a software team, there is a sharper version of this argument that is worth sitting with. James Shore put it bluntly in [a recent post on AI coding agents](https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs):

> Your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. You write code twice as quick now? Better hope you've halved your maintenance costs.

Shore's point is that the math only works if the LLM decreases your maintenance costs, and by exactly the inverse of the rate it adds code. If you double your output and your cost of maintaining that output, two times two means you've quadrupled your maintenance costs. The agent gives you a velocity boost. The codebase gives you a permanent tax. If the second number is bigger than the first - and there is mounting evidence it often is - you have not made the team faster. You have given it an obligation it will service for years.

This is not an argument against coding agents. We use them at Blue 37, deliberately. It is an argument that velocity is the wrong KPI on its own. The questions that matter are: are we shipping code that is cheaper to maintain than what we shipped last quarter? Are reviews still meaningful or are people rubber-stamping pull requests? Does the team understand the code well enough to fix it at 2am when production breaks? Those are organisational questions, not tooling questions.

## Trust, custom software, and the buy-versus-bolt-on question

There is one more piece of this worth naming. Enterprise AI buying is happening in an environment of low and falling trust. The [Stack Overflow blog has written about the AI trust gap](https://stackoverflow.blog/2026/04/02/what-the-ai-trust-gap-means-for-enterprise-saas/) for enterprise SaaS, and the pattern is consistent across surveys: buyers are spending, but they do not believe the outputs, they cannot audit the behaviour, and they cannot tell their board what the system actually does on Tuesdays.

This is where the build-versus-buy conversation gets interesting again. The MIT study found a counterintuitive result on this front: external vendors with specialised tools tend to succeed more often than internal builds aimed at general AI capability. We read that as a comment on focus, not on capability. A team trying to "do AI" without a specific workflow to redesign will lose to a team that picks one painful, expensive process and rebuilds it with AI at the centre.

That second team usually needs custom software. Not a chatbot bolted onto a CRM. A redesigned system where the AI's role, the human's role, the audit trail, and the failure modes are all explicit. That is the work we tend to get pulled into when an off-the-shelf rollout has stalled.

## Our take

We think the next two years of AI in business will be defined less by which model you pick and more by whether your organisation is structurally capable of learning from it. The companies that win will not be the ones with the biggest Anthropic invoice. They will be the ones that redesigned a meaningful slice of how they operate so that AI's outputs feed back into shared capability instead of evaporating into individual productivity.

That is a consultancy conversation, not a tooling conversation. It involves looking at incentives, at where decisions actually happen, at how knowledge moves between people, at which processes are worth keeping and which were only ever scaffolding for the limitations of pre-AI work. It also involves being honest about maintenance cost, lock-in, and the very real possibility that some of what gets shipped this year will be a liability by 2028.

We are sceptical of any AI strategy that begins with a procurement decision and ends with a dashboard of seat licences. We are interested in the ones that begin with a specific bottleneck, a clear hypothesis about how the work should change, and a willingness to redesign the surrounding process. That is where we think the 6% live.

## If this is the conversation you are having internally

If you are looking at an AI rollout that is producing activity but not outcomes, or a coding-agent experiment that is generating volume but not confidence, we are happy to talk through what a more deliberate approach might look like for your situation. [Get in touch](/contact).
