A team ships an LLM feature. It demos well, the prompt looks clever, everyone is pleased. A week later someone asks the one question every LLM feature eventually gets. Maybe a manager, maybe a customer, maybe the person sitting next to you. How well does it actually work?

And the room goes quiet.

There are logs. There is a full trace of every request: the prompt that went in, the chunks that were retrieved, the tokens, the latency, the answer that came out. What there is no way to produce is a number that says the answers were good. A developer who had been building agents for over a year described it exactly: when someone asks how well the agent performs, I freeze.

That freeze is the subject of this whole chapter. It has a name. Shipping on vibes. You tune the prompt until a handful of examples look right, you ship, and from then on quality is a feeling, not a measurement. When the feature seems worse you change something, glance at a few outputs, decide it feels better, and ship again. Every team building with language models is running one of two loops, and the difference between them is the difference between engineering and hoping.

Watch the left loop turn. Nothing in it tells you whether the system got better or worse between two ships. There is no before, no after, no evidence in either direction. Evals are the thing that breaks the cycle, because they replace feels better with a measured before and after. This lesson is about why that matters more than almost anything else you will build, and the rest of the chapter is how to do it.

It helps to see why the vibes loop is not just sloppy but actively dangerous. A prompt change is never local. You tighten an instruction to fix the one output someone complained about. That same edit moves every other case the model handles. And the model gives you no compiler error when your fix quietly breaks a case you were not looking at. A single edit has several possible effects at once, and without an eval you only ever observe the one you were looking at.

An eval does not stop you from changing the prompt. It stops the change from being a gamble. The cost of building the labeled set behind it is real, and this chapter is honest about that cost throughout. The cost of not having it is a slot machine. You feed it with production traffic, and the payout is measured in the trust of the people who use your product.

Because observability answers a different question than the one you are being asked.

Observability tells you what happened. It records the trace: the input, the retrieval, the tool calls, the final output, in full detail. Evals tell you whether what happened was good. Those are not the same question, and the gap between them is where quality quietly dies.

The numbers make the gap concrete. The LangChain State of Agent Engineering survey asked more than 1,300 people who are actually shipping agents. 89 percent of them had implemented observability. 52 percent had implemented evals. Almost everyone can see their traces. Barely half can score them.

Read the two bars as a pair. A logged wrong answer looks exactly like a logged right answer. The trace is identical, the latency is fine, no error was thrown. Observability shows you the output in perfect detail and stays completely silent on whether it was correct.

89 against 52 is not a small operational detail. It is the difference between a team that can improve its system on purpose and a team that can only guess.

Put the two boxes side by side and the point is hard to argue with. Same status code, same latency, same token count, no error thrown. Everything your monitoring watches is identical for the answer that was right and the answer that was wrong. A trace records what happened. It never records whether it was any good.

The reason this matters right now is worth saying plainly. Model intelligence has largely commoditized. Anyone can call a strong model through an API. One thing separates a feature that works from one that merely runs. It is the ability to measure quality and improve it on evidence. That is what LLM evaluation means in practice. That is why eval literacy has become the clearest signal that someone has actually built with LLMs rather than just read about them. It is, more than prompt tricks or framework knowledge, the job.

This is the instinct every engineer brings from normal software, and it is worth understanding exactly why it does not carry over.

Classic software is deterministic. You call add(2, 2) and it must return 4, every time, forever. So a unit test asserts one exact output: assert add(2, 2) == 4. That works because there is a single correct answer and any deviation is a bug. This is the world unit tests were built for, and they are perfect at it. Nobody replaces a unit test on a pure function with a fuzzy judge, and nobody should.

LLM output is open-ended and non-deterministic. Ask a model to summarize a support ticket and a hundred different wordings can all be correct. Ask it the same question twice and you can get two different strings, both fine. There is no single ground-truth string to compare against, so output == expected has nothing to check. The exact-match assertion that was your sharpest tool becomes useless the instant the output stops having one right form.

Walk the fork in the diagram. The question that splits the two worlds is simple: is there exactly one correct output string? For a calculator, yes, and the unit test works. For a summary, an answer, a rewrite, a plan, no. Many outputs are valid, none is the reference, and string equality falls apart.

They measure word overlap with a reference answer, and for open-ended text that turns out to be close to useless.

BLEU and ROUGE count how many words or short phrases the output shares with a fixed reference string. BERTScore does a softer version using embedding similarity instead of exact words. All three assume there is a canonical answer to compare against. For translation with a tight reference they had a real use once. For the open-ended generation LLMs do now, the assumption breaks, because there is no single reference. A correct answer written in different words shares few tokens with your reference and scores low. A wrong answer that happens to reuse the reference's vocabulary can score high.

You can watch this happen. The snippet below scores a correct paraphrase and a wrong-but-overlapping answer with a simple word-overlap metric, the same idea ROUGE is built on.

In my run, the score and the person disagreed on four of the five pairs. Two right answers scored low because they used other words, and two wrong answers scored high because they reused the reference's words.

