Skip to content
AI Delivery AI DeliveryTechnology Leadership

The adult in the room: what eighteen years taught me that AI can't

AI made building almost free. Surviving production is as hard as it ever was — and that gap is the whole game.

· 4 min read

You can build almost anything now. I can, you can, and so can the marketing coordinator who’s never opened a terminal. Describe the thing, wait a few minutes, and there it is: a working app, a slick demo, something that looks finished.

For a while this genuinely rattled me. I’ve spent eighteen years as a CTO — the person whose job was knowing how to build things. When the hard part, the actual making, stops being hard, you’re entitled to wonder what’s left of you. I did that maths at 2am more than once this year.

Then I watched what happens next. Not to me — to the things people build this way.

Here’s the pattern, and once you’ve seen it you can’t unsee it. Someone talented and fast ships something that works. Real users, real money, a demo that dazzles. And then, six months on, the wheels come off in ways that have nothing to do with whether the idea was any good: the credentials nobody rotated, the tests nobody wrote, the security holes nobody thought to look for, the database that fell over the first time real traffic hit it, the roadmap that quietly lost a fight with marketing. The building was never the problem. Surviving was.

Because a demo and a system are not the same thing. A demo has to work once, on a good day, for a friendly audience. A system has to work every day, on the worst day, when a real customer is doing something you never imagined and the person who built it is on annual leave. The gap between those two is where most projects quietly die — and it’s a gap AI has done almost nothing to close. It’s made the demo free. The system is as hard as it ever was.

That gap is where I’ve spent my whole career. And the thing I know about it — the thing you cannot generate, only earn — is what actually breaks when the demo meets a real business. That’s not knowledge you get from a model. It’s knowledge you get from being in the room when it went wrong, usually more than once, usually at your own expense.

So here’s the part that surprised me. When I built my own system this year — an agent setup that specs and ships work for me across a couple of dozen projects — I didn’t vibe-code it. I’d have been a hypocrite if I had. I built the boring part first: a governance layer that interrogates my own ideas before anything gets made. It asks the annoying questions. It refuses to let a vague brief through. It makes me define what “done” actually means before a line of it exists.

And it earned its keep by catching me. More than once it kicked my own briefs back as badly scoped before a single thing got built — one was quietly the wrong shape entirely, leaning on something I hadn’t built yet. I’d have discovered that halfway through, the expensive way. The system found it in the first ten minutes, the cheap way. That’s the whole game: moving the discovery of your mistakes from after you’ve built the wrong thing to before.

It’s not magic, and I’ll be honest about where it isn’t. On one bigger build, the thing drifted anyway — scope crept, features I hadn’t asked for snuck in, and it stopped being disciplined and became a normal, slightly messy coding session. I know this because I logged it, out loud, as a gap in my own system rather than pretending it hadn’t happened. That’s the actual difference. Not that I never hit the problem — that I see it, name it, and know what it costs, because I’ve hit it a hundred times before.

Here’s the moment it all clicked. I was mid-build on something, using one of the newer AI models to do the work, when that model got pulled — an export directive, out of my hands, gone overnight. Inconvenient. Except it wasn’t, really. I pointed the work at a different model and it finished the job without breaking stride. And that’s the whole thing in one anecdote: the model doing the building is a commodity. Swappable. The value was never in it. The value was in the spec, the governance, the judgement about what to build and whether it would hold — the part that stayed exactly the same whichever engine was running underneath.

So no, I don’t think I’m being made redundant. I think I’m being repointed. Same job I’ve always done — decide what’s worth building, work out whether it’ll survive, keep everyone honest while it gets made — aimed at a new kind of vendor. That vendor used to be an offshore shop with a good slide deck. Now it’s a brilliant, over-caffeinated builder who can ship in a weekend and can’t yet tell you which of those weekends ends in a 2am incident with a real client’s money on the line.

That’s the seat I’m taking. Not because AI worries me — I love the stuff, I run my whole operation on it — but because I’ve watched enough good projects die in the gap between it works and it survives to know that gap isn’t going anywhere. It’s about to get very crowded.

Someone should be the adult in the room. Turns out the thing I was afraid of losing was the one thing that can’t be automated.

Frequently asked questions

If AI can build almost anything, what's left for a CTO to do?

Decide what's worth building, work out whether it will survive contact with a real business, and keep everyone honest while it gets made. AI has made the demo free; the system is as hard as it ever was, and knowing what actually breaks in production is the part you can't generate.

What's the difference between a demo and a system?

A demo has to work once, on a good day, for a friendly audience. A system has to work every day, on the worst day, when a real customer is doing something you never imagined and the person who built it is on leave. The gap between the two is where most projects quietly die — and AI has done almost nothing to close it.

Doesn't using AI to build your own tools make you a hypocrite about governance?

Only if you skip the governance. I built the boring part first — a layer that interrogates my own briefs before anything gets made, refuses vague scope, and forces me to define what done actually means up front. It earns its keep by catching my own mistakes early, the cheap way, rather than halfway through the wrong build.

If the model doing the building can be swapped out overnight, where's the durable value?

In the spec, the governance, and the judgement about what to build and whether it will hold — the part that stays the same whichever model is running underneath. The model is a commodity; the thinking is not.

Found this useful?

I write about technology strategy, platform decisions, and the realities of digital transformation. If you're working through something similar, I'm happy to have a conversation.

Related reading