Lately, I’ve noticed something interesting in enterprise conversations around AI.
When a new business problem comes up, the discussion sometimes moves very quickly toward AI.
And now, there is an even newer question:
“Can we build an AI agent for this?”
I understand why. AI agents are exciting. LLMs can solve problems that were difficult to imagine solving a few years ago.
But I think we need to pause sometimes.
I recently came across a situation where the problem was essentially rule-based.
The rules were known. The conditions were defined. The expected outcome was predictable.
Yet the conversation was moving toward an AI-based solution.
Not because the problem required AI, but because AI—and particularly agents—are becoming such a popular direction.
That made me think:
Are we choosing the technology because the problem needs it, or because the technology is trending?
And this isn’t really an AI question.
It’s an engineering question.
Let’s take a simple example
Imagine a company has this requirement:
The business gives us three rules:
- Order value above €50 → free delivery
- Premium customer → free delivery
- Otherwise → standard delivery fee
Now imagine someone says:
“Why don’t we build an AI agent to decide this?”
We could.
We could connect an LLM, give it the rules, build an agent around it, and create all the infrastructure required to operate it.
But ask yourself:
What problem are we solving that traditional programming cannot already solve?
Nothing.
The rules are explicit. The outcome is predictable.
A few lines of code can solve the problem reliably.
It will probably be easier to test, easier to explain, cheaper to operate, and more predictable.
So in this case, adding AI doesn’t make the solution better.
It just makes it more complicated.
Now change the problem
Suppose the requirement becomes:
Now things are different.
There may be millions of historical customer records, usage patterns, transactions, support interactions, and changes in behaviour.
There may not be a simple rule that tells us which customer will leave.
Now Machine Learning could make sense because we’re trying to learn patterns from data.
Change the problem again.
Now we’re dealing with unstructured language.
Customers can express the same request in hundreds of different ways.
An LLM could be useful here.
We could build an application around the model to understand the email, extract information, generate a response, and integrate with our existing systems.
The problem changed. So the engineering approach changed.
And then comes the agent
Now imagine the requirement becomes more dynamic.
The system needs to understand a request, decide which systems or tools to use, gather information, determine the next step, and potentially take different actions depending on what it discovers.
Now an agent-based approach may make sense.
But notice something important:
We didn’t start by deciding to build an agent.
We started with the problem.
That’s the distinction I think we sometimes miss.
An agent isn’t automatically a better solution than a traditional workflow.
If the steps are fixed and predictable, conventional application logic may be simpler.
If the system genuinely needs dynamic decision-making, tool usage, and multi-step reasoning, an agent may be worth considering.
The problem should determine the architecture—not the trend.
Technology isn’t a ladder
Sometimes we look at technology as if we’re supposed to keep moving upward:
Traditional Programming → Machine Learning → Deep Learning → LLMs → Agents
But these aren’t levels in a game where the latest technology is automatically the best one.
They are different approaches for different problems.
If the rules are known, traditional programming may be enough.
If we need to learn patterns from data, Machine Learning may be appropriate.
If we’re dealing with complex unstructured data, Deep Learning may help.
If understanding or generating language is central to the problem, LLMs may be appropriate.
And if the problem genuinely benefits from dynamic planning, tool use, and multi-step decision-making, an agent may be appropriate.
Sometimes, the final solution may even combine several of these.
The important part isn’t how many technologies we can put into the architecture.
It’s knowing why each one is there.
Start with the problem
When a business gives us a problem, perhaps our first question shouldn’t be:
Instead:
- What exactly are we trying to solve?
- Are the rules already known?
- Is the problem deterministic or uncertain?
- Do we need to learn patterns from data?
- Is the input structured or unstructured?
- Does the problem actually require language understanding?
- Does it require dynamic, multi-step decision-making?
- What are the cost, reliability, latency, and maintenance implications?
Only then should we choose the technology.
Because sometimes the answer will be AI.
Sometimes it will be an LLM.
Sometimes it will be an agent.
And sometimes…
it’s just a simple if statement.
And there is absolutely nothing wrong with that.
Good engineering is about judgment
AI is moving incredibly fast.
Every few months, there is a new model, framework, architecture, or trend.
It’s easy to get caught up in it.
But our responsibility as engineers isn’t to use the newest technology everywhere.
It’s to build something that solves the problem effectively.
Good engineering isn’t about using the most advanced technology.
It’s about choosing the right technology for the problem.
So before we build an AI solution, perhaps the most valuable question we can ask is surprisingly simple:
That question might save us more than development effort.
It might save us from building something that never needed to exist in the first place.
At DataKern, this is one of the ideas I want learners to develop—not just the ability to use AI technologies, but the judgment to understand when to use them, how to use them, and when not to use them.
Because becoming a good AI engineer isn’t about knowing how to build everything.
It’s about knowing what needs to be built.