The smallest-change rule — vary one thing at a time
Artifact: your iteration loop, structured as one variable per turn
1. The rule
When iterating on a prompt, change one thing per turn.
This is the same rule as debugging code, the same rule as A/B testing, the same rule as controlled experiments anywhere: if you change two things and the output gets better (or worse), you don't know which change caused it. You learn nothing for next time.
The discipline feels slow on turn two. By turn five it has saved you twenty turns.
2. Why people break the rule
Two reasons.
One: impatience. When the output is off, the temptation is to rewrite the whole prompt and "try a different approach." Sometimes that's right. Mostly it just resets the experiment with no data.
Two: bundled hypotheses. You suspect the format constraint failed AND the role line is off, so you change both. If the next output is better, was it the format fix or the role tweak? You don't know. Now you can't reproduce the move on the next prompt.
The fix: when you have two hypotheses, run two turns. Cheap.
3. The good iteration
A function the model wrote, with two issues. Now iterate.
This is wrong. The function is too long, the names are bad, and the error handling is too verbose. Rewrite it cleaner with better naming and more concise errors.Three changes at once. If the next version is better, you don't know which clue worked. If it's worse, same problem.
The error handling is too verbose. Replace the try/catch blocks with a single early-return pattern. Don't change anything else — function length, naming, all stay.Now the next output answers one question: does the early-return change fix the error-handling issue? If yes, the move worked and you can use it next time. If no, you know the move didn't work and try a different one. Either way, you learn.