The regression set every prompt change has to pass

A founder building a small SaaS tool told me his AI feature had reached a state he called “afraid to touch it.” The feature worked well enough that customers relied on it. It also had a handful of known quirks he wanted to smooth out. Every time he opened the prompt to improve one thing, he stopped, because he had no way to know what else he might be breaking. So the prompt sat frozen, good but not better, held in place by fear rather than by any real constraint.

Fear is what you get when there is no test

He was in this spot for one reason. There was no set of cases he could run to answer the question “did my change help or hurt.” Without that, every edit was a bet placed blind. He could ship a change, wait a few days, and see if complaints went up. That is the slowest, most expensive feedback loop there is, and it runs on the backs of real customers hitting real bugs.

Normal software does not work this way, and nobody would accept it if it did. You change a function, you run the tests, you get an answer in seconds. The reason prompt work so often lacks this is that people treat the prompt as writing rather than as code. It reads like an instruction to a person, so it feels like something you revise by taste. But a prompt drives product behavior, and product behavior is exactly the thing you want tests around.

Build the set from cases you already have

The founder’s situation looked stuck, but the material for a fix was already sitting in front of him. Every quirk he wanted to fix was a case. Every support message was a case. Every “it does the right thing here” that he was afraid to lose was a case. He did not need to invent test data. He needed to write down the behavior he already knew the feature had to get right.

We started with about a dozen entries. Each was a real input paired with the behavior he expected on it, some correct-behavior cases he wanted to protect and some bug cases he wanted to fix. A short script ran every entry through the current prompt and showed which passed. For the first time, he could see the state of the whole feature on one screen instead of guessing about it.

The change in how he worked was immediate. An edit was no longer a leap. It was a change he could run the set against, watch the previously-broken cases flip to passing, and confirm the protected cases stayed green. The fear was gone because the uncertainty was gone.

What the suite needs to do its job

A regression set for prompts is simple, and a few properties make it worth keeping.

Store real inputs, not toy ones. The cases should be things the feature actually meets in production. Invented examples pass tests that reality then fails.
Pair each input with expected behavior. “Files this document as an invoice,” “refuses this request,” “extracts these three fields.” The check has to be something you can evaluate, not a vibe.
Grow it every time something breaks. A new bug becomes a new case the moment you find it. The set is a memory of everything the feature has ever had to handle.
Make passing it the ship condition. A prompt change is done when the set is green, not when the author feels good about it.

You do not need a framework to begin. A list of cases and a way to run them is enough to move prompt work off of luck.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement priced at $2,500, we build this suite early, because so much of a feature’s reliability rides on prompt changes made after we leave. We seed it with the real cases the feature has to pass and hand it over as something the team keeps extending. After that, the prompt stops being the scariest file in the codebase. It becomes a file with tests, like everything else that matters.

A prompt you are afraid to change is a prompt with no tests. Write the cases and the fear goes away.