Not Everything Needs AI

Every major technology wave brings the same temptation: find somewhere to add the technology first, and ask whether we actually needed it later.

We have seen this before.

Cloud became the answer before anyone asked the question. Kubernetes became the default before teams understood the operational cost. Microservices became the architecture before people understood the trade-offs.

Now it is AI.

Every product needs an AI assistant. Every dashboard needs a chatbot. Every company needs an AI story. Senior leadership wants to be able to say “we have AI”, and vendors are more than happy to provide another feature, another subscription, and another set of usage costs.

But the question engineers should always ask remains the same:

What problem are we trying to solve?

AI is not the exception.

The technology trap

The problem I have is not AI itself.

The problem is the same one we see with every technology: confusing the capability with the solution.

A tool existing does not mean we have a problem that requires it.

We have seen this in infrastructure countless times.

A team starts with a simple application. Then comes Kubernetes. Then autoscaling. Then observability. Then Karpenter. Then GitOps. Then policy enforcement. Then service mesh. Then distributed storage.

Every individual decision might be reasonable.

The problem is not any individual choice. The problem is the accumulation of choices.

But eventually, you have built a platform that requires more infrastructure to operate than the application it was designed to run.

Not everything needs a touchscreen

Years ago, there was a trend where everything needed a touchscreen.

Cars replaced physical controls with touch interfaces. Appliances gained screens. Every device wanted to be “smart”.

But a touchscreen is not automatically a better interface.

Sometimes a physical button is better because it is immediate, predictable, and does one thing well.

The same applies to AI.

Not every workflow needs a conversational interface.

If I need to create a DNS record, a simple form is probably better than asking an AI assistant to create it for me. The AI layer does not remove meaningful complexity. It adds another abstraction between me and the thing I am trying to accomplish.

The impressive technology is not always the useful technology.

Sometimes the best solution is the one that gets out of the way.

The technology trap applies to AI too

The same pattern is now appearing with AI.

A product adds an AI assistant because AI exists. A dashboard gets a chatbot because chatbots are popular. A workflow gets an AI layer because leadership wants an AI story.

But does it make the user more effective?

Does it reduce friction?

Does it solve a problem that could not be solved more simply?

Those are the questions that matter.

The AI conversation online often feels like two loud groups arguing past each other.

On one side, there are people convinced AI is going to transform everything. On the other, there are people who see only the risks and problems.

Most engineers I know are somewhere in the middle.

We use these tools. We benefit from them. We are also aware of the concerns around them.

I use LLMs regularly. Not in some “AI is revolutionising my entire workflow” way, but in practical ways engineers have always used tools:

• writing repetitive code;
• debugging unfamiliar errors;
• exploring ideas;
• explaining concepts;
• helping get unstuck.

Sometimes it is genuinely useful. Sometimes it saves significant time.

That does not mean every concern disappears.

The questions around training data, copyright, energy consumption, and the impact on jobs are real. The fact that a tool is useful does not mean every aspect of how that tool exists should go unquestioned.

Both things can be true:

AI can be useful, and AI can create legitimate concerns.

The problem is that nuance rarely survives online discussion. Saying “I use AI” is often interpreted as supporting everything about it. Raising concerns is often interpreted as rejecting the technology entirely.

The reality is much more complicated.

AI should remove complexity, not become another layer of it

Engineers spend a lot of time making trade-offs.

Performance versus cost.

Flexibility versus simplicity.

Automation versus control.

AI deserves the same level of consideration.

The best AI implementations are not the ones that add the most intelligence. They are the ones that quietly remove friction, reduce cognitive load, and allow people to focus on work that actually requires human judgement.

Summarising hundreds of logs during an incident. Finding patterns in large amounts of data. Helping understand unfamiliar code. Reducing repetitive cognitive work.

In each of these cases, AI is not replacing a simple workflow. It is helping with tasks where the complexity already exists.

The question is not whether AI is impressive.

The question is whether it makes the person, workflow, or system better.

AI should remove complexity, not become another layer of it.