Improve where you can measure; collaborate where you cannot
The auto-research loop
An auto-research loop is a simple structure with disproportionate effects. Propose a change. Run it. Measure whether the result improved against a target. Keep the change if it did, discard it if it did not, and propose the next change. Run continuously, the loop can produce sequences of incremental improvements without supervision. The pattern is well documented in software engineering, where it has produced double-digit percentage improvements on small projects in a single overnight run. The result is dependent on one condition: the success signal must be mechanical.
Why the success signal must be mechanical
An auto-research loop is only as honest as the measure it optimises. When the measure is mechanical — tests passing, runtime falling, conversion rate rising — the loop converges on improvements that survive scrutiny. When the measure is fuzzy — does the writing sound right, is the design elegant, is this argument persuasive — the loop converges on whatever the assistant happens to find pleasing, which is rarely the same as what a thoughtful human would call good. The result is a sequence of changes that look like improvements and are not. The first useful question to ask of any candidate loop is whether the measure can be wrong without anyone noticing.
The Ralph pattern for goal-directed work
A related but distinct pattern, less famous and equally useful, uses an external loop to feed a fresh assistant the same goal until the goal is met. The assistant works against the current state, makes progress, and reports back; a thin outer wrapper checks whether the goal is satisfied and, if not, runs the assistant again with the updated state. The pattern is well suited to bounded goal-directed tasks that have a clear completion test — a feature working, a document conforming to a checklist, a dataset cleaned to a specification. The discipline is the same as for auto-research: the completion test does the work, and the assistant follows.
Where these loops genuinely belong
The honest position is that unattended loops belong in a narrower set of categories than enthusiasts claim and a wider set than skeptics allow. Anywhere with a real test — software with a test suite, a generation pipeline with a measurable output, a routine artefact with a checklist — the loops produce results that compound. Anywhere the success signal is genuine human judgement, the loops produce volume without value, sometimes convincingly enough to take time to detect. The mature stance is to map one's working life into the categories and to use loops where they apply, collaboration where they do not, and the elimination hierarchy where neither does.
Augmentation amplifies; automation delegates
The clearest restatement of the working principle this module turns on is more than sixty years old. The early theorists of human-machine collaboration argued that the goal of computing was to augment human capability, not to substitute for it. The modern restatement, surfacing recurringly in working practice, is that automation delegates and augmentation amplifies. Delegation tends to produce volume; amplification tends to produce quality. Both have a place. Volume is correct for the work where a mechanical signal can defend the result. Amplification is correct for the work where the worker's own judgement is what the result rests on. A productivity stack that distinguishes between the two is a more honest stack than one that calls everything automation.
Of the recurring work you do, which pieces have a mechanical measure of success — a number that goes up — and which depend on a judgement only a person can make?