Chapter 1 Why Prompts Fail in Production
The Problem
A team ships a customer-support assistant. It works beautifully in the demo. Three weeks later, support tickets climb. The assistant has started confidently giving refund amounts that do not match policy. Nobody changed the prompt. Nobody changed the code. The model provider quietly updated the underlying model, and a prompt that depended on an undocumented behaviour drifted. The team finds out from angry customers, not from their own systems.
This chapter is about why that story is the rule rather than the exception, and why the instincts that serve you well in ordinary software engineering can quietly betray you when a large language model sits in the middle of your system.
1.1 The prototype-to-production cliff
There is a moment, familiar to anyone who has built with LLMs, when a prompt first works. You type an instruction, the model responds correctly, and it feels like you are finished. You are not finished. You are at the top of a cliff, and the distance to a dependable production system is much larger than it looks from up there.
The reason is that a prototype only has to work once, for you, on the inputs you happened to try. A production system has to work thousands of times a day, for users you have never met, on inputs you never imagined, under cost and latency constraints, while remaining auditable and secure. The prompt is the same. The surrounding obligations are entirely different.
Traditional software has a comforting property: given the same input, it produces the same output. A function that returns the wrong answer returns the same wrong answer every time, which makes the bug findable. LLM-based systems do not offer this. The same prompt with the same input can produce different outputs on different calls, and the same prompt can produce different outputs next month because the model behind the API has changed. The ground moves under you.
1.2 Four ways prompts fail that ordinary code does not
It helps to name the failure modes precisely, because each one needs a different defence — and the rest of this book is organised around those defences.
Non-determinism. The same input does not reliably produce the same output.
This breaks the most basic assumption behind unit testing. You cannot assert that
output == expected when output is a moving target. Chapter 5
replaces equality assertions with evaluation: scoring outputs against criteria
rather than matching them against a fixed string.
Silent regression. A change that looks like an improvement degrades behaviour on inputs you did not check. Because there is no compiler error and no failing test — you have no tests — the regression ships. You learn about it from users. Chapter 6 builds the frozen golden datasets and CI gates that catch this before release.
Drift. Nothing in your code changed, but behaviour changed anyway, because the model, the data distribution of your users, or the world moved. Chapter 9 is about seeing drift in production rather than being told about it.
Invisible coupling. Your prompt depends on a model behaviour you never documented and possibly never noticed — a particular way it formats lists, a tendency to comply with a certain phrasing. When that behaviour shifts, your system breaks in a way that is hard to trace back to its cause. Chapter 3 is about making prompts explicit and robust enough that they do not lean on undocumented quirks.
1.3 Why “just tweak the prompt” is a trap
When something goes wrong, the natural reaction is to edit the prompt until the bad behaviour stops. This works, locally, for the case in front of you. The trouble is that you have no way of knowing what else you changed. A prompt is a single dense object; adjusting one instruction can shift behaviour across every input the prompt handles. Without a way to measure the effect of a change across a representative set of inputs, every fix is a gamble, and you are as likely to introduce two new problems as to solve the one you started with.
This is the central argument of the book: prompts are not text you tweak, they are artifacts you engineer. They deserve the same disciplines we already apply to code — version control, testing, monitoring, review — adapted to their peculiar, probabilistic nature.
1.4 The cost of treating prompts as throwaway strings
In most codebases that grew organically, prompts live as string literals scattered through the source. One is in a route handler. Another is half-built from string concatenation three files away. A third lives in a configuration file someone added during a late-night incident. No one can answer basic questions: which prompt is actually running in production right now? What did it say last week? Who changed it, and why? What happened to our quality metrics when they did?
Every one of those unanswerable questions is a production incident waiting to happen. The remedy is not heroic. It is the same move we made decades ago with application code: get it out of scattered literals, give it a home, give it a history, and put a gate in front of changes. Chapter 4 shows exactly how.
For Your Team
The hardest idea to convey to non-engineers is that an LLM feature is never truly “finished.” Because the model is probabilistic and the world it operates in keeps moving, an LLM feature is a system that must be monitored and maintained, more like a fraud-detection model than like a button on a form. When you scope LLM work, budget for the ongoing evaluation and monitoring, not just the initial build. A team that ships and walks away will be back, firefighting, within weeks.
1.5 What the rest of this book does
The chapters ahead move from foundations to organisational maturity:
- Part I establishes the mindset: prompts as engineered artifacts, and the evaluation-driven loop that replaces “tweak and hope.”
- Part II is the core engineering discipline — architecture, versioning, evaluation, and regression testing. If you read only four chapters, read these.
- Part III covers what it takes to run at scale: cost and latency, reliability under rate limits and failures, and observability.
- Part IV addresses the advanced and human concerns: multi-step agents, security and prompt injection, and the governance that regulated environments demand.
You can read it straight through, or jump to the problem in front of you. Either way, you will come out with a system you can trust and, just as important, a way of reasoning about LLM systems that survives the next model release.
Takeaway
Prototypes prove a prompt can work once. Production demands it works reliably, measurably, and maintainably — under non-determinism, drift, and silent regression. The shift required is not more clever prompting; it is treating prompts as engineered artifacts subject to versioning, testing, monitoring, and review. Everything that follows is an instance of that single idea.
Chapter summary
- The gap between a working prompt and a production system is large and mostly invisible from the prototype side.
- LLM systems break in ways ordinary code does not: non-determinism, silent regression, drift, and invisible coupling to undocumented model behaviour.
- “Just tweak the prompt” fails because you cannot see the side effects of a change without measurement.
- The book’s thesis: engineer prompts like code. The remaining chapters are the practical disciplines that follow from it.