The Prompt Tweak That Fixed One Thing and Broke Three
In April 2026, Anthropic added a short instruction to the Claude Code system prompt. It told the model to keep the text between tool calls under 25 words and to keep final responses short unless the task needed detail. The goal was reasonable: Opus had grown verbose and was burning tokens. The standard set of evaluations they ran before shipping showed no regression. So they shipped it.
Then the complaints came in. The model felt terse and mechanical. That is a regression: something that used to work stopped working, quietly, because of a change nobody connected to it. When they went back and ran a broader set of evaluations, one of them showed a 3 percent drop, for two different model versions. A single short instruction, well under 25 words, had quietly cost measurable quality on a task their normal suite never checked. They reverted it a few days later. Anthropic wrote this up in the open, and it is worth reading:
an update on recent Claude Code quality reports.
I am asking you to read a story about a team that got this wrong, so the page it comes from is here rather than a footnote. The quotes above are theirs, not my summary of them. If you only click one link in this chapter, make it that one. A careful team writing up a regression they shipped is rarer, and more useful, than any framework.
Sit with what happened there. A careful team, with a real eval suite, tested a tiny change for weeks. They still shipped a regression. The specific case that broke was not in the set they ran. The change probably fixed the verbosity it was aimed at. It also broke something else, and nobody saw it until users did. This is not a story about a sloppy team. It is a story about the limits of an eval set that was not built to catch this particular kind of break. That is a design problem, not an effort problem.
Sit with the shape of it. The suite was real, the change was small, and the testing was weeks long. None of that helped, because the case that broke was not in the set. You cannot test your way out of a coverage gap by testing harder.
The 3 percent drop in that story is worth sitting with for a different reason. A 3-point move is right at the size where the number of examples decides whether you see it at all.
Start with a single score. Eighty percent on 100 examples is not 80 percent. It is somewhere between 72 and 88, and that is before comparing it to anything. Run the identical system twice and the two scores will differ by several points for no reason whatsoever.
Now the comparison. Each line is a genuine improvement of that size, put through 4,000 simulated eval runs. The y axis is how often the eval actually noticed. On 100 examples a real 5-point gain is caught 15 percent of the time, so 85 percent of the time you conclude your better prompt did nothing. To catch it reliably you need about 1,000 examples.
The 2-point line never reaches the bar, even at 5,000. That is the uncomfortable part. If your eval set is a few hundred examples, a 2-point difference is not a small signal you should look at harder. It is not a signal your experiment can produce.
Which turns "how many examples do I need" from a matter of taste into arithmetic. Decide the smallest improvement worth shipping, then size the set so you would actually catch it. If you cannot afford that many labelled examples, that is a real constraint. The honest response is to stop reporting differences the set cannot support, rather than to report them anyway.
None of this makes a bigger set enough on its own. In the Anthropic story the size was not the problem. The failing behaviour was absent from the set entirely, and no amount of statistical power finds a case you never wrote down. Size decides what you can measure. Coverage decides what you can see at all.
That is the failure this lesson prevents. You change a prompt, swap a model, or adjust retrieval, and the change helps one thing while hurting three others. Nothing throws an error. The average looks fine. The break reaches production silently. A is the tool that makes that break loud instead of silent, and building one well is a skill the industry pays for and rarely teaches.
By the end of this lesson you will know which cases belong in the set, how many, and where they come from. You will also know how to keep the set from rotting, and the one mistake that turns every number it produces into a lie.