AI operating models: why AI programmes stall at month six

Most AI rollouts look the same on paper: everyone gets a licence and a training session. Six months later, usage is up, satisfaction is mixed, and the executive sponsor cannot answer the question the board keeps asking. Has anything actually changed?

The failure is rarely budget, buy-in, or the tools. It is sequencing.
AI capability is two-dimensional, and most leadership teams are investing on the wrong axis first. The activity is real, but the capability it produces is thin, and by the time that becomes obvious, the programme has spent its political capital alongside its budget.

We have been designing AI operating models inside live engineering organisations long enough to see the pattern repeat. Here is the framework we use to break it.

The matrix

The framework is a 2x2. One axis is Individual against Workflow. Individual refers to how each person works with AI: their setup, context files, and prompting habits. Workflow is how the team delivers with AI: the pipeline from raw input through specification, implementation, review, testing, and release.

The other axis is Base against Advanced. Base is the minimum standard you want every team and every role to reach, regardless of domain. Advanced is the domain-specific work, where a particular codebase, system, or regulatory boundary shapes AI capability.

Each cell answers a different question and produces a different shape of work. But only one of them should be the first investment. We will come back to which one, and why, after naming the two patterns that get in the way.

The two patterns we keep seeing

The first is tool first, workflow never. The organisation has bought licences for everyone to a general-purpose AI assistant. Adoption is high, output is faster in places. But nothing has changed about how work flows through the team. That is Base + Individual investment without any Base + Workflow follow-through. The team gets faster at the parts of the job that were never the bottleneck, while the bottleneck stays exactly where it was.

The second is workshop first, repo never. The organisation has run training sessions, and people learned plenty in the room. But the skills did not survive the walk back to the codebase because nothing had been committed to the repository to help an engineer apply what they had learned to their own work the next morning. The week-three energy fades into the week-twelve baseline.

Both patterns spend real money but neither produces capability. And both are diagnosable in advance, if you place the planned interventions on the matrix before you fund them.

What discovery actually surfaces

In a recent engagement with a large digital engineering organisation, we ran 11 structured discovery conversations with major engineering streams and transversal teams, inside a four-week foundation phase. The goal was to find where work actually backed up, not to validate assumptions about where AI could help.

Four findings emerged independently and consistently, from every area we visited.

The first was that requirements quality, not coding speed, was the dominant constraint on delivery throughput. Unclear specifications led to rework, missed edge cases, and coordination costs that no AI coding assistant could resolve. The AI coding assistant lives downstream of the bottleneck. The outsourced delivery model the organisation operated under in some streams increased costs because each round trip with an external partner incurred real overhead.

The second was that testing culture existed but carried two to three years of accumulated debt. The infrastructure was in place; the coverage gaps were real. AI assistance on tests had been tried in pockets, with mixed results, partly because the tests were being generated against codebases the model had never been given context for.

Two further findings shaped the work but point downstream of this post: testing carried years of accumulated debt, and individual adoption was already ahead of the organisation’s guidance. Both are context problems; one of them will deserve its own blog post.

These findings led to our first investment. Not in the Individual axis, where the team was already further ahead than the organisation’s guidance. Not in the Advanced cells, where each domain would have its own work to do once the foundations were in place. In Base + Workflow: the upstream of the engineering pipeline, where raw notes, stakeholder emails, and incomplete specifications become the structured inputs the rest of the team builds against.

What we committed in the first six weeks

Three artefacts carry the engagement forward. A slide deck delivers capacity; each of these delivers capability.

1. A segmented playbook: it describes which workflows to use, when, and how, across the four quadrants. It is structured as a chapter that fits the organisation’s existing change process, not as a standalone document the consultants own. That structural detail matters more than the content. It is the part that decides whether the playbook survives after we leave.

