Years ago, I took a process that ran for 25 hours and got it down to 5 minutes.
No new hardware. No rewrite. What everyone believed about it turned out to be wrong - and almost nobody had thought to check.
It was a game studio. Every artist dwelt there with the same tax: change one object in a level, start a build, and lose the better part of a day waiting to see it - your machine crawling the whole time, and God help you if it crashed or rebooted before it finished.
Almost all of that time sat in one stage of the build: texture palettisation and compression. The code was considered fearsomely complicated; only one engineer claimed to understand the mathematics, and I was told more than once that there was no point looking into it. So nobody did.
I accepted that too - at first. Then, against my lead's explicit instruction, I started measuring how the time was actually being spent. Not the done thing, going about him like that. But the cost had become absurd.
I didn't need to understand all of the mathematics first. I needed to measure where the time was actually going.
The algorithm itself wasn't the issue. Buried inside it was a small operation being repeated millions of times. Fix that one spot, and twenty-five hours became five minutes.
What stayed with me wasn't the result. It was how long all of us had accepted the first explanation - an assumption that had quietly cost every artist a full day, on every single build, for a very long time.
That is what I mean by an expensive assumption.
Once you start looking, you find them everywhere. A finance system's dozens of unrelated slowdowns turned out to share one hidden cause nobody wished to touch. A healthcare application everyone assumed was slow because it held more data was actually recalculating the same unchanging figures, over and over. A performance problem inside Unreal Engine - one affecting some of the biggest games in the world - came down to a single character in a source file. Different industries, same shape: a reasonable-sounding assumption nobody had thought to question.
After thirty years, if one lesson has followed me everywhere, it is this:
{=html}<aside class="pullquote">
The biggest improvements rarely come from adding more - more effort, more tools, more technology. They come from questioning assumptions everyone else has stopped noticing.
{=html}</aside>
Which brings me to AI.
Like everyone else, I started by asking it to do things. Write this. Summarise that. Analyse this document. Generate that code. It was good at all of them.
Then one day I caught myself asking it to perform the same task for the fiftieth time, and I stopped.
The question was no longer can AI do this? It was why am I asking it to do this, over and over again?
That single thought completely changed how I think about AI. What interested me more was whether some of those questions should need asking at all.
AI doesn't need to become another employee
Most of us reach for AI as though it were another person in the office. We give it work. It gives us an answer. Tomorrow we hand it more work, and it gives us another answer.
There's nothing wrong with that. If it saves someone thirty minutes a day, that's worth having. But it's worth asking what you actually own at the end of a year.
Imagine someone in your HR department reviews two hundred CVs a month. Using AI to summarise each one is a sensible first step - far faster than reading them by hand. Twelve months and thousands of CVs later, what does the business actually know?
Can it tell you whether the candidates AI rated highly were the ones you hired? What your best people had in common? Whether your hiring improved at all?
Probably not. Every conversation started from scratch. You didn't buy an asset. You paid for the same answer thousands of times.
There is also something faintly absurd about using a powerful general-purpose model only to produce the same little summary two hundred times a month. It may save time, but you've still designed a process in which the useful knowledge disappears after each transaction.
That was the moment something changed for me.
{=html}<aside class="pullquote">
AI shouldn't be doing the repetitive work. Maybe it should be helping us
<em>{=html}remove</em>{=html} it.
{=html}</aside>
Instead of summarising two hundred CVs a month, what if it helped you build a small internal tool - one that pulled out the important details automatically, stored them consistently, and quietly tracked who was interviewed, who was hired, and who was still there a year later? Six months on, it might surface patterns that no individual could ever spot.
AI is still involved, but in a different place: helping improve the system rather than being asked to repeat the same clerical task.
I found the same thing in my own work. Rather than pouring gigabytes of raw measurements into AI, I let my own software handle the repetitive part - finding what matters, comparing it with last week, and remembering every result. Only then do I bring AI in, and only to reason about the evidence that's left.
The software keeps the history. I can then use AI for the part I care about: reasoning over that history.
I still use AI dozens of times a day. The difference is that I'm no longer asking it the same questions over and over. I'm asking it to help build systems that mean those questions never need to be asked again.
For me, AI gets more interesting here - not because it replaces people or writes code, but because it helps redesign the way work flows through a business.
Evidence changes everything
The quality of an answer depends far more on the quality of the evidence than on the intelligence of whoever - or whatever - is analysing it. That's as true for AI as it is for people.
Hand an AI the full source code for a game and ask it to "optimise this," and it's almost stuck before it starts. It can find expensive-looking functions and make them faster - but it has no way of knowing which ones matter.
Suppose there's a function that draws the Earth in fine detail, and it takes a noticeable time to run. AI spends twenty minutes brilliantly optimising it. Unfortunately, it runs exactly once, in a ten-second cutscene at the very end of the game. Meanwhile, a humbler function that draws a tree is slightly inefficient and runs 10,000 times per frame. That's where the real problem lives - and without evidence, neither the AI nor most programmers would know.
Add the measurements, and everything changes. Now we know how often each function runs, what it costs, and whether things have improved or worsened since last week. We're no longer asking AI to guess. We're asking it to reason from evidence.
The distinction matters enough that I've found it useful to give it a name.
Most of what flows through a business is raw information. What I'm describing is what's left after the hard part: information that has been measured, filtered, contextualised and validated to the point where it can directly support a decision. I call it Decision-Grade Evidence, or DGE. It is data that has been made useful enough to support an actual decision.
Engineers have already built something close to this idea. Physics-informed AI constrains a model with the laws of physics, so it can't waste its time proposing answers the real world would never allow. The model hasn't become more intelligent - we've improved the quality of the information that informs its reasoning.
I'd argue that a great many businesses should be going for the same move - not more AI, but DGE-informed AI: AI that reasons from decision-grade evidence rather than raw information. The model is the same; the quality of its input is better.
It took me a while to see this in my own work. The profiling tool I'd spent years building isn't really an optimisation tool at all - it's a Decision-Grade Evidence generator. Its whole job is to take millions of raw measurements and reduce them to a handful of facts solid enough to act on: which function actually matters, what it costs, whether last week's change helped or hurt. The optimisation was always just what happened next. The evidence was the point.
Which is why the biggest opportunity for most businesses isn't adopting AI at all. It's building better evidence. Raw data is cheap, and everyone has it. Decision-grade evidence is expensive to build - and that gap is exactly where the opportunity lives.
Raw data is cheap. Decision-grade evidence is expensive to build.
Every organisation already has data - sales figures, support tickets, customer feedback, financial reports, sensor readings. The problem is rarely a shortage of information. It's that the information sits in a dozen disconnected places, gathered in different ways, with no history. People end up deciding on fragments.
This is where software and AI fit together. Software collects patiently and never forgets. AI is remarkably good at looking at what software has gathered and asking the questions people don't think to ask:
Why did this suddenly change?
Why do sales always dip after this event?
Why is this process taking twice as long as it did six months ago?
Those require more than producing another report. I think this is the part many businesses underestimate: they see something that answers questions, when the real value is something that asks better ones.
The simplest way I've found to put it is this:
{=html}<aside class="pullquote pullquote-plain">
<b>{=html}Software</b>{=html} remembers.
<b>{=html}DGE</b>{=html} guides. <b>{=html}AI</b>{=html}
reasons. <b>{=html}People</b>{=html} decide.
{=html}</aside>
I now spend less time hunting for places to add AI and more time looking for decisions that are being made on weak or incomplete evidence.
For me, it went further than that. Somewhere along the line I realised I'm no longer trying to build better AI systems. I'm trying to build better evidence. Better evidence doesn't just produce better decisions. It produces better questions. The AI benefits as a result.
So where do we go from here?
You'll have noticed I've said almost nothing about prompt engineering, AI agents, or which model to use. That wasn't an accident. Those things matter, and they'll keep improving at a remarkable pace - but I don't think that's where the lasting value sits.
The organisations that benefit most from AI won't be the ones with the biggest budgets or the newest tools. They'll be the ones that get better at questioning how work flows through their business.
Every company has processes everyone quietly accepts. Reports that have always been produced. Meetings that have always been held. Approvals that have always been required. Data entered twice. Calculations repeated. Sometimes they still make perfect sense. Sometimes they're expensive assumptions nobody has challenged in years.
AI gives us a reason to revisit them - not because it knows the answer, but because it prompts the questions we should have been asking all along:
Why does this exist?
Who benefits from it?
What decision does it actually support?
If we were starting the company today, would we build it this way?
Every so often the answer is, "Yes - we already do this the best possible way." Good. Far more often, it's, "I'm not actually sure." That's where it gets interesting.
I don't see AI as another employee waiting in the corner for work. I see it as another engineer - one that never tires of an idea and is happy to challenge an assumption, but that still needs good evidence, good questions, and a good team around it.
So the next time you catch yourself asking, can AI do this for us?, try a better question first:
Why are we doing it this way at all?
You might find AI isn't the answer. You might find something way better. Either way, you'll be asking a better question.
{=html}<aside class="pullquote">
For thirty years I've made a career out of finding expensive
assumptions. AI hasn't changed that. If anything, it's made them
<em>{=html}easier to see</em>{=html}.
{=html}</aside>
Comments