Recursive Self-Improvement for Artificial Intelligence Coding Agents: What Is Real, What Is Theory, and What We Shipped

Recursive self-improvement is the idea that an artificial intelligence system improves its own ability to improve. Here is what the theory actually says, why the model-level loop is still theory, and how we built the instruction-level version for coding agents with a human at the gate.

Recursive self-improvement is the idea that an artificial intelligence system can improve its own ability to improve. Not just get better at a task, but get better at the process that makes it better, so that each round of improvement makes the next round faster. It is the engine behind every “intelligence explosion” argument you have read, and it is also, in a much smaller and more practical form, something you can run on your own coding agent this afternoon.

This post does both halves. The first half explains recursive self-improvement properly, because most explanations either oversell it or wave it away. The second half explains what we shipped in Coograph this week: guardrails for coding agents that measure their own failures and propose their own fixes, with a person approving every change. We call it Retro. It is not recursive self-improvement in the model sense, and we will be precise about the difference.

What Recursive Self-Improvement Actually Means

The Original Argument, From 1965

The mathematician I. J. Good wrote the sentence everyone quotes: “an ultraintelligent machine could design even better machines; there would then unquestionably be an intelligence explosion, and the intelligence of man would be left far behind.” He added that the first ultraintelligent machine is “the last invention that man need ever make.”

The argument has three steps. First, artificial intelligence research is itself an intellectual task. Second, a system that is good enough at that task can produce a better system. Third, the better system is better at the task, so it produces an even better one, faster. The loop feeds itself. The word “recursive” refers to that structure: the output of one cycle is the input of the next, and the thing being improved is the thing doing the improving.

Why the Model-Level Loop Is Still Theory

If the argument were complete, we would already be living in the explosion. We are not, and the reasons are concrete rather than philosophical.

Compute is a bottleneck. A smarter idea for a training method still needs thousands of accelerators and weeks of wall-clock time to test. Intelligence does not shorten a training run.

Experiments are a bottleneck. You cannot reason your way to a benchmark result; you have to run the experiment. Each cycle of the loop waits on empirical feedback that arrives at the speed of hardware, not the speed of thought.

Verification is a bottleneck. A system cannot easily prove that its proposed successor is better without building and evaluating it, which puts you back at the two bottlenecks above.

Diminishing returns are real. The easy improvements go first. Each later cycle has to find something harder, so the “faster and faster” part of the story fights against a “harder and harder” trend that nobody has quantified in advance.

As of 2026, large language models do write training code, generate synthetic data, evaluate other models, and automate parts of the research pipeline. Frontier laboratories use their own models to speed up their own research. Partial loops exist. A closed loop where the system improves itself with no human in the process has not been demonstrated. Whether it can be is an open empirical question, and anyone who tells you the answer with confidence is guessing.

Why It Still Matters for Safety

If the loop ever closes and runs quickly, alignment has to be right before it starts. There is no second chance to fix a system’s goals during an explosion. That is why organisations like Anthropic treat the question seriously even while the loop stays partial. It is also why “recursive self-improvement” as a phrase deserves respect rather than marketing. Which brings us to the thing we actually built.

The Same Loop, One Layer Down

Every coding agent runs on two things: a model and a pile of instructions. The model is fixed; you cannot retrain it from your terminal. The instructions are yours: a CLAUDE.md, an AGENTS.md, a set of hooks, a handful of skills. That layer is where all the behaviour you can control lives, and that layer has its own improvement loop. Today, nobody closes it.

The Loop Nobody Closes

Here is how a rule gets into an instruction file today. The agent does something wrong. A human happens to notice. The human adds a rule, usually a louder version of a rule that was already there. The file gets longer. Nobody measures whether the new rule changed anything on the next session.

We can show you this from our own repository. The Coograph CLAUDE.md opens with a rule in capital letters: use the code graph before any grep. In a session transcript from September 2026, the agent ran grep five times before it touched the graph at all, nine times in total, and when it finally reached the graph it did so through a Python script rather than the tools the rule names. The rule was on line three of the file. Nobody knew, because nobody reads transcripts.

Every clause in that file that says “this is NOT an exemption” or “convenience is not a valid reason” is a scar from an earlier incident. Each one made the file longer, cost tokens on every session that followed, and the violations continued.

Closing It

The structure of recursive self-improvement is: run under version N, measure, produce version N+1, repeat, and let the process improve its own procedure. Applied to the instruction layer, that becomes concrete and cheap.

Sessions run under rule set N. A hook records every time a rule is broken and what the session cost. An analyzer turns the records into a report. A skill turns the report into a proposal for rule set N+1, including changes to its own detectors and to itself. A person approves or rejects each line. The next cycle measures whether the change moved the numbers.

That is Retro. Same recursion, different substrate, and a human on the return path.

What Retro Records

