AI Adoption Challenges Live in the Business, Not the Code

The AI adoption challenges that stall an IT team are rarely in the code. An in-house team that has put real effort into AI-assisted software development can usually build the feature. What it often cannot do on its own is get the business to review that feature, agree to it, and change how people work so it gets used. The bottleneck has moved from engineering to the organization around it.

That changes what an IT leader should be managing. If the work is waiting on a decision, a better model will not release it. An owner, a measure, and a deadline will.

The Feature Is Done. The Business Has Not Said Yes.

Picture a team that ships an AI feature to summarize customer calls. The people taking those calls asked for it: a summary they can edit and paste into the CRM instead of typing notes by hand after every call. The feature works, it is tested, and it would give those staff back a few minutes on every call.

It does not ship. It sits in review while stakeholders go back and forth over minor formatting choices. Nobody objects to the feature itself. Nobody is responsible for deciding it is good enough, either, so the review never ends.

Underneath the formatting debate there is often something harder to say out loud. A feature that saves time changes what a role looks like, and some managers will protect the work their team does today. That reaction is human, and it deserves a direct conversation rather than a workaround. Treating it as a review comment to resolve is how a finished feature stays unreleased for months.

None of this is an engineering failure. The code was the easy part. The decision was the hard part, and nobody owned it.

Adoption Inside the Engineering Team Is Uneven Too

The business is not the only place adoption stalls. Inside most engineering teams, AI use is uneven. Some developers have rebuilt how they work around AI agents. Others use a chat assistant now and then, and some keep the workflow they have always had.

The comparison we find useful is a job site. A carpenter with power tools and one with hand tools can both build the same cabinet, and the craft still matters to both. They are not doing the same job at the same pace, though, and a crew that mixes the two needs to plan around that difference rather than pretend it is not there.

The research points the same way. Google’s 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, found that 90% of respondents use AI at work and summed up its main finding as “AI doesn’t fix a team; it amplifies what’s already there.” The same report found AI adoption linked to higher delivery throughput and, still, to lower delivery stability. Faster output lands on whatever process is already in place, including the parts that were already weak.

Uneven adoption is a management problem, not a tooling one. Buying more licenses does not close it. Showing people what the new way of working looks like on their own codebase, alongside someone who already works that way, usually does.

From Prompt Engineering to Context Engineering to Harness Engineering

How engineers work with AI has gone through three stages, and each one moves the bottleneck somewhere new.

Prompt engineering was about wording the request well. The developer wrote a careful instruction and got back a function or a block of code to paste in.

Context engineering is about what the model knows when it starts. Anthropic describes it as “the natural progression of prompt engineering”: curating the right information for the model, such as the codebase, the conventions and the design, instead of polishing a single prompt.

Harness engineering goes further. OpenAI’s engineering team has written about building the environment around the agent: the documentation it reads, the checks it runs, and the feedback loops that let it carry a change all the way to a pull request. In the version we favor, people set the direction and approve at defined gates, from the idea through production, instead of writing each line.

Each stage clears one constraint and exposes the next. Once agents produce working changes reliably, the queue moves to pull request review, because we still want a person to understand and approve what changed. Once review is organized, the queue moves again, past engineering and into the business.

This is also why we would not lead an AI program with speed. The order that holds up is architecture, specs and judgment first. A team that skips the design and the review gates does not ship faster. It ships rework.

Faster Delivery Fills the Queue the Business Has to Absorb

Every IT team has a backlog far longer than it can work at once. The traditional limit was engineering capacity. AI-assisted delivery loosens that limit, and the next one shows up right behind it: how much change the business can take in at once.

Every release asks something of the people who use it. Someone has to review it, approve it, train on it and adjust their day around it. Those people still have their regular jobs. If engineering doubles what it delivers and the business’s ability to accept change stays where it was, the result is not twice the value. It is a longer line of finished work waiting for sign-off.

This is where productivity gains from AI quietly disappear. In the same DORA research, more than 80% of respondents believe AI has increased their productivity; those gains are absorbed by a queue no one is measuring.

What IT Leaders Can Do About AI Adoption Challenges

The fixes are not technical. They are the same disciplines that make any change land, applied on purpose to AI work.

1. Pick Use Cases With a Business Owner

Before a line of code is written, name the person on the business side who owns the outcome and has the authority to say “this is good enough.” Not a committee and not a steering group. One person who will be measured on whether the feature gets used. If nobody will take that role, that tells you the use case is not ready, however good the technology is.

2. Measure the Time Saved

Agree on the measure before the build: minutes per call, hours per week, days off a cycle. Take a baseline from how the work is done today, then measure again after release. A measured saving turns a formatting debate into a cost decision. Every week the feature waits has a number on it, and the number belongs to the business owner, not to IT.

3. Put a Deadline on Review

Reviews without an end date expand to fill the time. Set a date by which the business owner decides: ship it, ship it with listed changes, or stop. Collect comments until then, decide once, and keep cosmetic preferences out of the gate. The deadline protects the reviewers as much as the engineers, because it tells them when their input counts.

4. Treat Change Management as the Project

The usual plan treats training and rollout as the last step after the build. For AI work, change management is the project. Plan who changes how they work, what they stop doing, who supports them in the first weeks, and how roles are affected, and have those conversations early and honestly. People who see what the feature gives them back are, in our experience, likelier to use it than people who find out at launch.

A useful test for any AI initiative on your roadmap: if the engineering were finished tomorrow, would it be in use next month? If the answer is no, the next dollar belongs in ownership and adoption, not in more code.

Where to Start

We adopted AI coding agents across our own team in 2025. What we bring to an IT team is engineering that holds up under your governance: an AI use case taken into production with its security, its support and its running cost named before the build, and a business owner in the room from the start.

If your roadmap has more AI work than your team can carry into production, see how we work as an engineering partner for IT teams, or read how we approach AI implementation from a working demo to production. If you are still deciding whether to build it yourself, buy a product or bring in help, our build vs buy vs partner framework walks through the trade-offs.

Get in touch and tell us which AI feature is stuck. We will tell you honestly whether the fix is code, ownership, or both.