Developer Tooling

Building LLM Applications for Production: Notes on Chip Huyen’s Book

· book · finished
The model is the easy part. The hard work of production LLM systems is the control flow that surrounds it: evals, retries, fallbacks, output validation, and graceful degradation. Chip Huyen’s 2023 essay names this gap clearly, and it traces through every production LLM system I have shipped, including the multi-agent pipeline that replaced 9,000 manual steps per scheduling cycle.

Where to read it

Chip Huyen’s piece reframed how I think about LLM engineering: the bottleneck is rarely the model, it is the operational scaffolding that decides what happens when the model gets it wrong.

I read this essay twice before I started building anything serious with LLMs. The first time I read it as a tutorial. The second time, after shipping a multi-agent pipeline that failed in three different ways in production, I read it as a warning.

What does Chip Huyen actually argue?

The hardest part of production LLM work is not the model, it is control flow: retries, fallbacks, output validation, and graceful degradation.

Huyen’s central claim is that the gap between a working demo and a working production system is wider than most teams realize, and that the gap is almost never closed by switching to a better model. It is closed by building the evals, the prompt versioning, the output validators, and the fallback paths that catch the failures you cannot prevent.

Four takeaways shaped how I work now:

  1. Evals come before features. If you cannot measure quality, you cannot improve it. I now write the eval before I write the prompt.
  2. Prompt ambiguity is a design problem. Most prompt failures are not the model misunderstanding. They are the prompt asking for two things at once.
  3. Control flow is the product. Retries, validators, and fallbacks define the system more than the prompt does.
  4. Few-shot examples are documentation. Treat them like API contracts that get versioned and tested.

What does this mean for builders today?

Production LLM engineering is a distinct discipline from both traditional software engineering and ML research, and it deserves its own playbook.

The essay predates most current frameworks (LangChain matured after, agent libraries came after that, multi-agent orchestration is still settling), but the diagnoses hold. I write about why this matters in my piece on why agent reliability beats agent intelligence, and trace the same control-flow problem through my case study on multi-agent systems in production. Both pieces start where Huyen’s essay ends.

Is this essay (and the book it grew into) worth your time?

Yes, especially if you are about to ship an LLM feature and have not yet written an eval.

The original 2023 essay is free and reads in 20 minutes. The expanded book version, AI Engineering (O’Reilly, 2025), goes deeper on data, retrieval, and post-training. If you are deciding which to start with, read the essay first. If it resonates, the book earns the next four hours.

You cannot prompt-engineer your way out of a system without evals. The discipline of production LLM work is the discipline of measuring what the model does when no one is watching.

What should you read alongside this?

Pair Huyen’s essay with the collective lessons from the Applied LLMs group and the a16z stack diagram, and you have the foundation for thinking about production LLM systems.

What We’ve Learned from a Year of Building with LLMs distills tactical, operational, and strategic lessons from practitioners shipping real systems. It reads as the operating manual to Huyen’s diagnosis.

Emerging Architectures for LLM Applications maps the canonical LLM stack: data, embeddings, vector store, orchestration, model, validation. It established vocabulary the industry still uses two years later.

I write about how these patterns shape my own work in on architecture as a design discipline.