A few years ago, building with AI usually meant one thing: send some data to a model, get a prediction back, and wrap a product around it.
That world already feels old.
Today I can give an AI system a goal, connect it to tools, let it read documents, write code, search databases, call APIs, inspect its own output, and continue working without me touching every step.
And yet, after building and watching these systems evolve, I keep coming back to the same thought:
We are moving incredibly fast, but the hardest problems are only becoming more visible.
The next chapter of AI will not be decided only by who has the biggest model. It will be decided by who can make AI reliable enough to become real infrastructure.
Stage 1: From Chatbots to Systems
We are already leaving the chatbot era.
The first generation of AI products mostly looked like this:
User → Prompt → Model → Response.
The next generation looks very different.
User → Goal → Agent → Tools → Memory → APIs → Other Agents → Verification → Result.
That difference is much bigger than it looks.
Once an AI can act instead of simply answer, software architecture changes.
An AI coding assistant may inspect a repository, create a branch, modify several files, run tests, discover an error, correct it, and open a pull request.
A financial agent may analyze transactions, compare risk rules, generate a report, ask another model to validate it, and send the result into an existing workflow.
This is where AI becomes genuinely powerful.
It is also where things start breaking.
Problem #1: Reliability
Hallucination is often discussed like it is simply a model problem.
I think it is becoming a system-design problem.
If an AI occasionally writes the wrong sentence in a chat, the damage is limited.
If an autonomous agent makes the wrong database update, executes the wrong API call, changes production code, or interprets financial information incorrectly, the consequences are very different.
Developers therefore need systems that can answer questions like:
Did the model use the correct source?
Did the action actually succeed?
Was the result verified?
Can the operation be reversed?
Should a human approve this step?
The winning AI applications will probably contain much more traditional engineering than people expect: validation layers, deterministic rules, audit logs, permissions, tests, retries, fallbacks, and rollback mechanisms.
The model may be intelligent.
The system around it still needs discipline.
Problem #2: Memory
Current AI often feels brilliant for twenty minutes and forgetful twenty minutes later.
Long-term memory changes that.
Imagine an engineering agent that understands not only your repository but why certain architecture decisions were made six months ago.
Or a business agent that remembers previous negotiations, company preferences, rejected ideas, customer feedback, and operational patterns.
But memory creates its own engineering challenge.
What should be remembered?
What should expire?
What happens when old information becomes incorrect?
How do we prevent private data from leaking into another workflow?
Simply putting everything into a vector database is not a complete answer.
We will need better memory architectures combining short-term context, structured facts, semantic retrieval, permissions, confidence levels, and time-aware information.
Problem #3: Evaluation
This might become one of the most important areas in AI engineering.
Traditional software gives us a comfortable idea:
Input A should produce Output B.
AI is probabilistic.
Two runs can produce different answers, and both may look reasonable.
That makes testing much harder.
Soon, teams will need AI evaluation systems alongside their CI/CD pipelines.
Before deploying an agent, they may run hundreds or thousands of scenarios:
Does it complete the task?
Does it use the right tools?
How many steps does it take?
How expensive is it?
Does it expose sensitive information?
Can another model verify the result?
Where does it fail?
The future AI engineer will probably spend far more time thinking about evaluation than prompt engineering.
Problem #4: Cost and Latency
There is another reality behind every impressive AI demonstration: somebody has to pay for the tokens and wait for the result.
A complex agent might call a model 20 times to complete one task.
Add retrieval, reasoning, browser operations, embeddings, image processing, and verification, and the cost grows quickly.
I expect AI architectures to become increasingly hybrid.
Small models will handle classification and repetitive decisions.
Larger models will be called only when deeper reasoning is necessary.
Some models will run locally.
Some will run in the cloud.
Systems will cache previous work and reuse computed context instead of repeatedly asking the model to rediscover the same information.
Good AI architecture will increasingly be about deciding when not to call the most powerful model.
Problem #5: Security
Agents create an entirely new attack surface.
Prompt injection is only the beginning.
If an agent can read email, access GitHub, query databases, browse websites, and execute tools, then every external input potentially influences a system with real permissions.
We will need AI-specific security boundaries.
An agent should not receive unlimited access simply because it may need a tool later.
Permissions should be temporary, contextual, limited, and auditable.
The principle will look familiar to security engineers:
Give the system exactly what it needs, exactly when it needs it, and nothing more.
The Roadmap I Expect
Over the next phase of AI development, I expect progress to happen roughly like this:
Models become better at reasoning and multimodal understanding.
Then:
Agents become better at completing longer tasks.
Then:
Multiple specialized agents begin collaborating inside workflows.
After that, the difficult infrastructure work becomes unavoidable:
memory, evaluation, identity, permissions, observability, verification, cost optimization, and interoperability.
Eventually, we may stop thinking about AI as a feature.
It will become another software layer.
Just as applications today assume databases, cloud infrastructure, authentication, APIs, and networking exist underneath them, tomorrow's applications may assume intelligence exists underneath them too.
What I Would Learn Now
If I were preparing for that future today, I would not spend all my time learning how to write better prompts.
I would study distributed systems.
APIs.
Databases.
Retrieval systems.
Model evaluation.
Security.
Observability.
Agent architecture.
Human-in-the-loop workflows.
And most importantly, I would learn how to connect probabilistic AI with deterministic software.
Because that intersection is where many of the hardest problems are appearing.
AI is developing extremely fast.
But faster models do not automatically create better products.
The real opportunity belongs to developers who can take increasingly capable intelligence and turn it into systems people can actually trust.
That is the roadmap I am watching.
And I think we are still much closer to the beginning than the end.
Top comments (2)
The abstraction level with this kind of stuff seems WAY higher than with the (non-AI) stuff that we're familiar with - thinking about the people who are currently working in the software development field, I can't imagine that this will be everyone's cup of tea ...
P.S. your take on AI being a part of "infrastructure", comparable to databases, web servers, etc, seems spot on - I think building/optimizing agent harnesses and AI tooling might be (or become) a specialized field - some devs build these tools, others ("application developers") only use them ...
I'll be retired soon, fortunately.