The correct paraphrase scores lower than the answer that reuses the reference's words while getting the meaning wrong. A metric that ranks a right answer below a wrong one is not measuring quality, it is measuring vocabulary. As Hamel Husain and others who work on evals full time put it, these scores create an illusion of confidence that is unjustified. By 2026 they are largely dead for generation work. What actually runs production evals is two things: human review and .

The lab's score is simple enough to compute on paper, and doing it once shows exactly where it goes wrong.

The score first turns each sentence into a set of words: lower case, punctuation removed, and each word counted once even if it appears twice. Then it counts the shared words, the ones in both sets. From that it builds two ratios. Precision is shared words divided by the words in the answer. Recall is shared words divided by the words in the reference. The final score, called F1, is a kind of average of the two: 2 × precision × recall ÷ (precision + recall). For sets of words, that works out to the same thing as 2 × shared ÷ (answer words + reference words), which is easier to do by hand.

The reference: "The payment failed because the card had expired." As a set, that is the, payment, failed, because, card, had, expired. Seven words ("the" appears twice but counts once).

The correct paraphrase: "Your card was out of date, so the charge did not go through." As a set: your, card, was, out, of, date, so, the, charge, did, not, go, through. Thirteen words. Shared with the reference: only "card" and "the". Two words. So the score is 2 × 2 ÷ (13 + 7) = 4 ÷ 20 = 0.20. That is the 0.20 the lab prints for the first answer, well under the pass line of 0.50.

The wrong answer: "The payment expired because the card had failed to load." As a set: the, payment, expired, because, card, had, failed, to, load. Nine words. Shared with the reference: the, payment, expired, because, card, had, failed. Seven words, which is every word of the reference. So the score is 2 × 7 ÷ (9 + 7) = 14 ÷ 16 = 0.875, printed as 0.88.

Look at what happened. The wrong answer swapped two words, "failed" and "expired", and that swap reversed the meaning. The score cannot see it, because a set has no order. The right answer used different words for the same idea ("out of date" for "expired", "did not go through" for "failed"), and the score punished it for that.

The fourth pair in the lab takes this to the limit. The reference is "Ask the customer to add a new card and retry the order." The wrong answer is "Ask the customer to retry the card and add a new order." Both sentences have exactly the same eleven words as a set, so the score is 2 × 11 ÷ (11 + 11) = 1.00, a perfect score for an instruction that makes no sense.

Real BLEU and ROUGE are more careful than this. They look at short runs of words, not just single words, and add other adjustments, so their exact numbers would differ. But they still score the surface of the text, and the surface is not the meaning. That is the point the lab is built to show, and the lab's own notes say not to quote its numbers as BLEU or ROUGE.

Usually it is bad news. A perfect pass rate almost always means your evals are too weak, not that your system is flawless.

This is the counterintuitive point that pays off across the whole chapter, so it is worth planting now. If every case passes, you are not challenging the system. Real LLM features fail in specific ways, and you can find them. They miss a retrieved document. They ignore a constraint buried in the prompt. They invent a number. They answer a slightly different question from the one asked. An eval suite that never catches any of this is not describing a perfect system. It is describing a suite that only tests the easy path.

The move that separates people who do this well is to treat a green board with suspicion. When everything passes, the next question is not ship it, it is what failure am I not testing for. That instinct comes directly from having read your own failures, which is why the chapter starts there and not with tooling.

There is a matching trap on the other side. It is easy to write evals that check things the model already does perfectly, because those are the easy ones to write. They stay green forever and tell you nothing. Good evals cluster around the places the system actually breaks, and you only know where those are by looking. This is why the next lesson is error analysis and not a tool. Reading your own outputs tells you which evals are worth writing. No amount of tooling can replace that first look.

Between the output and the next thing you fix. Evals are not a dashboard you check on Fridays. They are the feedback signal that decides where you spend effort.

Follow the arrows. An input enters the system, which is your prompt, your model, your retrieval, and any tools. The system produces an output. Observability logs that output, but cannot grade it. The eval scores it against a defined property, and here is the part that matters: the score does not just sit there. It names a specific failure mode, retrieval missed the doc, the prompt dropped a constraint, the model hallucinated, and that is what you change next.

This is the difference between an eval and a metric on a chart. A chart tells you a number moved. An eval tells you which output failed and why, so you know exactly where to put your next hour of work. When people who build this for a living say evals are the job, this loop is what they mean. The prompt tweaking, the model choice, the retrieval tuning, all of it is downstream of the signal the eval gives you. Without that signal you are back in the vibes loop from the first slide, changing things and hoping.

Turn that signal into a working practice and you get eval-driven development, the discipline that mirrors test-driven development for a non-deterministic system. Write the eval from a real failure first, so the definition of good exists before you touch anything. Then make one change, measure the whole set, and let the number decide whether you ship or go back.

