April 29, 2026
Back in mid-2025, TechReviewer’s global survey reported that 97.5% of companies had adopted AI in their software development (TechReviewer). Nine months later, the story still holds. McKinsey’s November 2025 global survey put regular AI use at 88% of organisations worldwide, up from 78% a year earlier (McKinsey), and KPMG’s January 2026 executive pulse found 93% of leaders crediting their GenAI investments with improving their company’s competitive position (KPMG). Near-universal adoption has been the headline for the better part of a year.
Read past the headlines, though, and the details in those same reports show a more complicated picture. McKinsey finds that only about one-third of organisations have begun scaling AI across the enterprise, while nearly two-thirds are still experimenting or piloting. Deloitte’s January 2026 State of AI in the Enterprise reports that workforce access to AI expanded by 50% in a single year, yet fewer than 60% of workers with access use AI in their daily workflow, a figure that hasn’t moved in a year (Deloitte). So, there’s a gap between broadly-claimed adoption and reality on the ground that I wanted to understand better.
The engineering and product leaders I’ve been talking to inside large enterprises describe that gap in sharper terms. Walk into one of those companies and you’ll find a messier reality. Advanced AI practice exists, but only in pockets. A four-person team ships daily with coding agents while the rest of engineering uses AI “as a better Stack Overflow.” A product manager builds synthetic personas from customer interview transcripts while colleagues down the hall have never tried it. A handful of trailblazers carry almost all the real experimentation while governance committees are still debating what the rules should be.
Understanding where a large enterprise stands with its AI maturity requires reading the fine print, and then listening to the people doing the work.
The same near-universal pattern shows up when you cut the data by sector. Russell Reynolds reported in December 2025 that 91% of financial services firms had taken steps to implement generative AI in day-to-day workflows, up from 71% a year earlier (Russell Reynolds). An NVIDIA retail and CPG survey put about 80% of those companies in the “adopting or piloting” bucket (NVIDIA). It isn’t a tech-industry artifact.
Sanctioned deployment at enterprise scale is a different story. A January 2026 Bloomberry analysis of 76,000 companies found that only 13.4% of the Fortune 500, and 6% of firms with 500 or more employees globally, had deployed an enterprise LLM platform to their workforce (Bloomberry). Deloitte finds a similar split on transformation depth: only 34% of organisations describe what they’re doing with AI as a deep transformation of products, processes, or business models. Another 30% are redesigning key processes, and 37% are still using AI only at a surface level (Deloitte).
Cut the data by sector or by depth, and the answer is the same: broad adoption, but in a pattern that’s both shallow and sparse.
To get a more firsthand view of what was happening with AI adoption in software delivery in early 2026, I interviewed engineering and product leaders at large enterprises across media, hardware technology, hospitality, healthcare, and retail organisations.
Almost all of these organisations are in or entering the individual-to-team transition: past the point where a few developers are quietly experimenting, not yet at the point where whole teams share a standard practice. Coding is the dominant SDLC phase in every case, and for most teams that is where AI usage stops. Other phases see only light use. Security concerns are universal and unresolved at scale, with every interviewee flagging the same worry. And the teams that have pulled ahead on coding are now running into the next constraints, like code review, QA, and requirements definition. This is what the gap identified by the surveys looks like inside a single company.
The interviews also surfaced a nuance the surveys miss. Deloitte puts 42% of organisations at “highly prepared” with formal AI strategies in place, but the more predictive question was whether the executives themselves use the tools. At one tech and hardware company, the CEO’s direct reports were using coding CLIs daily, and that created the permission and top-down support that accelerated everything else. At another organisation, a leader who did not believe in the tools left a vacuum no strategy document could fill. Having a strategy and having leaders who personally use AI are not the same variable, and actual usage predicts maturity more accurately.
So, the surveys are broadly right about what is happening. Where they fall short is explaining why the broad adoption these organisations report isn’t delivering bottom-line value yet, what is blocking the move from individual AI usage to shared team practice, and what it takes to make that move happen.
The interviews I conducted surfaced the forces holding the transition back, none of which show up in the industry survey data. What follows is the set of patterns that came up often enough to be worth naming. None are unique to a single industry, and none are on the standard list of adoption barriers.
In every company I spoke with, pockets of advanced AI usage coexisted with teams that had barely changed. It isn’t a company-level phenomenon; it is a team-level and often individual-level one. A four-person team inside a media company ships daily with coding agents while the rest of engineering uses AI “as a better Stack Overflow.” At a hardware technology company, “total converts” sit next to “very traditional people who really haven’t changed at all.” A product leader at a hospitality company described a handful of trailblazers “who know how to break the rules safely” carrying almost all the meaningful experimentation.
Menlo Ventures’ January 2026 enterprise report shows the same shape at the company level: about half of developers now use AI coding tools daily, rising to roughly 65% in top-quartile organisations (Menlo Ventures). The 15-point gap between top quartile and average shows that usage intensity concentrates in a minority of companies even as broad adoption spreads everywhere.
This concentration is invisible to the headline numbers. A survey that asks “has your organisation adopted AI?” gets a yes whether one team or fifty teams have crossed the line into regular, productive use. The shape of adoption inside an enterprise matters as much as whether it’s happening at all.
Most of the infrastructure supporting an enterprise developer was designed to support individual humans, not people operating multiple independent agents. Identity systems, seat allocations, procurement workflows, license budgets: all built for people, not agents. Every interviewee bumped into the mismatch.
The pattern showed up across layers. At a media company, per-developer token budgets sized for interactive coding were getting exhausted within days once a team moved to agentic workflows. An engineering leader at a hardware technology company described credential management for agents operating across third-party services as an unsolved problem. At a food-service company, Okta-based authentication created friction every time a new AI tool had to be wired into the existing identity stack. At a healthcare company, procurement processes designed for annual software purchases couldn’t keep pace with tools that reshape themselves quarterly. And at a hospitality company, license upgrades for coding assistants had to be fought for per use case, one budget meeting at a time.
None of this shows up in the surveys’ lists of adoption barriers. Those measure strategy, skills, and culture. They don’t ask whether the platform team has the bandwidth to rewire auth, procurement, and license provisioning for agentic patterns, which is a binding constraint on AI maturity.
Some of the boundaries inside a large enterprise weren’t designed, they were inherited. You can mandate practice change inside your own organisation, but it doesn’t transfer cleanly across teams you didn’t build.
A product leader at a hospitality company described delivery there as split across multiple agency partners, each with its own methodology, none with a shared view on how AI should be used. Rolling out a standard coding practice across teams that don’t report in, and whose contracts were written before agents existed, turns into a renegotiation rather than a decision. The same leader flagged a sharper problem: vendors claimed internal AI productivity gains while holding their billing rates constant. Whatever upside AI was producing flowed into agency margins, not the client’s budget.
A healthcare company described the same fragmentation occurring from acquisitions, not vendors. Unlike vendor teams, acquired teams sit inside the company, which makes them more pliable. The practices they bring offer something worth learning, if the organisation takes the time to assess them rather than flatten them on arrival.
Bottom-up AI adoption, where every team picks its own tools, is how most of the enterprises I spoke with got moving in the first place. Teams experimented broadly to find what worked against their codebase, delivery culture, and risk profile.
Many of those organisations had working groups, AI councils, or internal communities sharing what they were trying, but none had a mature framework for measuring which experiments were producing results. Most leaders described measurement as the unsolved problem. One interviewee called it “the million dollar question.” Another pointed out the chicken-and-egg issue of trying to measure AI impact in organisations that had never measured engineering output rigorously.
Not converging on a shared approach carries a cost. An engineering leader at an industrial distributor put it directly: agents perform measurably better against standardized, common frameworks than against a sprawl of team-specific stacks. Spotify’s public account of building its Honk coding agent reinforces the point. They spent years consolidating their internal platform and standardizing testing before agents could be effective at scale (Spotify Engineering). Token economics also favor standardization. A large share of what an agent spends its context on is exploration: figuring out where things live, how the codebase is structured, and which patterns are in use. Consistent, well-structured context across an organisation reduces that exploration cost directly; fragmentation inflates it.
Every company I spoke with in my interviews had some framework in progress for handling data risk, compliance, and access controls. But there’s another type of employee concern that was shared by just one product leader I talked to. I suspect it’s a concern that exists far more broadly, but only emerged because this leader at a hospitality company had specifically gone looking for the information.
The product leader in question ran a team-by-team research exercise asking people what they were afraid of about AI. The answers were not what the governance documents anticipated. People felt guilt about using an AI tool to do work they had previously delegated to contractors or colleagues they knew by name. They worried that any time reclaimed by AI would be refilled with more work rather than returned to them as breathing room. They were anxious about getting in trouble if an AI tool made a mistake on their watch. And where roles already overlapped, people using AI to do work that used to sit in someone else’s job description got “this is my thing, why are you doing it?” pushback.
None of these fears appear in public survey barrier lists. Employees don’t volunteer them unprompted, either. They show up in private conversations, and in adoption patterns: the trailblazers in any organisation are usually the people who don’t feel these concerns, or who know how to work around them without asking. That could be a big reason why adoption keeps landing in a concentrated shape.
Ask any engineering leader who has pushed AI usage beyond individual developers what happens next, and they point to the same place: code review and QA. Every interviewee either hit the wall or was routing around it. A leader at one media company described code review as the new constraining factor, and was building AI-assisted review tooling to stay ahead of it. A food-service engineering leader put it plainly: “The bottleneck right now is QE work.”
The most advanced team I spoke with had already moved past this hurdle, replacing human code review with automated validation loops: BDD-style scenarios, happy and sad path coverage, and continuous execution. They now ship daily without anyone reading the code. That approach probably goes beyond many current organisations’ comfort levels, if not governance rules, but it points at what solving the QA bottleneck looks like at scale: not more reviewers, but different verification.
Solving for QA isn’t enough, however; the product function can also become a bottleneck. When engineering teams can consume requirements faster than before, the people writing those requirements become the constraint. Part of the problem is throughput: product managers have to produce more requirements to keep engineering busy. The harder part is quality and direction. A product that ships at four times its old velocity in the wrong direction is just wasting capacity faster.
In the larger picture, the bottleneck moves past the delivery team altogether. A product leader at a hospitality company named the constraint: organisational change capacity. Decision-making bandwidth. Operational absorption. Customer tolerance for how fast a product can change. “Just because you can do a lot more stuff, does it mean that your organisation can actually handle the amount of change you’re going to be making?” Downstream teams and customers only absorb change at a certain rate, and that rate becomes the new ceiling.
Solutions to try
The field is moving faster than proven practice, given the rapid evolution of AI tooling. But here are a set of ideas worth trying, drawn from past organisational transformation work and techniques the leaders I spoke with are already experimenting with.
See clearly before acting. Industry adoption numbers are misleading, so pay attention to what’s visible within your own organisation. Map where AI use is concentrated and where it is absent, and at what level it is being applied. Functional leaders set the bar: engineering leaders using coding CLIs and agentic workflows, product leaders using research synthesis and prototype-first discovery, non-technical executives using AI in their own analysis, strategy, and writing. Strategy documents don’t move adoption the way personal use does.
In practice:
Fix structural blockers deliberately. The enablement layer is the gate. Identity, procurement, license provisioning, credential handling for agents: give these priority attention. With vendor partners, the focus is converging on common frameworks, repositories, and practices so the context substrate agents rely on is shared. Blend internal and vendor development teams so both sides can see where the AI gains are flowing. That shared visibility is what makes contract renegotiation a tractable conversation instead of a fight. When integrating an acquisition, treat the acquired team’s practices as a source of learning about what could work in the larger organisation.
In practice:
Build the learning system. Bottom-up experimentation is the right starting point, but it needs a feedback loop. Measure what a productive AI-accelerated team looks like, and use those metrics to decide what to standardize on. Research the human concerns ahead of establishing governance; what people are afraid of rarely matches what compliance documents anticipate.
In practice:
Plan for the next hurdles. Code review, QA, product throughput, and problem selection are the next bottlenecks. Organisational change capacity is the barrier past that. Plan to invest in these before they happen.
In practice:
Genuine capability gets built by leaders who can describe the actual shape of AI use inside their own organisation, unblock the structural problems surveys never ask about, and invest ahead of a bottleneck that keeps moving. If you can do these things, building the strategy deck is the easy part.
Mike Mitchell is a Product and Strategy Principal at Equal Experts, helping organisations adopt modern product practices and integrate AI into their product lifecycle in practical, sustainable ways.
His current focus is on helping product teams do more meaningful strategic work with AI, both by accelerating the routine work that crowds it out, and by making AI a more proactive, multi-modal collaborator.
Mike brings 35 years of experience in enterprise software, with a foundation of engineering followed by two decades of product leadership. He is a founder of multiple startups, has advised dozens more, and has led multiple enterprise transformations. Just prior to EE, Mike served as a fractional Chief Product Officer, guiding early- and growth-stage firms to deliver value faster through stronger product strategy and operating models. He holds a degree in Computer Science & Engineering from MIT.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
