The prompt edit that fixed one case and broke five you did not test

An engineer who owned a document-classification feature described a bug that took a week to understand. A customer reported that one type of invoice was being filed under the wrong category. He found the issue, adjusted a line in the prompt, confirmed the reported case now worked, and shipped it. A few days later three other customers wrote in. Documents that had classified correctly for months were suddenly landing in the wrong bucket. His fix had caused them. He had checked the one case in the ticket and nothing else.

A prompt is not a local edit

When you change a line of normal code, you can usually reason about what it touches. The function you edited affects the callers of that function, and the blast radius is roughly the shape of the call graph. A prompt does not work that way. The whole prompt is one instruction to one model, and every word interacts with every other word. Add a clause to handle invoices from one vendor, and you have subtly shifted how the model reads every other document too.

The engineer’s edit was reasonable in isolation. He told the model to pay closer attention to a field that distinguished the misfiled invoice. But that same field appears on other document types, and now the model weighed it more heavily everywhere. The cases that broke were not related to the case he fixed in any way he could have predicted by reading the prompt. They were related through the model, which reads the entire instruction at once.

Eyeballing one case tells you almost nothing

The trap is that the change looked verified. He reproduced the bug, applied the edit, saw the bug disappear, and moved on. Every step felt responsible. The missing step was checking whether the edit had cost him anything, and that step is invisible unless you go looking for it. There is no compiler warning when a prompt change degrades a case you did not run.

This is why prompt work feels deceptively cheap and turns out expensive. The edit takes two minutes. The regressions take a week to surface, arrive as separate tickets, and do not announce that they share a cause. By the time you connect them, you have lost the thread back to the change that started it.

Keep a set of cases that every change has to pass

The fix is not to be more careful when you read a prompt. Careful reading cannot predict how a model will reweigh an instruction. The fix is to stop trusting your eyes and start rerunning known cases.

Collect real cases as they appear. Every bug report, every tricky document, every “it should have done X” becomes an entry with an input and the behavior you expect.
Rerun the whole set on every prompt change. Not the case you are fixing. All of them. The point is to catch the ones you would never have thought to check.
Add the case you just fixed to the set. The bug you solved today is the regression you prevent tomorrow. The set should only grow.
Gate the change on the set passing. A prompt edit ships when the set is green, not when the reported case works. Those are different conditions.

None of this requires heavy tooling to start. A file of inputs and expected outputs and a script that runs them is enough to turn a two-minute gamble into a two-minute change you can actually trust.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500, one of the first things we build for a feature that leans on prompts is a regression set drawn from the real cases the feature has to handle. After that, a prompt change is not a guess someone made and hoped about. It is a change that either passes the known cases or does not, and you know which before it reaches a customer. That single habit prevents most of the mystery regressions teams spend weeks chasing.

A prompt edit that only fixes the reported case has not been tested. It has been tried.