Production prompts grow by accretion. A rule is added after one bug, an example after another, a formatting note after a complaint. Eventually the prompt misbehaves on some input and nobody can say which of its forty lines is responsible. Staring at it and guessing is the usual response. A better one comes from classic debugging: minimize the failure.

Start with a reproducible failure

Minimization only works if you can tell, mechanically, whether a given prompt "still fails". Before you delete anything:

  • Capture the exact input, the full rendered prompt, the model version, and the sampling settings.
  • Write a pass/fail check, even a crude one: a regex, a JSON schema validation, a string that must or must not appear.
  • Run the failing case several times. If it fails 3 times in 10, treat "fails in at least 2 of 10 runs" as your definition of still failing, and use that same sample size at every step.

If you cannot define the check, you have not yet understood the bug, and that is worth knowing before spending an afternoon editing.

Shrink in halves, not in whims

Split the prompt into logical blocks: role statement, each rule, each example, output format, the user data. Then apply delta debugging:

  1. Remove half of the removable blocks. Keep the user input and the output-format block fixed, since the check depends on them.
  2. Run the check. If it still fails, the removed half was irrelevant; keep it removed. If it now passes, restore that half and remove the other half instead.
  3. Recurse on whatever remains, down to single blocks.

In a handful of rounds you usually end up with a prompt of three or four blocks that still reproduces the failure. That is the interesting artifact. Often the culprit is not a single bad instruction but an *interaction*: a rule that says "always answer in one sentence" sitting next to an example that shows three. The minimal prompt makes such conflicts visible because there is nothing else to blame.

Then grow it back the other way

Once you have a minimal failing prompt, do the reverse experiment: take a minimal *passing* variant and add blocks from the original one at a time until it fails. The block whose addition flips the result is your suspect. Together, the two directions give you a much tighter hypothesis than either alone.

Some practical cautions:

  • Don't minimize the input and the prompt at the same time. Change one axis per experiment, or you won't know which change mattered.
  • Watch for position effects. Removing a block shifts everything after it. If behavior changes when you delete something harmless, note it; instruction position matters, and that is a finding in itself.
  • Keep a log. A short table of "blocks present, runs, failures" turns a vague session into evidence you can attach to the fix.

Close the loop

The minimal failing prompt is also your best regression test. Save it, with its check, in your eval set. Fix the prompt, confirm the minimal case passes, and then confirm the *full* prompt passes on both the original failure and your existing suite. A fix that works only on the minimized version has not fixed the product.

Prompt debugging feels like an art because we usually do it by intuition. Treating it as a search problem, with a reproducible oracle and a systematic way to shrink the space, makes it something you can do on a bad day and hand to a colleague.

Large Language ModelsSoftware Engineering