What to Optimise, Cheapest First

In one line: order the things the loop may change by how cheaply a bad change can be undone, and start at the bottom of that ladder, because the loop will ship a bad change and the only question is what it costs you.

The instinct is to rank candidates by how much improvement they could deliver. That ranking puts fine-tuning first, and it is the wrong axis. A loop running unattended will promote something wrong, repeatedly. What matters is the cost of that event.

The ladder

Each rung costs more to produce, more to evaluate, and more to undo than the one below it. That ordering is also, usefully, roughly the order of how often the rung is the actual bottleneck.

Instructions

The system prompt, the task description, the output contract. Cheap to generate, cheap to evaluate, and revertible by writing the old string back. A diff is human-readable, which matters more than it sounds — when the loop makes something worse, somebody has to be able to see what it did.

Demonstrations

Few-shot examples selected from real traces. The mechanism worth naming is bootstrapping: run the current system over training inputs, keep the traces where the final answer was correct, and use those traces as the demonstrations. The examples are then in the system's own voice and format, which is why they transfer better than hand-written ones, and the loop is selecting from a pool rather than inventing text.

Joint optimisation of instructions and demonstrations together is the standard modern approach, because the two interact — an instruction that reads well with three examples reads differently with none.

Configuration

Retrieval k, rerank depth, chunk size, temperature, routing thresholds, retry counts. Numeric, bounded, and the easiest rung to search well. It is also the rung where the loop most often finds a real win that a human would not have bothered to look for, because the search space is boring and large.

Composition

Which steps run and in what order: adding a rerank stage, dropping a verification pass, changing a fallback. Now the change is code-shaped, evaluation must cover latency and cost, and reverting means a deploy rather than a value change.

Weights

Fine-tuning on curated traces. Hours per candidate, a training set that is itself an artifact needing versioning, and a change nobody can read. Reverting is loading the previous checkpoint, which is fast — but knowing you should is slow, because the failure will be diffuse rather than local.

Why this order and not the other one

There is a second reason, less obvious and worth saying. Lower rungs give the loop a tighter feedback interval. A prompt candidate can be scored in a minute; a fine-tune takes hours before it can be scored at all. A loop whose iteration is measured in hours will get a handful of experiments a week, which is roughly what the team was managing manually — so the throughput argument that justified the loop quietly disappears.

What must never be in the loop's reach

Some artifacts look optimisable and must be fixed by construction:

• The evaluation set and the metric definition. A loop allowed to edit its own metric will improve very quickly and mean nothing.
• The guardrails — safety filters, permission checks, rate limits. Their whole value is being outside the optimisation.
• Anything with an external contract: API schemas, stored data formats, anything another team depends on.
• Anything whose change is not reversible by an automated process. If undoing it needs a migration, the loop cannot own it.

Saying this in an interview

Name the rungs, say you start with instructions and demonstrations, and give the reversibility reason rather than the effort reason. Then add the constraint that makes it a design rather than a preference: the loop may only own artifacts it can also revert unaided. If a rollback needs a human, the promotion needed one too.

Next: where candidates come from, and why "ask a model for a better prompt" underperforms.