How I Learned AI Engineering
I still remember when I first started getting serious about AI.
At that time, AI was everywhere. Every second person was talking about ChatGPT, LLMs, RAG, agents and the next big AI framework.
I was already working as a software engineer, so I initially thought this would be easy for me. I knew how to build APIs, work with databases, write backend services and think about scalable systems. I thought I just needed to learn how to call an LLM.
I was wrong.
The first few days were actually exciting. I started with Python because most of the AI ecosystem was built around it. I already knew programming, so Python itself wasn’t the difficult part.
But then I started seeing things like embeddings, transformers, vector databases, RAG, LangChain, LangGraph, agents, memory, tool calling and MCP. Every time I understood one thing, I discovered three more things.
That was probably the first problem I faced.
I wasn’t struggling because AI was impossible to learn. I was struggling because I didn’t know what I should learn first.
So instead of randomly jumping between YouTube videos, blogs and new AI frameworks, I decided to step back and look at AI Engineering from an engineer’s perspective.
I asked myself a simple question:
If I had to build a real AI product from scratch, what would I actually need to know?
That question changed everything.
I Started With Things I Already Knew
I didn’t start my AI journey by trying to understand every mathematical detail behind neural networks. I started from the engineering side.
I went back to Python, because I wanted to become comfortable building AI applications with it. Then I made sure I was comfortable with things that are easy to ignore when you’re excited about AI: Git, APIs, HTTP, JSON, databases, SQL, asynchronous programming, Docker and basic cloud concepts.
At first, these topics didn’t feel like AI.
I remember thinking, “Why am I learning Git and Docker again? I came here to learn AI.”
But later I understood why.
Suppose you build an AI application that works perfectly on your laptop. Now imagine someone else needs to run it. Your application needs an API. It needs configuration. It needs a database. It needs deployment. It needs logging. It needs error handling. It needs version control.
The LLM is only one part of the application.
That realization became very important for me.
I stopped thinking about AI as a separate world and started looking at it as another type of software system.
Then I Went Back to Machine Learning
After getting comfortable with the engineering foundations, I started going deeper into Machine Learning.
I didn’t want to become a research scientist. My goal was to understand what was happening underneath the tools I was using.
I learned about data, features, training, validation, models, overfitting and evaluation. Then I moved towards Deep Learning and started understanding neural networks and how models learn patterns from data.
This was interesting because I had spent years writing software where I explicitly told the computer what to do.
With traditional programming, I could write:
“If this happens, do this.”
Machine Learning felt different.
Instead of manually writing every rule, I was giving the system data and allowing a model to learn patterns.
That difference was important to understand before jumping into modern LLM applications.
Then I Found Transformers
The next big step for me was understanding Transformers.
Before that, LLMs felt almost magical.
You type a question.
The model understands it.
It generates an answer.
But when I started learning about tokens, embeddings, attention and transformers, the magic started becoming engineering.
I still didn’t understand every mathematical detail, and I didn’t need to.
What I wanted was a mental model.
I wanted to understand what happens between:
Text → Model → Output
That foundation made it much easier for me to understand modern LLMs.
Then I Started Building With LLMs
Once I understood the basics, I started using LLM APIs.
This part was fun.
You could write a small amount of code and suddenly have an application that could summarize text, answer questions, extract structured information or generate content.
But after building a few simple applications, I hit another problem.
The model didn’t know my data.
I could ask it general questions, but what if I wanted it to answer questions about my own documents?
What if those documents were private?
What if the information changed every week?
What if I had thousands of documents?
Putting everything inside the prompt obviously wasn’t going to work.
That was when I discovered RAG.
RAG Was a Big Turning Point
RAG completely changed how I thought about AI applications.
Instead of:
Question → LLM → Answer
the system could become:
Question → Retrieve relevant information → LLM → Answer
That sounds simple when you write it like that.
But when I actually started building one, I realized how many engineering decisions were hiding underneath.
How should I split a document?
How large should a chunk be?
Should I keep metadata?
How should I create embeddings?
Where should I store them?
How many documents should I retrieve?
What if the retrieved documents are wrong?
What if the answer isn’t present in the knowledge base?
What if the document changes?
Suddenly my simple RAG application wasn’t so simple anymore.
And honestly, this is where I started learning much faster.
Because I wasn’t learning RAG from a definition anymore.
I was learning it because my own application was giving me bad answers.
I Started Understanding Embeddings and Vector Databases
To make RAG work properly, I needed to understand embeddings.
At first, the idea felt strange.
How can a piece of text become numbers?
And how can those numbers help me find similar information?
I started experimenting with embeddings and vector databases.
Then I understood the basic idea: instead of searching only for exact words, we could represent information in a form that allowed us to find semantically similar content.
That opened another area of learning.
Vector search.
Similarity.
Metadata filtering.
Indexing.
Retrieval.
Hybrid search.
And once again, I realized that the AI application was not just an LLM call.
There was an entire retrieval system around it.
Then I Started Building AI APIs
At this point I wanted to move beyond notebooks and small experiments.
I wanted to build proper AI backend services.
That’s where FastAPI became useful.
I started thinking about an AI application like any other backend system.
There is an API.
There is validation.
There are services.
There is a database.
There are external dependencies.
There are failures.
There are timeouts.
There are retries.
There are logs.
There are users.
The difference is that somewhere inside the system, there is an LLM making probabilistic decisions.
That difference creates a completely new set of engineering challenges.
For example, in a normal API, I can usually predict what a function will return.
With an LLM, the output can change.
It can be correct.
It can be incomplete.
It can misunderstand the request.
It can hallucinate.
It can return something in the wrong format.
So I started thinking about validation and reliability much more seriously.
Then Agents Started Getting Interesting
After building RAG systems, I started asking another question.
What if the AI could actually do something instead of just answering?
What if I gave it a calculator?
What if I gave it a database?
What if it could call an API?
What if it could search something?
What if it could decide which tool to use?
That led me into AI Agents and tool calling.
The first time I built a simple tool-calling workflow, it felt very different from a chatbot.
The model wasn’t just generating text.
It was deciding what action should happen next.
But again, the moment I started building more complicated workflows, things became messy.
What happens when the tool fails?
What happens when the model calls the wrong tool?
What happens when the agent keeps repeating the same action?
Where do we store state?
How do we retry?
When should a human take over?
Those questions pushed me deeper into agent engineering.
LangGraph Changed My Mental Model
When I started learning LangGraph, something clicked.
Instead of thinking about an agent as some magical autonomous AI, I could think about it as a workflow.
There is state.
There are nodes.
There are decisions.
There are edges.
There can be loops.
There can be retries.
There can be human intervention.
That was much easier for me to reason about as a software engineer.
I started building workflows where one step would retrieve information, another would call a tool, another would validate the result and another would decide what should happen next.
The more I built, the more I realized that a good AI agent is not about giving the model unlimited freedom.
It’s about designing the right boundaries around it.
Then I Started Thinking About Memory
One problem became obvious after building conversational systems.
The AI forgets.
You can have a long conversation with a system, start a new session and suddenly it knows nothing.
That made me curious about AI memory.
What should an AI remember?
Should it remember everything?
Probably not.
Should it remember user preferences?
Maybe.
Should it remember previous tasks?
Sometimes.
Should memories expire?
Probably.
Where should memories be stored?
How should they be retrieved?
These questions made me realize that memory is not just “store the chat history.”
It is another engineering problem.
Then Came MCP
As I continued exploring AI agents and tools, I came across MCP.
What interested me wasn’t just the protocol itself.
It was the idea behind it.
AI systems need to interact with external tools and data.
Instead of every AI application creating completely different integrations, there could be a standardized way for models and applications to discover and use capabilities.
That made me think about AI applications differently again.
The future AI application isn’t just a chatbot sitting inside a box.
It can interact with databases, APIs, files, developer tools and other systems.
The model becomes one part of a much larger ecosystem.
Then Reality Hit: AI Can Be Wrong
This was probably one of the most important lessons I learned.
A demo can look amazing.
A production system is different.
You can build a RAG system that works perfectly on five documents.
Then you put 50,000 documents into it and everything changes.
You can build an agent that works perfectly ten times.
Then it gets a slightly different request and enters a loop.
You can write the perfect prompt.
Then the model gives you an unexpected answer.
That forced me to learn about AI evaluation.
Get Himanshu Singour’s stories in your inbox
Join Medium for free to get updates from this writer.
I started thinking about questions like:
How do I know my retrieval is good?
How do I know the answer is correct?
How do I detect hallucinations?
How do I compare two versions of a prompt?
How do I know whether a new model is actually better?
Traditional unit tests aren’t enough for every AI problem.
AI systems need their own evaluation strategy.
That was another major shift in my thinking.
Then I Started Thinking About Production
Once you build enough AI applications, you eventually stop asking:
“Can I make this work?”
and start asking:
“Can I make this reliable?”
That’s a completely different question.
Now you start thinking about latency.
Token costs.
Caching.
Retries.
Timeouts.
Rate limits.
Streaming.
Logging.
Monitoring.
Tracing.
Security.
Authentication.
Deployment.
Scaling.
Model selection.
Fallbacks.
This is where my software engineering background became extremely useful.
Because AI may be new, but production engineering problems are not.
An AI application still needs good architecture.
It still needs good APIs.
It still needs proper databases.
It still needs observability.
It still needs security.
It still needs testing.
It still needs people who understand what happens when something goes wrong at 2 AM.
I Also Made Plenty of Mistakes
One thing I don’t want to hide is that I wasted a lot of time.
I jumped between frameworks.
I watched tutorials without building anything.
I sometimes learned a tool before understanding the problem it was solving.
I built small demos that looked impressive for five minutes but taught me very little.
There were also times when I thought I understood something because I could explain the definition.
Then I tried building it.
And got stuck.
That was a good lesson.
There is a huge difference between knowing:
“A vector database stores embeddings.”
and actually debugging why your retrieval system is returning irrelevant documents.
There is a difference between knowing:
“Agents can call tools.”
and debugging an agent that keeps calling the same tool again and again.
There is a difference between knowing:
“RAG reduces hallucinations.”
and actually discovering that bad retrieval can make the final answer even worse.
Building exposes those gaps very quickly.
Eventually I Stopped Learning AI as Separate Topics
This was probably the biggest change in my learning.
Earlier, I saw everything separately.
Python was one thing.
Machine Learning was another.
LLMs were another.
RAG was another.
Agents were another.
Vector databases were another.
FastAPI was another.
MCP was another.
Now I see them as pieces of one system.
A user sends a request.
The API receives it.
The application decides what needs to happen.
Maybe it retrieves information.
Maybe it calls a tool.
Maybe it uses memory.
Maybe an agent workflow is required.
The model generates a response.
The response gets validated.
The system records what happened.
Then we evaluate whether the system actually did a good job.
Suddenly all those individual topics started making sense together.
What Actually Helped Me Learn
If I had to choose one thing that helped me the most, it wouldn’t be a course or a particular framework.
It would be building things.
Whenever I learned something, I tried to build something small around it.
Learned RAG?
Build one.
Learned tool calling?
Build one.
Learned agents?
Build one.
Learned memory?
Build one.
Learned MCP?
Build one.
Learned evaluation?
Add evaluation to an existing project.
The project didn’t need to be huge.
Sometimes a small working project taught me more than spending an entire weekend watching tutorials.
The pattern became very simple:
Learn → Build → Break → Debug → Understand → Build again.
That’s how the knowledge started sticking.
I Also Started Explaining What I Learned
Another thing that helped me was writing about these concepts.
When you explain something to another engineer, you quickly discover what you don’t understand.
You think you understand RAG.
Then someone asks:
“Why this chunk size?”
And you realize you never really thought about it.
You think you understand agents.
Then someone asks:
“What happens when the tool fails?”
And suddenly you have another rabbit hole to explore.
Writing and teaching forced me to go one level deeper.
That’s also one of the reasons I started organizing these topics on AlgorithmXlr8.
I didn’t want AI Engineering to feel like a collection of random technologies.
I wanted to create a path where someone could start from the fundamentals and gradually reach real AI systems.
My Biggest Lesson
Looking back, I don’t think I learned AI Engineering by following one perfect roadmap.
I learned it by repeatedly getting stuck.
I learned Python because I needed it to build something.
I learned RAG because my LLM didn’t know my data.
I learned vector databases because I needed better retrieval.
I learned agents because I wanted the AI to take actions.
I learned LangGraph because agent workflows became difficult to manage.
I learned memory because conversations needed context.
I learned MCP because AI systems needed better access to tools.
I learned evaluation because “it seems to work” wasn’t good enough.
And I learned production engineering because eventually every demo needs to survive outside your laptop.
That’s what made AI Engineering interesting to me.
It isn’t just about AI.
It is about bringing everything together.
Software Engineering.
Data.
Machine Learning.
LLMs.
Backend Engineering.
Systems.
Infrastructure.
And a lot of experimentation.
If I Were Starting Again
If I were starting AI Engineering from zero today, I wouldn’t try to learn everything at once.
I’d first get comfortable with Python, Git, APIs, databases and basic software engineering.
Then I’d learn the foundations of Machine Learning and Deep Learning.
Then I’d understand LLMs and Transformers.
Then I’d build a RAG system.
Then I’d learn embeddings, vector databases and retrieval properly.
Then I’d build AI APIs with FastAPI.
Then I’d move into tool calling and AI Agents.
After that I’d learn LangGraph, state and workflows.
Then memory and MCP.
Then I’d spend serious time on evaluation, guardrails, reliability and production AI.
But I wouldn’t spend months learning each topic before building.
I’d learn enough.
Then build.
Then let the problems tell me what I need to learn next.
The Journey Isn’t Finished
Even after learning all of this, I don’t consider myself “done” with AI Engineering.
That’s probably the biggest difference between learning a technology and becoming an engineer.
There is always another problem.
A better retrieval strategy.
A better model.
A cheaper inference setup.
A more reliable agent.
A better evaluation method.
A new protocol.
A new architecture.
A new production problem.
And that’s okay.
I don’t think the goal is to finish AI Engineering.
The goal is to become good enough at engineering that when a new AI technology appears, you can understand where it fits, why it exists and when you should actually use it.
That’s the mindset I’m trying to build.
Don’t chase every new model.
Don’t learn every framework just because it’s trending.
Don’t build another chatbot just to say you built an AI project.
Understand the fundamentals.
Build real things.
Break them.
Debug them.
Measure them.
And keep going.
That’s how I learned AI Engineering.
And honestly, I’m still learning.
Want to Start Your AI Engineering Journey?
If you want to start learning AI Engineering and follow the same kind of path I followed, I’ve put the complete learning journey on my platform, AlgorithmXlr8.io
I’ve tried to structure it around the same question I had when I started: what should I learn first, what should I learn next, and how do all these pieces actually connect?
You can start with the fundamentals and gradually move towards Machine Learning, LLMs, RAG, AI Agents, workflows, memory, MCP and the other concepts required to build real AI systems.
If you’re also trying to figure out where to start with AI Engineering, you can start here:
I’ve learned these concepts by building, breaking, debugging and going back to the fundamentals. I’ve tried to put that same approach into the platform so you don’t have to spend months jumping randomly between different resources.
If you’re starting your AI Engineering journey, you can start here too.
