Enterprises are buying AI at scale and getting very little back. The most comprehensive study of the field to date, MIT’s State of AI in Business 2025, found that around 95% of enterprise generative AI pilots fail to deliver measurable financial return, despite an estimated 30 to 40 billion dollars of investment. The cause is not the technology. It is organisational: a gap between the tool a company has bought and the way its people actually work.
This paper draws the distinction that separates the winners from the rest. Access is the licence, the credits, the tool made available. Adoption is behaviour, AI embedded in how work is done. The two are not the same, and buying more of the first does not produce the second. For engineering and development teams, where the return on AI is largest, closing that gap requires changing two things: the operating model, and, more importantly, the run model, the standards, guardrails and daily defaults that govern how software is built.
The evidence is consistent on this point. AI adopted without those fundamentals does not just underperform. It can actively harm delivery. Adopted properly, embedded across the whole engineering lifecycle with humans in command, it compresses cycle time by margins that justify the spend many times over. This paper sets out how to cross from one to the other.
Buying AI is now the easy part. An enterprise agreement, a pool of credits, a licence for every engineer who wants one. Most organisations have done it, or are about to.
Getting anything transformative back from it is a different story, and the data shows almost nobody has managed it. MIT’s State of AI in Business 2025, based on 150 executive interviews, a survey of more than 350 employees and analysis of 300 public deployments, found that only around 5% of enterprise AI pilots achieved rapid revenue acceleration. The rest stalled, delivering little to no measurable impact. The same study found that while 40% of organisations had deployed AI tools, only 5% had integrated them into workflows at scale.
Figure 1. Most enterprises have deployed AI. Very few have embedded it.
That distance, between deployment and integration, is where all the value lives, and it is the part money cannot buy. Access can be purchased in an afternoon. Adoption, the kind where AI is embedded in how people actually work, has to be built. The trend is now moving in the wrong direction for those who have not built it: the share of companies abandoning most of their AI initiatives rose to 42% in 2025, up from 17% the year before.
MIT’s own diagnosis is unambiguous. The divide is not explained by model quality or by regulation. It is a learning gap, the failure of tools to integrate with the workflows and data of the business. That is an organisational problem, not a technical one, which is precisely why more procurement does not solve it.
The clearest sign of a stalled programme is not low usage. It is usage that has gone somewhere the organisation cannot see. The same MIT research found that while only around 40% of companies had bought an official AI subscription, employees at more than 90% of the companies surveyed were already using personal AI tools for work. The tool the business paid for often sits underused, while the real work quietly happens on people’s own ChatGPT and Claude accounts. A shadow economy of AI use runs alongside the official one, and dwarfs it.
That gap, between what was bought and what is used, is the failure in miniature. It is not that people reject AI. It is that the sanctioned deployment does not fit how they work, so they route around it. In one case the study describes, a company’s official pilot looked polished in the boardroom and collapsed the moment it met real work in the field. The demo impressed. The workflow did not survive contact.
The heaviest users, meanwhile, are often not the working engineers at all. Independent research into unsanctioned AI use found that more than 80% of employees, and nearly 90% of security professionals, use AI tools their organisation has not approved, with senior staff among the most frequent users. Enthusiasm at the top is easy to mistake for adoption across the team. It rarely is.
None of this is a story about a weak tool or the wrong people. It is a precise description of what happens when a powerful, general-purpose tool is handed to people and nothing else about how they work is changed. The MIT researchers name the pattern directly as high adoption, low transformation: generic AI reaches wide use for easy tasks and stalls the moment a workflow demands real context.
Figure 2. Generic AI is widely used for the trivial, and rarely for the valuable.
Two failure modes hide inside that pattern, and both are instructive.
The first is that behaviour defaults to the trivial. Hand someone a capable tool with no change to their workflow and they will reach for it on the most familiar, lowest-value task they have. Not through laziness, but because it is the path of least resistance. Nothing in the working day makes the valuable use easier than the trivial one, so the trivial one wins. A tool that is merely available is not a behaviour. It is an option most people decline under the weight of habit.
The second is mistaking enthusiasm at the top for adoption across the team. When the heaviest user is a leader, it manufactures a comfortable illusion. The organisation tells itself it has become an AI company, because the person telling the story genuinely has changed how they work. But one enthusiast, however senior, is not adoption. Their engagement masks the fact that the people who were meant to be transformed have barely moved.
This does not mean leadership matters less. It means the opposite. A leader who simply uses the tool changes one person’s habits. A leader who drives a deliberate, organisation-wide transformation changes how the company works. The failure is not too much attention from the top. It is the wrong kind: personal enthusiasm standing in for strategic intent.
Beneath both is a single truth. A licence grants access. Adoption is behaviour, and tools do not change behaviour. Changed ways of working change behaviour. Most AI programmes never internalise this, and so keep trying to solve an adoption problem by buying more access. The two are not connected.
There is a stronger version of this argument than mere underperformance, and the most credible engineering research makes it.
The 2024 Google DORA report, the longest-running study of software delivery performance, surveyed roughly 3,000 practitioners. It found that AI adoption significantly increased individual productivity, flow and job satisfaction, and that more than three quarters of respondents were already relying on AI for part of their work. On the surface, an adoption success.
Underneath, a warning. The same research estimated that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. In plain terms, teams that adopted AI without changing how they worked shipped less reliably and broke more things. DORA’s conclusion is the sentence every engineering leader should sit with: improving the development process does not automatically improve software delivery, not without the fundamentals of small batch sizes and robust testing.
Figure 3. AI lifts individual factors, but without the fundamentals it drags delivery down.
The 2025 follow-up sharpened the point into a single idea: AI acts as an amplifier, magnifying whatever an organisation already is. Strong practices are amplified into faster, safer delivery. Weak practices are amplified into faster instability. The tool does not set the direction. The run model does.
This reframes the entire adoption question. The goal is not to get people using AI. It is to build the conditions in which AI, once used, makes delivery better rather than worse. That is not a licensing decision. It is a decision about how the organisation runs.
This is where the work becomes strategic rather than technical, and where it has to be owned at the top. Embedding AI is not an IT rollout to be delegated to whoever is keenest. It is a deliberate transformation of how the organisation delivers, and it competes for the same executive attention as any other change that decides whether a business leads or lags. That it is a dividing line is increasingly clear in the data: the share of companies walking away from most of their AI initiatives rose to 42% in 2025, from 17% the year before. A small group is pulling ahead, embedding these tools into how they work, while the majority stalls. The distance between the two is widening, and it is the kind of gap that decides who leads a market and who is left explaining the spend.
If not more credits and more training, then what changes an organisation from access to adoption? You change the conditions people work in, until the default flips. Until using AI well is the easy path, and not using it is the awkward one. That decision has two parts.
The first is the operating model: what the team is. Its roles, its structure, how work is organised and sourced. This is the part organisations are comfortable redrawing, and it matters here as the structural enabler. It sets the conditions.
The second is the run model: how the team actually works. The standards, the guardrails, the defaults, the daily mechanics of turning an idea into shipped, working software. This is the part almost nobody touches, and, as the DORA evidence shows, it is the part that decides whether AI helps or harms.
You cannot buy a run model. You have to build one. Until you do, every pound spent on access is buying an option that most of your people will keep declining, and that a fraction may be using in ways that quietly degrade delivery.
For engineering teams, the run model is concrete and buildable now. Three things do most of the work.
Shared context, so everyone’s AI knows your standards. The difference between an engineer who gets little from AI and one who gets a great deal is usually context. Encode the organisation’s coding standards, security guidelines and architectural policies into shared context files and reusable skills that every engineer’s tooling draws on by default. The model then stops producing generic output that has to be corrected into house style, and starts producing work that already fits, because it knows the rules. This is the highest-leverage move available, and the one that turns AI from a novelty into a colleague that already understands how you build.
Guardrails, so speed is safe by default. The fear that stops teams moving fast is that fast means reckless, and the DORA data shows that fear is well founded when the fundamentals are missing. The answer is to make the standards enforce themselves. Coding standards, security checks and architectural policies encoded into the pipeline and applied to every change automatically. Tests generated as part of the build rather than bolted on afterwards. When the guardrails are automated, speed stops being a risk and becomes a property of the system. This is the direct, practical response to the paradox in Figure 3: it is how you keep the throughput gains without the stability cost.
Defaults that assume AI, so not using it is the exception. The workflow itself has to change, not just the toolbox. Code review that expects AI to have been part of authoring. Test generation as a standard step, not an optional one. Incident investigation that begins with an AI-drafted diagnosis. When the pipeline and the daily rituals assume AI, the trivial default cannot survive, because the valuable use is now the easy one and skipping it is the friction.
Do these three, and the thing credits and training never could achieve happens on its own. The default flips. Embedded use stops being something people are exhorted towards and becomes the way work is done.
There is a narrower trap that careful organisations still fall into. They embed AI in development and stop there.
That only moves the constraint to the next desk. If developers are twice as effective but every requirement still waits weeks for analysis, every design waits on a manual review, and every change waits for someone to write the tests by hand, the organisation has not sped up. The queue has simply moved.
Real adoption spans the whole engineering lifecycle. Every discipline, embedded:
When every discipline is embedded, the whole flow moves. That is the difference between a team using AI at the margins and a team that operates at a different tempo entirely.
This is the part that justifies the spend that trivial, shadow use never could.
The prize is cycle time: how long the business waits between a decision and working software in production. In the GitHub study run with Accenture and Microsoft across 4,800 developers, embedding AI in the workflow cut average pull request time from 9.6 days to 2.4 days, a 75% reduction. The same body of research found developers completing controlled tasks 55% faster with AI assistance.
Figure 4. Embedded AI compresses the time from change to production.
Those figures sit inside a wider pattern. DORA’s long-run research puts the gap between elite and low-performing engineering organisations at 100 to 1,000 times on lead time and deployment frequency. That gap is what embedded AI closes, and where the return lives. The public results bear it out: Stripe completed a 10,000-line migration in four days with AI assistance, work originally scoped at ten engineer-weeks. Ramp cut incident investigation time by 80%. Anthropic’s enterprise customers report productivity gains of 25 to 100%.
Stack the credible, individually defensible gains and the compounding effect lands somewhere between 2 and 5 times on the work a team retains. But per-engineer output is not even the headline. The headline is how long the business waits. Move that from months to days, and the difference between a company that adopted AI and one that merely bought it becomes impossible to miss.
None of this replaces the engineers, and it is worth saying plainly, because it is exactly the fear that fuels the resistance beneath every stalled rollout. Developers are often the most reluctant to change how they work, and DORA found only 39% of practitioners were confident in AI-generated output. That caution is not stubbornness. It is judgement, and the model depends on it.
In this way of working, humans are the orchestrators. They are augmented, not automated away, and they are always in the loop. Every change is reviewed by a person. Every release is a human decision. The architecture, the design, the security judgements, the call on whether something is actually right, all of it stays with the team.
What changes is not whether people are in control. It is what they spend their control on. Less mechanical work, more of the decisions only engineers can make. The model is not autonomy. It is leverage, with a person directing it at every step, and the guardrails ensuring that low confidence in a given output is caught before it ships. Sold honestly, that is a future most engineers want, not one they resist.
An organisation does not cross from access to adoption with a policy memo. It crosses by changing how one team works, showing the result, and letting it spread.
The cleanest way to force the shift, and to answer the cost question at the same time, is a contained pilot with a budget. Take a piece of work that would normally need four developers. Give it to two, with a defined token budget, and have them deliver it the new way, with the shared context, the guardrails and the AI-first defaults all in place.
The result is rarely just the same output for less. The constraint changes how the team works. With fewer hands and a budget to respect, people stop doing things the slow way out of habit, because they cannot afford to. Embedded use stops being optional and becomes the only way the work gets done in the time available. Better practices fall out of the exercise alongside a lower cost, and the organisation learns what the tools are genuinely good at, where its guardrails need strengthening, and what the real economics look like on its own work. One contained experiment, not a leap of faith, and a reference the rest of the organisation can see.
On cost specifically, the token spend is best judged against the right comparison. It is not a cost measured against zero. It is a cost measured against engineer time and against the price of delivering late. Set against a loaded engineer day, it is small, and unlike headcount it is a managed input that can be set, monitored and capped.
Anyone can sign the agreement. Anyone can hand out the credits. The hard part, the part that separates the organisations getting a return on AI from the ones quietly wondering where their money went, is everything that comes after: changing the operating model, and more importantly the run model, until the tools are embedded at the heart of how engineering works, not sitting beside it.
The evidence points the same way throughout. The MIT study found that organisations buying from specialist vendors and building partnerships succeeded roughly 67% of the time, while those going it alone with internal builds succeeded only about a third as often. Crossing this divide is hard enough that most attempt it with help.
That crossing, from access to adoption, is the work we do at dotslash, and as an Anthropic partner it is the work we have done on ourselves. We do not describe this transformation from theory. We run this way, which is why we can help others get here.
If you have bought AI for your engineering teams and are not yet seeing the return, the problem is almost certainly not the tool. It is the gap between access and adoption, and closing it is exactly what we do.