Free preview

What a Self-Improving Loop Actually Is

In one line: a self-improving system is one that changes its own artifacts from its own production traces without a person in the edit, which makes the quality of its measurement the ceiling on everything it can become.

Almost every system in this course improves over time. Someone reads the failures, changes a prompt, retrains a model, ships it. That is a team improving a system. A self-improving loop removes the person from the edit and leaves them at the boundary, and that single change is what makes the design interesting.

The five stages

Propose, evaluate, select, deploy, measure. Every system of this kind has these five, whether or not anyone named them, and most designs that go wrong went wrong because a stage was assumed rather than built.

The stage in purple is the one that decides everything else. The loop moves in whatever direction the metric points. It has no other information about what you wanted. So the interesting failures are not "the optimiser is weak" — they are "the optimiser worked, and the metric was not the thing."

The property that governs the rest

A person editing a prompt has a goal in their head that the metric only approximates. When the metric and the goal disagree, they notice, because they can see the output and they remember what they were trying to do. That noticing is doing an enormous amount of unacknowledged work.

Take the person out and nothing holds the goal any more. The loop holds the metric. If there is a gap between the two — and there always is — the loop will find it and move into it, because from inside the loop that gap looks exactly like progress.

This is the sentence worth having ready:

An automated optimiser does not optimise the task. It optimises the measurement of the task, and it will find every place those two come apart faster than a person would.

Everything else follows from that. The evaluation design matters more than the optimiser. The ground truth has to sit somewhere the optimiser cannot reach. Promotion needs a gate that is not the metric being optimised. And the honest version of the system has a person at the boundary rather than no person at all.

Why anyone builds one

The case is real, and it is about throughput rather than capability.

A system with real traffic produces failures faster than a team can read them. Prompts, retrieval settings and routing thresholds interact, so tuning them one at a time by hand explores a tiny part of the space. And the input distribution keeps moving, which means a hand-tuned configuration is a snapshot that decays.

None of that makes the loop smarter than the team. It makes it faster, and it is only worth having if it is fast in a direction you actually chose.

What it is not

Three things get called self-improvement and are not, and separating them early is worth doing out loud in an interview.

Retraining on a schedule is not this. The artifact changes, but a fixed pipeline is producing it from new data — nothing is searching over candidates, so there is nothing to hack.

A model correcting itself inside one response is not this either, and there is evidence it does not work: without external feedback, intrinsic self-correction on reasoning tasks leaves accuracy flat or lower, with one reported drop of over 25 points across two rounds. The model has no new information — it is re-reading its own context with an instruction to find fault, which supplies noise rather than signal. The loop here works because each round brings something the model did not have: outcomes from production.

And a system that adapts per user at request time is personalisation. It changes behaviour, not artifacts, and it does not persist a decision across users.

The shape of the argument ahead

The chapter builds the loop in the order the design pressure actually arrives: what you are allowed to change, where candidates come from, how they are scored, why the scoring degrades under pressure, why the winner is usually worse than it looked, how to score a change without shipping it, why the evaluation set wears out, what happens when the loop starts consuming its own output, and what makes an automated promotion safe.

Key takeaway

A self-improving loop is propose, evaluate, select, deploy, measure — with no person inside the edit. Removing the person removes the only component that was holding the goal rather than the metric, so the loop moves toward whatever is measured and treats the gap between measurement and intent as progress. Design the measurement first; the optimiser is the easy part.

Next: what you are actually allowed to let it change.

Enjoying the preview?

Create a free account to unlock the rest of this course, the in-browser judge, and live AI mock interviews.

Sign up free to continue