Don't Build Big Things With AI. Build Big Things Through AI.

I’ve become increasingly uncomfortable with the phrase “AI use case”.

Not because I think AI is overhyped. Quite the opposite. I think AI is one of the most significant enabling technologies we are likely to see in our working lives. But that is exactly why I think we need to be careful about how we frame it.

Too often the conversation starts with: “Where can we use AI?”

I think the better question is: “What problem are we trying to solve?”

AI might be part of the answer. It might not. Starting with the technology tends to distort the thinking.

Don’t build big things with AI. Build big things through AI.

The distinction matters because the most interesting thing about AI is not simply that it lets us create “AI products”. It is that it is starting to change what people themselves are capable of doing.

I see that very clearly in my own hobby coding. I’m a self-taught coder and, over time, I’ve moved into what people now call vibe coding. I’ve built around ten multi-user applications this way. This is obviously not how I would approach enterprise or government production systems, and I’m certainly not suggesting that architecture, security or assurance somehow stop mattering. What it has given me is a very direct view of how quickly the capability is changing.

A year ago my development loop was fairly linear: idea, prompt, code, error, fix, repeat. Increasingly, I now spend much more time up front on intent and design, then give an agent enough context to build, test, find problems and iterate before handing the work back.

The important change is not that I’m building “AI apps”. It is that I can build things I simply would not have attempted before.

I think that scales beyond hobby coding. If a finance analyst can explore a dataset from five different angles in the time it previously took to explore one; if an operations team can prototype a process improvement without waiting for a formal development cycle; if a product manager can put a working interface in front of users before an idea becomes a project, then AI is no longer just another tool in the technology stack. It is changing the shape of delivery itself.

That has consequences for how we think about digital transformation.

For years, organisations have operated with a reasonably clear boundary: technology teams build systems and the rest of the organisation uses them. We have also spent a lot of effort trying to prevent “shadow IT”, often for very good reasons: uncontrolled data, unknown dependencies, security weaknesses and unsupported technology all create genuine risk.

AI starts to blur that boundary because creating useful software is becoming dramatically easier.

The answer cannot simply be that everyone should build whatever they like. But I’m equally unconvinced that the answer is trying to preserve the old boundary through tighter control. If people across an organisation can create front ends, automate processes and build small tools by describing what they need, attempting to prevent that entirely is likely either to fail or to suppress a significant opportunity.

The role of technology leadership therefore starts to change. The question becomes less “how do we stop people building outside IT?” and more “how do we make distributed building safe?”

That means approved environments, sensible identity and access controls, clear data boundaries, reusable patterns, visibility of what is being created and a route for useful local tools to become properly engineered and supported services when they need to. Governance does not disappear. It becomes much more about enabling safely than controlling scarcity.

I think there is a similar shift needed in how we measure value.

A great deal of digital transformation is still framed through efficiency and, ultimately, headcount: how many people will this save?

Sometimes that is entirely appropriate. But productivity improvement does not automatically translate into cashable FTE reductions, particularly when small gains are spread across hundreds or thousands of people.

AI may create value in a different way: faster decisions, better-quality work, greater throughput, broader service coverage, shorter iteration cycles and people spending more of their time operating at a higher level of capability.

The biggest AI dividend may not be fewer people. It may be more capable people.

That is also why I am cautious about creating AI teams whose job is to go looking for AI use cases. The intention is understandable, but it risks putting the technology before the problem. If the funding, team and target are all labelled “AI”, it is hardly surprising when every problem starts to look as though it needs an AI solution.

I would rather start with outcomes. What are we trying to improve? What is getting in the way? What would better look like? Then work out what combination of people, process, data, conventional software and AI gets us there.

This is less neat than having an “AI agenda”, but I think it is closer to how sustainable transformation happens.

The biggest opportunity may not be one enormous AI system or a succession of flagship AI projects. It may be something much more distributed: thousands of people becoming incrementally more capable in how they analyse, design, build, decide and deliver.

That, to me, is the genuinely transformational prospect.

Don’t build big things with AI. Build big things through AI.