Iterating on a prompt: fixing the part that is actually wrong

The first output is rarely the one you wanted. What you do next is where most of the time gets won or lost. The common move — delete the whole prompt and rewrite it from scratch — is slow, and it throws away the parts that were working along with the part that was not. The faster move is to read the failure, decide which single thing caused it, change that one thing, and run it again.

Prompting is debugging. And the first rule of debugging applies: change one variable at a time, or you will never know which change fixed it.

Read the output as evidence

A disappointing answer is not noise; it is a symptom, and the symptom usually points at the missing instruction. Train yourself to translate the complaint into the fix:

• "It is too generic." You did not name the audience or the argument. Add a context line that says who it is for and what it should assert.
• "It rambled." No length cap and no format. Add "under 150 words" and a shape.
• "It ignored my rule." The rule was probably buried in a paragraph. Pull it out into its own line, or into an "Avoid" list.
• "It invented a fact." No instruction on what to do with gaps. Add "if it is not in the source, say so — do not infer."
• "It answered a different question." The task verb was ambiguous, or a pronoun had nothing to point at.

Each complaint has a home. The skill is resisting the urge to rewrite everything when the evidence points at one missing line.

Change one thing, then look

Here is a prompt after exactly that process — the draft rambled and buried its one instruction, so the fix was a hard length cap, an imperative format, and a single example of the target:

Rewrite the paragraph below as a single instruction a skimming reader cannot miss.

### Audience
Developers reading a changelog who will spend three seconds on this line before moving on.

### Context
The draft buries the one action users must take inside eighty words of enthusiasm.

### Requirements
- Length: Under 30 words.
- Output format: One sentence, imperative mood.
- Keep the version number and the exact flag names unchanged.
- Avoid: adverbs, and any preamble such as "In this release".

### Example of the wanted output
Upgrade to 2.4 and replace --legacy with --compat before deploying.

### Paragraph
"""
In this release, which we are really excited about, we have made a number of improvements, and importantly the --legacy flag has now been removed, so you should switch to --compat instead.
"""

Notice what the revision did not do: it did not touch the subject, invent a new persona, or restructure the whole thing. It added the constraints the failure pointed at and left everything else alone. When the next run is still wrong, you will know the remaining problem is not any of the things you just fixed — because you did not touch them.

Add constraints, do not pile on emphasis

When an instruction is ignored, the tempting fix is to shout it: capital letters, "IMPORTANT", "you MUST". This almost always makes things worse — forceful phrasing backfires on current models, and it does nothing to fix the real reason the instruction was missed, which is usually that it was vague or buried.

The reliable fix is not more force, it is more precision. "Make it shorter" ignored? Replace it with "under 30 words." Still too long? The instruction was clear; something else is fighting it — maybe an example that is itself long. Emphasis treats the symptom. A sharper constraint treats the cause.

Know when to stop

Iteration has a floor. If you have made the prompt precise, given it an example, capped the length, named the audience, and it is still wrong in the same way, the problem may not be the prompt — it may be the task, the model, or an expectation the model cannot meet. Endless tweaking past that point is superstition, not debugging.

A good stopping test: can you name the next change and predict what it will fix? If yes, make it. If you are just rewording and hoping, stop — you have left debugging and started gambling. Save the version that works and move on.

The example above passed every check live in your browser. When your next output disappoints, paste the prompt into the checker first — a failing check is often the exact line the evidence was pointing at.