What 25 Years in IT Changed About How I Build AI Systems
A lot of AI writing still treats the field as though it belongs only to people who arrived recently and speak the language of novelty well.
My experience has been almost the opposite.
The more serious the AI and automation work becomes, the more useful traditional technology judgement turns out to be. Architecture still matters. Governance still matters. Security still matters. Supplier choice, rollback planning, monitoring, documentation, cost control, and change discipline all still matter. In fact, they often matter more because AI systems can amplify weak decisions very quickly.
That is probably the biggest lesson I have taken from the last few years of building with AI: the tools changed fast, but the value of good operational judgement did not disappear. It compounded.
AI did not replace the old disciplines
When people first encounter modern AI tooling, it is easy to assume the game has changed completely. A model can draft, classify, transform, summarise, route, and generate code quickly enough to make the old pace of delivery feel almost irrelevant.
But speed has a side effect. It makes poor discipline more dangerous.
If you automate a weak process, you do not get magic. You get a weak process that now runs faster.
That is why so much of the work that actually matters around AI ends up sounding familiar to experienced operators:
- which systems are trusted and why?
- what happens when the preferred path fails?
- what evidence proves the output is acceptable?
- how do you stop sensitive data leaking into the wrong place?
- how does another operator understand what the workflow is doing?
- what is the recovery path when the model, provider, or orchestration breaks?
Those are not “AI-native” questions in the hype sense. They are technology leadership questions.
The old instincts became more valuable, not less
The part of my background that translated best into AI work was not prompt novelty. It was years spent dealing with production environments, supplier behaviour, security trade-offs, failure modes, and the gap between what a system is supposed to do and what it actually does under pressure.
That experience changes how you build.
You become less impressed by isolated demos and more interested in whether the operating model survives repetition. You care earlier about routing logic, secrets handling, observability, fallback design, change control, and how much trust the workflow deserves by default.
That is not because AI is less exciting than people think. It is because once it becomes useful, it starts inheriting all the obligations of serious systems.
What actually changed in practice
The shift for me was not “IT versus AI”. It was a widening of the same operating model.
Traditional infrastructure thinking helped in a few concrete ways:
Governance before scale
It is tempting to let AI experiments grow informally because they start out lightweight. But the point at which they begin touching customer-facing work, internal decisions, or automated operations is exactly the point where governance has to stop being optional.
Cost and routing matter early
AI systems can look commercially attractive right up until nobody is managing provider choice, workload placement, or fallback behaviour properly. Cost discipline is not a finance afterthought. It is part of system design.
Monitoring has to reflect real behaviour
An AI workflow being “up” does not mean it is behaving correctly. The useful checks are the ones that prove the real path, the real output shape, and the real operational result.
Documentation is part of the product
If the workflow depends on one person's memory, it is not mature no matter how clever it looks in a demo.
Why this matters for clients
One reason I think experience matters in this space is that most businesses do not need AI theatre. They need systems that fit into an already messy commercial reality.
That means:
- integrating with existing platforms
- handling risk and data sensibly
- making supplier choices that do not trap the business later
- improving operations rather than just generating novelty
- creating an operating model that other people can own
That work sits at the intersection of AI capability and ordinary executive judgement. It is less about sounding futuristic and more about making sure the thing stands up once somebody depends on it.
The real transition
If there has been a transition, it is not from “old IT” to “new AI”. It is from applying technology judgement to slower-moving systems to applying it to faster-moving ones.
That is a meaningful change. But it is not a rejection of the old disciplines. It is an argument for bringing them with you.
The organisations that get the best value from AI are usually not the ones chasing the most noise. They are the ones combining experimentation with governance, speed with control, and automation with a clear operating model.
That is where the work becomes commercially useful.
And that is where experience starts looking less like history and more like leverage.
If you want AI systems that benefit from modern tooling without abandoning the disciplines that keep production environments trustworthy, the AI & Automation Architecture work is built around exactly that balance. Or get in touch if you want a practical conversation about how to turn AI experimentation into something your business can actually rely on.