Autonomous Improvement Rate

A system gets better by trying something, learning something from what happened, and using that the next time around. If that's the loop, then the speed of improvement depends on three things:

• E_t - Iteration throughput: How many experiments, attempts, simulations, builds, or other useful iterations can the system complete per unit of time?
• I_E - Information per iteration: How much useful information does each iteration produce? A thousand experiments that all tell you the same thing are not a thousand useful experiments.
• η_L - Learning efficiency: How effectively does the system retain what it learned and use it to make the next iteration better?

Why multiplication matters

These aren't three separate report cards. They compound. If a system becomes 10× faster at running experiments, 2× better at choosing informative experiments, and 3× better at retaining and exploiting the results, the improvement rate doesn't rise by 15×. In this simple model, it rises by roughly 60×.

That is the interesting part: modern autonomous systems can push on all three terms at once.

The terms interact

There is a catch. The easiest way to increase throughput is often parallelism, but parallel experiments cannot learn from one another while they are running. Ten sequential experiments can make experiment ten depend on what experiments one through nine discovered. Ten simultaneous experiments cannot.

So increasing E_t can reduce I_E. The goal is not to maximize any one term. It is to maximize the product.

The flywheel

The most interesting case is when the autonomous system works on itself. Better orchestration produces more successful autonomous work. That work improves the orchestration system. The improved system then produces useful work faster and with fewer expensive interventions.

better system → more autonomous work → faster system improvement → better system

That does not prove the loop accelerates forever; improvements can get harder to find. But wherever a system can act, measure the result, retain the evidence, and use it to choose a better next action, these three factors provide a practical way to think about what controls the speed of improvement.

Bad feedback can reverse the flywheel

Learning efficiency can effectively become negative. If the evaluator rewards the wrong thing - a bad test, a misleading simulation, an overfit evaluation, or some other weak proxy for reality - the system can learn efficiently in the wrong direction. More iterations then make things worse faster.

Fast autonomous improvement therefore requires trustworthy feedback, not just a fast loop.

Software is the fast loop

Software makes this easy to see. An AI coding system can write code, compile it, run tests, inspect failures, change the code, and try again. Iterations can take seconds or minutes. Failures are cheap and usually reversible.

That changes how you should search. When an iteration costs a few seconds of compute, brute-force exploration can be rational: try more variants, test them, keep the evidence, and move on. When an iteration means an expensive simulation, a long model run, a chemical reaction, or physical hardware, experiment selection matters much more. Cheap loops reward throughput; expensive loops reward careful information gain per attempt.

Simulation and computational research work much the same way. Instead of compiling code, the system runs a model or experiment. Instead of a unit-test result, it gets measurements. The loop is fundamentally similar:

propose → execute → measure → evaluate → learn → repeat

Physical systems run the same loop with a slower clock. Automated laboratories move samples and wait for reactions. Robots interact with real objects. Vehicles have safety constraints. Manufacturing consumes materials and energy. Physical mistakes cost more than failed software builds.

So I expect autonomous improvement to show up fastest where iteration is cheap and feedback is objective: software first, then simulation and computational research, followed increasingly by automated laboratories, robotics, manufacturing, and other physical systems.

Spend the scarce thing wisely

Autonomous systems should not simply maximize output. They should maximize completed useful work per unit of whatever resource is actually scarce.

In an AI software factory, local compute can be cheap and abundant while access to the most capable frontier models is limited or expensive. A useful operating metric is therefore:

Cheap local models can handle implementation, tests, retries, and repeated build/fix loops. More capable models can be reserved for architecture, difficult decisions, review, and escalation. If more work starts completing without consuming the scarce resource at all, the loop is genuinely improving.

Where I use this

In my current software-development workflow, Ratchetloop is the bounded delivery loop: agents implement in isolated worktrees, deterministic checks gate the result, independent model-family review judges the diff, and the run record preserves what happened. Local models can handle suitable high-volume work while frontier models are reserved for harder reasoning, architecture, and review. The operating metric is Autonomous Completed Work per Frontier-Model Token, not agents spawned or tokens generated.

Ratchetloop makes software delivery auditable. Strategy Assayer is the domain-specific evaluation layer that keeps higher experiment throughput from turning into faster overfitting.

I don't claim this is the final model of autonomous improvement. I claim it's a reasonable starting point: simple enough to reason about, specific enough to measure, and clear enough to prove wrong.

Todd Espy · August 2026

Generated output stats available on request.