Iterative Prompt Refinement: A Cycle That Saves Runs

The typical workflow looks like this: a request — wrong — rewrite everything — wrong again — rewrite again. After ten runs the result is no better than the first and no understanding has accumulated. The alternative is a four-step cycle that converges in three or four iterations.

Step one: a baseline run

Compose a request from the five required blocks — subject, action, setting, light, technique — and make two or three runs without changes.

Two runs are not for picking the best but for measuring the spread. If the results differ widely, the request is underspecified: the model is filling gaps its own way. If they are similar, the request was understood unambiguously and you can now edit precisely.

Step two: one main problem

Look at the results and name the single most significant divergence from your intention. Not a list of five — one.

The usual priority order: composition and shot size → light → expression and pose → optics → texture and processing. Editing a lower level is pointless while a higher one is unresolved.

Step three: a minimal edit

Change only what relates to the identified problem. Do not rephrase the rest — even a synonym shifts the result and confuses the next iteration.

If the problem is light, edit the light description. If it is shot size, edit only that. This lets you tie a change unambiguously to an outcome.

Step four: check and decide

Make two runs with the new request. Compare with the previous ones. Three outcomes:

• Better — lock the edit in and move to the next problem by priority.
• Unchanged — the problem was not in the element you edited. Revert and look elsewhere.
• Worse — revert and try the opposite formulation.

When to stop

Two signs that refinement is exhausted. First: edits stop producing a visible effect — you have hit the plateau of what the model can do for this task. Second: the spread between runs of one request exceeds the difference between request variants.

In both cases further refinement wastes budget. It is more practical to make more runs of the current request and select the best.

What to record along the way

Keep a short log: request version, what changed, the outcome. It sounds bureaucratic but pays off by the third iteration — memory of which variant produced what fades faster than expected.

Successful formulations are worth saving separately: they get reused in other tasks. Over time a personal library of working descriptions for light, backgrounds and processing accumulates.

A typical trajectory

1. Baseline request, two runs: the composition is wrong.
2. Edit shot size and placement, two runs: composition right, light flat.
3. Edit the light, two runs: light good, expression catalogue-like.
4. Edit the expression, two runs: close to the intention.
5. Five or six runs of the final request, select the best.

Four iterations, fourteen runs, a predictable outcome — against twenty runs of trial and error and a lucky hit.