The AI/ML Engineer Roadmap Nobody Actually Finishes (But You Should Try)

Aditya Agrawal — Sat, 01 Aug 2026 15:09:24 +0000

Okay real talk — if you've googled "how to become an AI/ML engineer" you've drowned in roadmap images that are just... a wall of logos. TensorFlow logo, AWS logo, Docker logo, arrows everywhere, zero actual explanation of what to do with any of it.

So here's an actual phase-by-phase breakdown, with checkpoints, so you know when to move on instead of doom-scrolling more "10 skills you need" listicles.

Phase 1: Math (yes, actually)

Not a whole degree. Just:

Linear algebra (matrices = what NN layers actually compute)
Calculus (gradients = what backprop actually is)
Probability/stats (this is literally how you evaluate if your model is any good)

Checkpoint: Build linear regression from scratch in NumPy. No sklearn. Yes it's annoying. Do it anyway.

Phase 2: Data Wrangling

Pandas + SQL + feature engineering. This is 80% of the actual job and 5% of what tutorials cover. SQL specifically will show up in interviews and catch people off guard constantly.

Checkpoint: Full EDA project on a real (messy) dataset, pushed to GitHub with a real README.

Phase 3: Classical ML

Regression → trees → random forest → gradient boosting (XGBoost, everyone uses this) → SVM → clustering.

Metrics matter more than the algorithm honestly. Accuracy is basically a trap metric for imbalanced data and a shocking number of people don't know that.

Checkpoint: 2-3 full projects w/ a writeup of why you picked the metrics you did.

Phase 4: Deep Learning + LLMs

Neural net basics → pick PyTorch or TF (I'd say PyTorch) → CNNs for vision → Transformers for basically everything text-related now, including the RAG/LLM stuff that's all anyone's hiring for currently.

Checkpoint: Fine-tune a pretrained model, wrap it in a FastAPI endpoint.

Phase 5: Cloud (the part everyone skips)

Pick ONE:

AWS → SageMaker/Bedrock → most jobs
GCP → Vertex AI → best ML tooling honestly
Azure → Azure ML → enterprise-heavy companies

Learn IAM, storage, Docker, basic Kubernetes, managed training, model registries, endpoints. These concepts transfer no matter which cloud you pick.

Checkpoint: Deploy a model you already built. Full loop: train → register → serve.

Phase 6: MLOps

This is the "actual engineer" phase. Experiment tracking (MLflow), pipelines (Airflow), CI/CD (GitHub Actions), monitoring for drift.

Checkpoint: One full pipeline start to finish, automated, monitored.

Phase 7: Specialize

GenAI/LLMs (hottest rn, not close)
Computer Vision
MLOps/Platform Engineering
Data Engineering + ML

TL;DR

Stop building 20 tutorial projects that all look the same. Build 3-5 real ones and take them all the way to actually deployed + monitored + documented. That's the difference between a portfolio that gets ignored and one that gets you an interview.

Drop a comment — what phase are you stuck on?

I Stopped Treating AI as a Black Box and Started Building a Semantic Caching System from Scratch

Aditya Agrawal — Wed, 29 Jul 2026 20:01:43 +0000

Most AI projects today look something like this:

response = llm.invoke(prompt)

It works.

It's powerful.

But one question kept bothering me:

Do I actually understand what's happening behind the scenes?

That's what led me to start building a Semantic Caching System from scratch.

Not by copying an existing GitHub repository.

Not by wrapping an LLM in another API.

But by implementing every component myself and understanding why it exists.

Why Semantic Caching?

Imagine you're building an AI chatbot.

A user asks:

"What is Semantic Caching?"

A few seconds later another user asks:

"Can you explain semantic caching?"

The wording is different.

But the intent is almost identical.

Traditional caching won't help because the strings aren't exactly the same.

Semantic caching solves this problem by understanding that two different sentences can have the same meaning.

Instead of recomputing the answer every time, we can reuse a previous response when two queries are semantically similar.

That means:

Faster responses
Lower compute costs
Better scalability
Reduced load on AI models

My Goal

Instead of building another AI application, I wanted to understand how one of its important building blocks actually works.

So I decided to build everything myself.

My learning rule is simple:

If I can't explain why a class exists, I shouldn't use it.

What I've Built So Far

The project is divided into independent modules instead of one large codebase.

Current components include:

Query preprocessing
Text normalization
Tokenization
Embedding generation
Cosine similarity engine
Semantic cache manager
Cache hit and miss detection
Cache eviction strategies
Logging
Performance metrics
FastAPI endpoints

Each module has a single responsibility, making the architecture easier to understand and extend.

The Development Process

Rather than writing thousands of lines of code at once, I'm building one class at a time.

For every class, I follow the same workflow:

Understand the problem it solves
Design the class
Implement it
Explain every line of code
Test it
Improve it
Move to the next component

This approach is slower than following a tutorial, but I've learned far more from it.

What I'm Learning

Working on this project has already helped me understand concepts that are often hidden behind libraries:

Semantic Search

How can two different sentences be recognized as having similar meanings?

Embeddings

How can text be represented as mathematical vectors?

Cosine Similarity

How do we measure the similarity between two vectors?

Cache Management

How do we decide whether to reuse an existing response or compute a new one?

Cache Eviction

When memory becomes full, which cached items should be removed first?

Why I'm Avoiding the "Magic"

Modern AI libraries are incredible.

But they also make it very easy to skip understanding the fundamentals.

I wanted to know:

How embeddings work
Why cosine similarity works
Why semantic search works
Why caching improves performance
How these components communicate inside a real system

Building everything myself has answered many of those questions.

What's Next?

This project is still evolving.

The next steps include exploring how to make the architecture more production-oriented by integrating technologies such as:

Redis
Vector databases
Distributed caching
Kubernetes
Monitoring and metrics
Horizontal scaling

The idea isn't to build the biggest project.

It's to build one that teaches me something new every day.

Final Thoughts

One thing I've realized is that it's easy to build software that works.

It's much harder—and far more rewarding—to build software that you truly understand.

This project has reminded me that the best way to learn isn't by collecting frameworks.

It's by asking:

"Could I build this myself?"

That's the question I'm trying to answer, one class at a time.

If you're working on Backend Engineering, AI Infrastructure, or Distributed Systems, I'd love to hear how you approach learning complex systems from first principles.

DEV Community: Aditya Agrawal