AI in practice

We gave everyone AI. Then we went looking for the value.

Earlier this year we could describe everything we had built with AI and almost nothing about what it had changed. This is the first of a series on what we did about that.

In short
  • Capability is easy to describe and easy to admire. Value is neither.
  • We could list what we had deployed and could not say what any of it had changed.
  • Nobody had agreed what would count as working. Everything else followed from that.
  • Everything in this series follows from deciding that question before deciding anything else.

There is a comfortable stage in an AI programme where everything looks like progress. New capability arrives every few weeks. People find uses for it that nobody planned. Demonstrations go well. Nothing is obviously wrong.

We spent a while in that stage.

We had put AI into consulting work, into software engineering, into how we manage what the business knows, and into delivery. We could describe all of it. Asked what it had changed about the business, we had anecdotes and a strong collective feeling that things were better.

That is not an answer. It is the absence of one, said confidently.

The gap was not technical

The models worked. The tooling worked. Nobody was waiting on a platform decision. What was missing was earlier and duller than any of that: nobody had agreed what would count as working.

Without that agreement, every conversation about AI value turns into a conversation about AI activity, because activity is the thing you can actually see. How many people are using it. How much it produced. How fast. All measurable, and none of it evidence that anything downstream moved.

You can run a long way on that and still not know whether you are ahead.

Why we are writing this down in public

Two reasons.

The first is that our clients are in the same position and will not say so. In boardrooms the AI conversation has moved from what it can do to what it has done, and the second question is much harder to answer than the first. Pretending otherwise helps nobody.

The second is that the useful parts of what we learned are the unflattering parts. A case study describes a success. What we wanted to write down is the sequence of corrections: the assumptions that turned out to be wrong, and what we changed as a result. That is more useful to someone facing the same decisions, and it is harder to fake.

The four corrections, in order

We will work through them in the sequence we hit them, because the sequence turned out to matter.

The first correction was about what the model reads. Before AI could do anything worth measuring, the knowledge it worked from had to be exposed and current. Ours was neither in the places that mattered.

Next came where that knowledge and processing physically sit. In this region the lawyers reach that question before the architects do.

The third was about delivery: what reuse actually buys you once AI assistance enters the picture, why the build-or-buy framing sends people down the wrong path, and what changes about accountability when a tool is drafting the work.

Measurement itself took longest. When we finally measured what the work changed downstream, several things we believed turned out to be wrong.

What it changed in how we run a client project

We made each correction on our own business first. Every one of them has since become part of how we run work for clients, and each piece in this series ends somewhere a client can see it on an engagement. Sprint 0 is designed to end with a working prototype the client has used and approved, and nothing an AI tool drafted reaches a client until a named engineer has reviewed it.

How that engagement runs, and where a person signs, is set out on AI-assisted engagement and delivery.

Where we started

The honest starting position, in June, was this. We had built a lot. We had deployed a lot. We could not tell you what it was worth, and we had not yet admitted that to ourselves clearly enough to do anything about it.

Everything that follows came from asking one question and refusing to accept an activity metric as the answer: what changed in the business because we did that?

The next piece looks at what we found when we followed that question back to its source, which turned out to be the state of our own knowledge.

Sources
  • Internal operating experience, nVisionIT. No performance figures are quoted in this article.
Keep reading

More from Insights

AI in practice

Activity is not progress

Last of three. A process can be dramatically faster while the business barely moves. The smaller number was far less impressive and much more useful.

18 September 2026 · 4 min read
AI in practice

The programmes that stall are short of a question

Ask why an AI programme stalled and the answer comes back technical. Underneath it there is usually a question nobody had formed properly, with nobody waiting for the answer.

7 September 2026 · 4 min read