A Practical Architect’s Guide to When Not to Use AI
A few days ago, I was in a discussion with a fellow solution architect.
The proposal on the table?
👉 An AI agent to transform telemetry data coming from a device into a required target format.
On paper, it sounded modern.
In reality, it raised a red flag.
This was a well-defined, deterministic, static transformation problem—the kind we’ve been solving reliably for decades using simple, predictable systems. Introducing an agent here wasn’t innovation; it was overengineering disguised as AI adoption.
And this is becoming a pattern.
The Current Problem: AI Is the New Hammer 🔨
Right now, AI has traction—massive traction.
And whenever a new hammer appears, everything starts to look like a nail.
Rule-based flow? → “Let’s add an agent”
ETL pipeline? → “Can AI optimize it?”
Data mapping? → “What about GenAI?”
This mindset is dangerous.
As architects, our job isn’t to use AI.
Our job is to design systems that are correct, maintainable, observable, and economical.
AI is a tool. Not a default.
Telemetry Transformation ≠ Intelligence
Let’s call this out clearly.
If:
Input schema is known
Output schema is known
Transformation rules are fixed
Errors must be deterministic and traceable
Then this is:
A data engineering problem
Not an AI problem
Not an agentic problem
A simple pipeline—well-designed, versioned, and tested—will:
Be cheaper
Be faster
Be more reliable
Be easier to debug
AI adds uncertainty where certainty is required.
Architect’s Checklist: When Does AI Actually Make Sense?
Before adding AI to any solution, I ask these hard questions.
1️⃣ Is the problem deterministic?
If the same input should always produce the same output, AI is usually the wrong choice.
AI thrives on ambiguity—not precision.
2️⃣ Does the system need to learn or adapt over time?
If no learning is required, why introduce probabilistic behavior?
Static problems deserve static solutions.
3️⃣ Can you explain failures to an auditor or client?
“Model behaved unexpectedly” is not an acceptable root cause in production systems.
If explainability matters, think twice.
4️⃣ What is the operational cost?
AI isn’t just a design choice—it’s a long-term cost commitment:
Model updates
Drift handling
Monitoring
Infra scaling
Security & compliance
Classic pipelines age far more gracefully.
5️⃣ What happens when AI is unavailable?
If your system cannot function without an AI component, you’ve created fragility—not intelligence.
Where AI Actually Belongs?
To be clear—I’m not anti-AI, I am consuming it in many ways !
AI makes real sense when:
Inputs are unstructured (text, speech, images)
Rules cannot be exhaustively defined
Patterns evolve over time
Human-like judgment adds value
Optimization or prediction is the goal
Not when the problem is already solved cleanly with known tools.
Architecture Is About Restraint
Good architecture is less about what you can add and more about what you choose not to.
Every unnecessary AI component:
Increases cognitive load
Reduces predictability
Complicates operations
Weakens trust
Sometimes, the most senior architectural decision is saying:
“This does not need AI.”
Final Thought
AI will stay.
The hype will fade.
Good architecture will outlive both.
As architects, we owe it to our systems—and to future teams—to design with clarity, not trend-chasing.
I’d love to hear from fellow architects:
👉 Where have you removed AI and improved the system?
First published on LinkedIn.