The loop is honest about cost. Writing and maintaining the eval set is real work, and a good needs a set of labeled examples behind it plus ongoing upkeep as the product changes. The payoff is that every change after that is a measured step and not a gamble. The set only grows stronger as you feed each new production failure back into step one. One change at a time is not a nicety either: it is the only way the delta can tell you what caused what.

The honest objection to all of this is that evals are effort, and they are. So it is worth being just as honest about the alternative, because shipping blind is not free. Its bill simply arrives later, and in a currency you would rather not pay in.

Start with timing. The same regression shows up twice. It shows up first as an eval score that drops the moment you make the change. It shows up again much later, in the business numbers a bad product eventually moves. Complaints, refunds, churn, a growing support queue.

An eval is a leading signal. Churn is a lagging one. The distance between the two dots is weeks of a worse product shipping to real people. A green business dashboard during that window is not evidence the model is healthy. It only means the damage has not compounded far enough to show up yet. Evals let you act on the first signal, while a fix still costs a code review instead of a churned account.

Now draw the failure itself as it actually unfolds. A change ships, quality slides on every request, and because nothing errors, every operational dashboard stays green the whole time. The regression is silent, and the entire window between the change and the eventual complaint is served to real users at the lower quality.

The cost of no evals is not zero, it is deferred. You either pay a small, known cost building and running the set. Or you pay a large, unknown cost in silent regressions, found by the people you least want to find them. Evals move that bill to the cheapest possible moment, the commit, where a regression is a red check on a pull request instead of a lost customer. That trade, a little work now against a lot of damage later, is the whole economic case for taking evals seriously.

Teams that decide to take evals seriously tend to trip over the same few things in the first weeks. None of them is about tooling.

Starting with a tool instead of the outputs. It is tempting to install an eval framework first and then look for something to measure. The framework will happily score whatever you point it at. But you only know what is worth scoring after you have read real outputs and seen how they fail. That is why the next lesson is reading, not installing.

Scoring with word overlap because it is easy. The by-hand slide showed why a score can rank a wrong answer above a right one. A number that is easy to compute is not the same as a number that means something.

Trusting a judge model before checking it. A second model that grades answers is fast and cheap. It is also a model, with its own habits. Until you have compared its grades with careful human labels on the same cases, its number is an opinion. Later lessons in this chapter measure several of those habits directly.

Writing only easy cases. A set built from cases the system already handles stays green forever. Cases should come from real failures.

Changing several things at once. If you change the prompt, the model and the retrieval in one release, and the score moves, you cannot say which change moved it. One change per measurement keeps the delta readable.

Treating the set as finished. The product changes, users ask new things, and new failures appear. A set that never grows slowly stops describing the system it is meant to measure.

Reading a small change as real. On a small set, a score can move a few points from one run to the next with nothing changed. Later lessons in this chapter show how to tell a real change from noise, and how many cases that takes.

Evals are a tool, not a religion. It helps to know where they pay off and where they do not.

You need one when the output is open-ended and someone will depend on it: a summary, an answer from documents, a support reply, an agent's plan. Anything where "is this good?" cannot be answered by checking one exact string.

You need one before you change a prompt, swap a model, or change retrieval on a feature that is already in use. Those are the moments when a silent regression can ship.

A plain unit test is better when there is exactly one right output: a parser, a date format, a JSON schema, a calculation. Use the test. It is faster, cheaper and exact.

A tiny eval is enough when you are exploring an idea that nobody depends on yet. A handful of cases you read yourself is fine at that stage. The mistake is not starting small. The mistake is still being at that stage when real users arrive.

No amount of evals replaces the decision about what "good" means for your product. That decision comes first, and it is made by people.

In the only order that works, because each step needs the one before it. Before we walk that order, it helps to see the ladder every team climbs, so you can place yourself honestly on it.

Nobody builds the top rung on day one, and you do not need to. The jump that matters most is from rung zero to rung two. That is the move from a feeling to a fixed set you can re-run. It turns quality from an opinion into a number two people can argue about with evidence. Everything above it, the judge and the gate, is automation of a ruler you first have to build by hand. With that picture in mind, here is why the chapter teaches its steps in a fixed order.

Error analysis comes first. Before you can measure quality you have to know what failure looks like in your product. The only way to learn that is to read your own outputs and label how they go wrong. Hamel Husain writes some of the most-cited practical material on this. He calls error analysis the most important activity in evals. It tells you which evals are worth writing in the first place. Everything downstream depends on it.

Golden datasets come next. Once you know your failure modes, you turn them into a fixed set of labeled examples. This becomes the ruler every later eval is measured with, so it has to come after error analysis, not before. You cannot build a good ruler until you know what you are measuring.

LLM-as-judge comes after that. With a labeled set in hand, you automate the scoring so it runs on every change. You also learn the judge's own biases and failure modes before you lean on it. Validating the judge comes last, because it depends on everything above. You check the judge's scores against your human labels, and only once it agrees with people is its output worth acting on. A judge you have not validated is just another opinion wearing the costume of a metric.