The AI Engineering Reading List That Actually Makes Sense

Here's the problem with most AI engineering learning paths: they're either written by academics who haven't shipped code since 2015, or by bootcamps trying to sell you a dream in 12 weeks. Marina Wyss, a Senior Applied Scientist at Amazon who's coached nearly 200 people into AI and ML roles, has a different approach. Her recent reading list cuts through the usual nonsense, and the interesting part isn't what she includes—it's what she deliberately leaves out.

The core tension in Wyss's roadmap is definitional. AI engineering, as she frames it, isn't about training models from scratch. "Unlike data scientists or machine learning engineers who train models from scratch, AI engineers build applications using pre-trained models," she explains. They take foundation models like GPT, Claude, or Llama and turn them into products. Their toolkit as of 2026 is mostly prompt engineering, RAG, fine-tuning, and agents.

This distinction matters more than it seems. If you get it wrong, you'll spend months studying things you don't actually need. And that raises an uncomfortable question: how many people currently grinding through Stanford's CS229 lectures are learning skills that won't actually help them get or do the job they want?

The Math Question Nobody Wants to Answer

Wyss's most provocative claim is about mathematics. After six years working on production AI and ML systems at companies like Coursera and Amazon, she says she has "never once needed to calculate the chain rule by hand. Not once."

She recommends the Manga Guide series for statistics, linear algebra, and calculus. Actual manga. Comic books with storylines and characters explaining mathematical concepts.

This will infuriate some people. And it should—it's worth being infuriated about. Either the traditional gatekeeping around mathematical prerequisites is counterproductive credentialism, or we're about to flood the market with people who lack fundamental understanding. Both can't be true.

Wyss's position is clear: "What you actually need is enough stats to run a solid experiment and enough probability, calculus, and linear algebra to understand conceptually what the models are doing. You need intuition, not derivation skills."

But intuition about what, exactly? And at what point does conceptual understanding become hand-waving? These aren't rhetorical questions. The AI engineering role is new enough that we don't actually know yet where the floor is.

The Production Gap

The most useful part of Wyss's roadmap might be the second book: Software Engineering for Data Scientists. This addresses what she calls the jump from "code that works on your laptop and code that can actually be deployed, maintained, and trusted in production."

This gap is real and enormous. I've seen it swallow entire startups. You can have all the AI knowledge in the world, but if you can't ship reliable software, you're not going to succeed in this field. Project structure, testing, version control, logging, monitoring, Docker—these aren't sexy topics, but they're the difference between a demo and a product.

The emphasis here reveals something about what AI engineering actually is: it's closer to traditional software engineering than most people expect. The AI part is increasingly commoditized through APIs. The hard part is everything around it.

The Paradox of Building from Scratch

Wyss recommends Build a Large Language Model from Scratch, which seems to contradict her entire premise. If AI engineers don't train models, why build one?

Her logic: "You're not doing this because you'll build LLMs at work. You're doing this so that when you're building applications on top of these models, you actually understand what you're working with."

This is probably right, but it raises practical questions. How deep is deep enough? At what point does understanding the internals deliver diminishing returns? If you're building a RAG application, does it matter whether you understand the attention mechanism?

The answer depends on what kind of problems you'll face. If you're just chaining API calls, maybe not. If you're optimizing inference costs at scale, definitely. But most people starting out don't know which category they'll end up in.

What's Missing

Wyss's list is conspicuously light on one thing: the business side. There's nothing about product thinking, user research, or understanding what problems actually need solving. This is either because she assumes you'll learn that on the job, or because the role really is that technical-focused.

Both possibilities are interesting. The first suggests AI engineering is still junior enough that you won't be making product decisions early in your career. The second suggests we're building a generation of people who can implement solutions but not identify problems worth solving.

The capstone book, Generative AI System Design Interview, focuses on technical architecture and trade-offs. That's valuable. But the hardest system design questions I've encountered weren't about choosing the right vector database—they were about whether we should build the thing at all.

The Real Value

If you strip away the specific book recommendations, what Wyss is really offering is a perspective on what matters and what doesn't. Python matters. Production engineering matters. Conceptual understanding of ML matters. Being able to derive backpropagation by hand doesn't.

Whether she's right depends entirely on what AI engineering becomes. If it stays close to software engineering with specialized tooling, her roadmap makes sense. If it evolves to require deeper model understanding, she's leaving people underprepared.

The field is young enough that both futures are possible. Which means the real skill might be metacognition: knowing what you don't know, and being able to learn it when the job requires it. That's harder to teach from a reading list.

—Mike Sullivan