AI Engineering Books: What to Read Before You Ship

An AI reading list should help you decide what to build differently. If it only leaves you with more model names, it has missed the job. For an application engineer, I would start with evaluation and reliability, then go deeper into model internals when the question calls for it.

This list is aimed at engineers building on foundation models they did not train. It includes three AI-focused books, two systems books and a separate note about my own book.

Choose the book by the system responsibility you need to understand. Calling a model API, maintaining a retrieval pipeline and implementing attention are different tasks. One reading order will not serve all three, even though each may be described as AI engineering.

I build Codelit, so my bias is toward the parts that make a product dependable after the first impressive response.

Start with AI Engineering when you need a broad method for building on foundation models. Its evaluation material gives the rest of the work a reference point: what good means, how to compare options and which failures matter to the application.

The O'Reilly contents place evaluation methodology and AI-system evaluation before prompt engineering. That ordering is useful. It asks you to establish the test before spending weeks tuning the answer.

For a prompt-to-diagram pipeline, valid JSON is one acceptance condition. It does not establish that the architecture is correct, useful or complete. The evaluation set needs to exercise those separate questions.

Read selectively. If you do not train or finetune a model, those chapters can wait. If your retrieval data is unreliable, dataset work may be more urgent than another prompt revision.

Designing Machine Learning Systems is useful for thinking about data quality, monitoring and change after deployment. The book predates many current LLM application patterns, so the value is the operational reasoning rather than a recipe that matches your provider's API.

The publisher's contents cover data engineering, distribution shifts and monitoring. I would read those sections with a concrete question: what can change underneath this feature while the application code stays the same?

An input population changing is one kind of shift. A provider replacing the model is another source of behavior change; calling both “drift” without separating them makes diagnosis harder.

In multi-provider routing, a healthy HTTP response still needs the same evaluation bar as the primary model. Availability fallback is not automatically quality fallback.

Build a language model from scratch when understanding model internals is the learning goal or the missing context behind your engineering decisions. It is not required before shipping an API-based feature. The opportunity cost depends on the problem you are trying to solve this month.

Sebastian Raschka's Manning book, published in September 2024, works through model implementation, including attention and training. It is a substantial practical study, not a shortcut to production application reliability.

The useful distinction is between understanding the dependency and owning it. An application engineer benefits from the first without having to reproduce the second.

Ordinary systems books belong on the shelf because AI applications still have state, timeouts and dependencies that fail independently. Adding a model makes some behavior probabilistic; it does not remove the existing need for recovery, isolation and careful handling of external effects.

Release It! is the book I would reach for before adding retry layers. Retrying a slow dependency can multiply load and cost. A fallback that waits too long can make a product less responsive while appearing more reliable on paper.

Designing Data-Intensive Applications helps when a run must survive beyond one request. What is durable? Which state can be rebuilt? Which external effect is ambiguous after a crash?

An idempotency key only helps within the receiving system's contract. A local run log cannot guarantee exactly-once behavior from a third-party action that offers no such support.

Your product still needs its own acceptance criteria, cost accounting and response to failure. Books can explain the categories and trade-offs, but they cannot supply the test cases or operating thresholds for a workflow they have never seen.

For costs, start with a workload-based estimate, then replace assumptions with actual usage. Do not copy an old per-token price from a chapter and treat it as a budget.

Streaming a structured response adds another distinction: visible progress is not completed output. Measure and communicate both.

From Prompt to Proof is about using AI to complete work, not building or serving models. It belongs beside the practice of sourcing, setting boundaries and checking results. I wrote it and earn an author royalty, so it is not an independent recommendation alongside the other titles.

The practical questions are different from Huyen's: did the model inspect the real source, does it know what “done” means, is it allowed to send or publish, and what evidence would make the result trustworthy?

If you are designing a retrieval pipeline, start with the systems books above. If your sessions repeatedly end with a confident draft instead of a verified outcome, my book addresses that workflow.

Make the reading pay off by turning one idea into a test, design decision or operating rule for a real feature. A useful chapter should leave something behind in the repository or workflow. Recognition alone is not the outcome.

My first assignment would be small: choose ten representative tasks, include a few expected failures, define what passes and run the feature against them. Then read the evaluation chapter again with those results in front of you.

The rest of the recommendations are on my bookshelf. Start with the gap in the product, not the size of the reading list.