2. A repo onboarding kit: a small set of files committed to the root of each priority repository, a CLAUDE.md with project context, a conventions/ folder of team rules made writable, a commands/ folder of named workflows, a review checklist, and testing rules. None of it is product code, and all of it decides whether the same model meets the team’s standards. What goes into the kit and what it costs to own are distinct, which we cover in our post on the repo onboarding kit.

3. A pilot portfolio: approximately five pilots across the complexity spectrum, each mapped to a cell on the matrix, each designed to produce a board-readable before-and-after. Three confirmed in the first wave. Each one selected for readiness, strength of proof, and replicability, so the results are transferable to other teams.

The pilots spread deliberately across the grid. In Base + Individual sat a team already using AI informally, whose work was to formalise what was working rather than introduce anything new. In Base + Workflow, the first-investment cell, sat the proof pilots: an authentication rebuild replacing an external dependency, and a feature team running the full pipeline themselves, from raw notes to release. The Advanced cells held the domain-specific work that only made sense once the foundations were in place: infrastructure-as-code generation and a non-standard commerce stack in Advanced + Individual, and a logistics platform with unstable requirements and a multi-brand design system in Advanced + Workflow. The point of mapping each pilot to a cell before starting is that the proof is legible: you know which question each pilot is answering, and you do not confuse a domain experiment with a change to how the team delivers.

What the operating model looks like when it runs

In one of the workshops, we ran the full delivery lifecycle in front of the team, in their own environment, on their own codebase.

It started with a stakeholder email and two mockup images, and about 90 minutes later ended with a feature deployed to a sandbox environment that someone in the room could click through.

Each arrow in that pipeline used to be hours or days of work. In the session, each arrow was a single prompt. The first one, given to Claude after pasting the stakeholder email and dragging in the mockup images:

Create a technical specification for this feature. Include: overview, user flow, components to build, acceptance criteria, out-of-scope.

The second, run against the spec inside Claude Code on the team’s actual repository:

Break this spec into Jira stories with acceptance criteria. Create them in the [project] project.

The rest of the pipeline followed the same pattern: one prompt per step, each step producing the input the next step needed, the whole chain running on the team’s real code.

We were transparent about the staging. The pipeline had been prepared and rehearsed before the live session, with every step verified as a clean commit. We used the cooking-show analogy in the room: prepared, but proven live. The team watched it run from email to a deployed feature on their own codebase and asked the kinds of questions that only get asked once the abstract has become concrete. Most of those questions were about ownership and review, not about the model.

The 90-minute number is the one that makes the rest of the operating model legible. Once a team has seen it, the conversation about which parts to install, which to defer, and which will never be appropriate for a particular codebase becomes a real one, not a hypothetical one.

What to tell the board

The board is not really asking whether teams use AI. It is asking what has changed about how work gets delivered.

A programme running on Base + Individual investment reports velocity, story points, and tool adoption rates. All of these improve without predicting business outcomes. A programme running on Base + Workflow investment reports different numbers: specs shipped per cycle, spec-to-PR cycle time, review iteration count, rework rate after the spec has been validated. If the AI sponsor is still reporting velocity as the lead metric, the cell has not changed.

That Base + Workflow authentication pilot gives a sense of what those numbers look like in practice. It increased spec throughput from 2 to 6.4 specs per week and reduced rework on those specs from 8% to 0%. The first epic reached staging in 11 calendar days, compared with the team’s pre-AI estimate of 10-12 sprints. That sample is small and early, so it reads as a directional signal rather than a programme-wide result. But it is the right kind of number to take to a board: a workflow metric that moved, not a tool adoption rate.

The harder part is creating the conditions for the change to hold. The pattern that kills AI programmes is not scepticism from the top, but a workflow investment that fails to connect to the organisation’s existing change mechanism. Programmes that last are ones where the new workflow is owned by the team, not the consultants who designed it.

If your programme is spending political capital faster than it produces proof, the first move is to find which cell to fund and where your own work backs up. Our AI enablement for engineering teams opens with a diagnostic that maps your current AI status and defines the first investment. Book a diagnostic call to see what it surfaces.