The AI Engineer Roadmap Nobody's Talking About

There's something quietly ambitious happening in tech education right now. While most courses promise to turn you into an AI engineer in 90 days with nothing but vibes and a ChatGPT subscription, ZazenCodes just dropped a two-hour roadmap that assumes you're serious enough to work through the boring parts.

The course—available on their platform with over five hours of total content—tackles what the creator calls the "four pillars" of AI engineering: programming, data engineering, machine learning, and mathematics. It's comprehensive to the point of being almost intimidating. And maybe that's the point.

The Role That Doesn't Quite Exist Yet

First, we should talk about what an "AI engineer" actually is, because the industry hasn't entirely figured that out. ZazenCodes breaks down three adjacent roles: AI engineers build product-focused applications that use AI. Data scientists analyze data and generate business insights. ML engineers build the models themselves.

The boundaries are fuzzy. An AI engineer might grab a pre-trained model an ML engineer built, fine-tune it, and integrate it into a customer-facing product. They're doing prompt engineering, building RAG systems, creating LLM evaluations. They're not necessarily training models from scratch—that's the ML engineer's domain—but they need to understand how those models work well enough to deploy them responsibly.

"Your product manager comes up and says, 'Hey, there's an issue with the product recommendation system. I'm seeing a spike in errors. Let me know what you think,'" ZazenCodes explains in a hypothetical day-in-the-life scenario. The AI engineer pulls error logs, replicates the issue locally, determines root cause, implements a fix. It's software engineering, but with AI-specific failure modes.

This matters because the skill stack is genuinely different from traditional software development. You need to understand linear algebra well enough to grok why a neural network is doing what it's doing. You need to know when cosine similarity is the right tool for comparing embeddings. You need to think about data pipelines and vector databases and model observability.

The Parts Nobody Wants to Learn

The course spends significant time on fundamentals that most people either already know or desperately want to skip. CPU cores and concurrency. The difference between 32-bit and 64-bit systems (introduced in 1985 and 1991, respectively—the creator acknowledges these dates might not be perfectly accurate but include them for "general vibe"). Bits versus bytes. The fact that a kilobyte is actually 1,024 bytes, not 1,000.

This is either admirably thorough or wildly over-specified depending on your perspective. If you're coming from a software engineering background, you probably know that Git was created by Linus Torvalds, who "names all his projects after himself—first Linux, now Git" (Git being British slang for an unpleasant person). If you're coming from a different background, maybe you don't, and maybe it matters.

The Python section advocates strongly for pathlib over the older os.path approach. "Use pathlib, get used to using this," the creator emphasizes. Type hints get similar treatment—they're presented not as nice-to-have but as essential for catching errors before runtime. The linting program "automatically knows about this. So as we're writing code it'll start flagging errors and warnings inside of the IDE before we even write anything."

Then there's the clean code section, which the creator admits is full of tradeoffs. Bad variable names (HPD, DW) versus good ones (hours_per_day, days_worked). Separation of concerns that makes code more readable but also introduces boilerplate. The eternal tension between clever one-liners and simple loops: "There's no need to take that and be like, 'Okay, let's bunch it down to some optimized Python representation.' Like this is just fine."

The Math You Actually Need

The mathematics section is where things get interesting, partly because the creator clearly loves this part. "I studied math in school for a few years and I really loved solving mathematics problems and I love the aesthetic of math and writing it and LaTeX and I wanted to put all of this into the course."

Vectors get introduced as "just lists of numbers" that could represent anything—height, weight, and age in a dataset; embeddings for the word "cat"; coordinates in 3D space. The dot product gets explained through cosine similarity, which measures the angle between two vectors and is commonly used to compare embeddings.

Then comes the neural network explanation, complete with hand-drawn counting of weights. "When you're doing this stuff in a neural network and we're drawing lines like this, each line which represents some sort of multiplication in this linear transformation, each line has its own weight. It's kind of trippy." The creator walks through a six-node layer feeding into a two-node layer, counting out all twelve weights, showing how the matrix transpose makes the dimensions align.

This is pedagogically interesting because it's neither purely theoretical nor purely applied. It's theory with enough concrete detail to build intuition. You're not just told that neural networks have weights—you're counting them.

What's Missing From the Conversation

The course touches on "Responsible AI" as a topic (timestamp 1:46:46) but the transcript cuts off before we get there. That's unfortunate because it's arguably the most important section. Who gets harmed when these systems fail? Who bears the cost of their mistakes? Those questions should be foundational, not tacked on at the end.

The career development section (starting at 1:55:31) might address some of this. The roadmap format implies a linear progression—learn Python, then math, then ML, then RAG and agents, then deployment—but the reality is messier. You learn by doing, which means you're probably deploying broken things and fixing them, not mastering each pillar sequentially.

The course also seems aimed at people who already have some technical foundation. If you've never written code before, starting with CPU architecture and bit-level operations might not be the move. But if you're a software engineer trying to transition into AI, or a data scientist who wants to ship production systems, this kind of comprehensive map has value.

The Terrain, Not the Journey

What ZazenCodes has built is essentially a very detailed map. It shows you the territory—here's what AI engineers need to know, here's how these concepts connect, here's where you might get stuck. But a map isn't the same as a path through that territory. How you actually learn this stuff—through projects, through failure, through shipping things that don't work and fixing them—that's a different question.

The course is structured around Jupyter notebooks for each section, with all code open-sourced on GitHub. That's smart. Learning to be an AI engineer means writing code, debugging it, and understanding why it broke. No amount of watching someone explain linear transformations can substitute for implementing one incorrectly and spending three hours figuring out why your dimensions don't align.

Still, there's something valuable about seeing the whole picture laid out. Most people learning AI are either drowning in math-heavy academic courses or floating through no-code tutorials that promise everything and teach nothing. This sits somewhere in between—technical enough to be useful, practical enough to be applicable.

The question isn't whether this roadmap is perfect. It's whether having any coherent roadmap helps you avoid spending six months learning things you don't need while missing things you do. On that measure, even an imperfect map beats wandering in the dark.

Marcus Chen-Ramirez is a senior technology correspondent for Buzzrag.