AI Adoption Is Not
a Tooling Problem

I have been making a quiet assumption in my work for the last 18 months. That AI adoption is a tooling problem. Use better tools, get better results. I was wrong.

The teams I have watched struggle with AI – and there are more of them than the LinkedIn highlight reel suggests – were not struggling because they had bad tools. They were struggling because they adopted AI into processes that were never designed for it.

Three patterns kept appearing:

The tools worked fine. The systems around them were not ready.

This is the insight that changes how you think about AI adoption. The failure is almost never in the model. It is in the interface between the model and the human processes surrounding it: the requirements it receives, the tests that evaluate it, the monitoring that watches it, the deployment process that ships it. Get those interfaces right and AI performs. Leave them unchanged and AI amplifies exactly the problems that were already there – but faster, and with more confidence.

The SDLC as a Process for Two Kinds of Consumers

The software development lifecycle was designed for human consumers of its outputs. Requirements written for human developers. Tests evaluated by human judgement. Deployments monitored for human-recognisable failure modes.

AI agents are a different kind of consumer. They need different inputs, produce different outputs, and fail in different ways. The SDLC phases below are not broken. They need to be extended – not to accommodate AI as a novelty, but because AI is now a first-class participant in each phase.

Here is where I have seen things go wrong, one phase at a time:

None of these failures required the AI to malfunction. In every case, the model did exactly what it was asked to do – correctly, quickly, and with confidence. The problem was in what it was asked to do, in the absence of the right guard rails, in the lack of visibility into what it was doing, and in the failure to design for how it changes over time.

Scoped, Not Constrained

There is a pattern in those nine failures, and it is worth pulling into the open. In every one of them, the agent received intent but not the deliverable's definition. The industry has spent fifty years writing those definitions down: the user story with acceptance criteria, the architecture document, the failing test, the service level objective. Every phase of the SDLC already knows what its output looks like when it is done well. We just stopped handing that knowledge to the newest member of the team.

The word that matters here is scoped. Not constrained: scoped. A constraint closes the solution space and tells the model what it may not do. A scope draws the boundary of the deliverable and leaves the model free inside it. An agent told to write tests will produce tests of some kind. An agent handed the test pyramid, the coverage bar, and a standard for sizing the functional test matrix produces the deliverable the phase was always supposed to produce. Same freedom inside the boundary. A very different boundary.

Standards amplify AI for a reason that is easy to miss: the model has already read them. A template the industry wrote down ten thousand times is a shape the model knows from training, which means a mature standard does three jobs at once. It is a vocabulary the model already speaks. It is a contract that defines what done means for this phase. And it is a rubric that a reviewer, human or machine, can grade the output against. Nothing else in your process does all three.

Notice what none of this changes: the deliverable, and the bar it has to clear. An architecture document is judged the way it always was. A test matrix covers what it always had to cover. The producer changed, and the human moved one seat over, from writing the deliverable to evaluating it against a standard both sides can read. That is also why the phases with the most mature standards are adopting AI fastest: there was already a written answer to what good looks like, and the model can be held to it.

Each phase of the SDLC has a specific failure mode when AI is introduced without adapting the process. The next articles in this series go deeper – one phase at a time, with concrete changes that actually move the needle, not frameworks that sound good in a diagram.

Some of This Is Slightly Unpopular

The positions in this series are specific. Some of them push against prevailing opinion. That is intentional – not for the sake of being contrarian, but because the prevailing opinion is often shaped by people with something to sell.

I might be wrong on some of it. The honest position in a rapidly changing field is to say something specific and be correctable, rather than say something vague and be agreeable. Vague agreement produces no learning for either of us.

In that same spirit: a fair thing to ask anyone who writes about AI adoption is whether they live in it or only talk about it. So here is my own last thirty days, unedited.

I show this not as a flex but as the exact thing this article argues against. A usage chart is tooling adoption made visible, and it is the easy part. It can tell you how much AI someone runs; it cannot tell you whether the requirements were written for a non-human implementer, whether the tests know what “correct” means, or whether anyone would notice the day the output quietly began to drift. The hundred and forty million tokens are not the achievement. The processes around them are where the real work – and the real failure – actually live.