The raw material already existed. Claude Code writes every session to disk as a transcript: every tool call, its inputs, the order, the results, the token usage per message. Coograph’s existing hooks already fire when the agent edits outside the approved change or touches a generated file; they just printed a warning and forgot. We added a SessionEnd hook that parses the transcript, made the existing hooks write a record when they fire, and gave the whole thing a strict rule about what a record may contain.

A signal record holds the rule id, which detector fired, whether the detector is deterministic or heuristic, and an evidence object of counts, tool names, repo-relative paths, and a hash for shell commands. It never holds prompt text, assistant text, tool output, file contents, or a full command. That is not a policy; it is an allow-list in code, and a test plants a marker string in every part of a synthetic transcript and fails if the marker reaches the signal file. Nothing is uploaded anywhere. The file lives in your project, ignored by git.

Seven things get detected: grep before the graph, multi-file edits with no approved change, edits outside the approved change, hand-edits to generated files, the same build command failing three times in a row, a new dependency being installed, and a user message that looks like a correction. The last two of those (the multi-file guess and the correction guess) are labelled heuristic and can never be the sole evidence for a change. Every session also gets one summary record with tool counts and token totals, deduplicated per message because the transcript repeats usage on every content block.

What Retro Proposes

The analyzer is plain Python with no model in it. It reads the signals, the rule registry, and the archived changes, and writes a report: every rule against its threshold with an “escalate to” column, the directories where violations cluster, build retries, tokens per session with a before-and-after split around the most recent rule change, how many editing sessions also ran a review, and how large the instruction files have grown against a budget.

The skill reads that report and writes a proposal in the same format as every other change in a Coograph project. Five kinds of change are allowed: reword a rule when the evidence shows ambiguity, add a rule for a pattern nothing covers, add a scoped instruction file for the directory where violations cluster, add a hook, or prune a rule nobody has tripped in ten sessions.

Every proposed change opens with three plain sentences. What happened. Why it matters. What changes. Then an evidence block whose numbers come only from the report. If a number is not in the report, it is not in the proposal.

The Rules of the Loop

The loop has constraints, because a loop that rewrites its own rules without constraints is how you get the bloat you started with.

A prose rule that is still being violated is escalated to a hook. It is never reworded louder. The data from our own repository says louder does not work, and a hook cannot be skipped by an agent that is in a hurry.

Heuristic signals are never sole evidence. A guess about a user’s mood does not change a rule.

Over the token budget, every added rule must be paired with a pruned one. The instruction set cannot grow without bound just because the loop found something new.

Retro may propose changes to its own skill, its own detectors, and its own hooks. That is the recursive part. It may not change its own thresholds or disable a detector unless the proposal carries an explicit task saying so, because a loop that can quietly lower its own bar will.

Nothing is applied automatically. The proposal is an OpenSpec. You approve it, reject it, or strike lines from it, exactly as you would for a feature.

Day One, Not Day Twenty

The usual objection to any measurement tool is that you need weeks of data before it says anything. You do not. Claude Code has been keeping your transcripts all along, under a directory named after your project path. Initialisation offers to read them, so the first report has your real sessions in it before the setup finishes. Projects that never turned Retro on but have ten or more archived changes can bootstrap it with one command; the session-start line tells them so.

That line is also how you find out there is something to look at. Every Claude Code session in a Coograph project already prints the code-graph status at the top. Now it prints one more line, of the form: twelve sessions captured, three rules over threshold, run the retro. Nobody has to remember a step, and nobody has to finish a change the “proper” way for the loop to notice.

What This Is Not

Retro does not train anything. No weights change. It is not recursive self-improvement in the sense that I. J. Good meant, and we will not describe it that way in a sales deck. It is the instruction-layer version of the same loop: the system observes its own failures and proposes changes to its own scaffolding, including the parts of the scaffolding that do the observing.

Two honest caveats. Capture only works in Claude Code, because it is the only coding agent that exposes both transcripts and lifecycle hooks; the other seven tools Coograph supports get the analyzer and the skill but not the recording. And whether the loop keeps finding improvements over many cycles is unproven. Our expectation, consistent with the theory above, is diminishing returns: the first retro finds most of the value, later ones find less. We built the mechanism to measure that, so in a few months we will know rather than guess.

Try It

Retro ships with Coograph 1.1.0, in the Claude plugin, in the initialiser, and in the sync script that keeps registered projects current. The detector reference, the registry format, the thresholds, and the tests are documented in the repository. The docs page for Retro walks through the session-start line, the report, the proposal format, and the per-tool support table.

If you already run Coograph, pull, and your next session will tell you whether there is anything worth a retro. If you do not, the initialiser asks one question about it and then reads the transcripts you already have.

The interesting question about recursive self-improvement was never whether the loop is possible. Narrow versions of it plainly are. The question is what you let it change, how you measure whether the change helped, and who gets to say yes. We picked instructions, token cost and violation counts, and you.