I Built a Self-Improving Loop. The Judge Made It Worse.

What a pre-registered ablation taught me about guarded AI loops, and why I’m moving to verifiable code tasks next

TL;DR: I built si-loop, a small open-source scaffold that wires together a hypernetwork, a worker, a curriculum engine, a guarded judge and a competitive "global workspace". I pre-registered four hypotheses and ran a 4-arm ablation on 10 paired seeds. The workspace showed no detectable effect. The conservative judge, meant to protect the loop, hurt final performance. It rejected about 73% of rounds, which plausibly starved the model of updates. Here is what happened, what I learned, and what Study 2 will try.

The hype, and the narrower question

“Recursive self-improvement” is everywhere right now. Agents rewrite their own code and validate changes empirically. Models generate their own finetuning data. Proposer/solver self-play with verifiable rewards has shown promise. Hypernetworks emit adapters directly from task descriptions. Workspace-style coordination is showing up in multi-agent LLM systems.

Each of these pieces exists in isolation. I wanted to run a controlled test of what happens when you wire them into one closed loop and let a judge decide what the loop keeps.

That’s the question behind si-loop. It is a research scaffold, not a product. It does not claim recursive self-improvement, and it does not claim anything about language models. It tests two narrow questions:

1. Does a workspace that must select what to share help, compared with no sharing or random sharing?
2. Do conservative judge controls help or hurt?

The architecture in five pieces

• Model A (hypernetwork): generates a low-rank adapter for the worker from a support set and the workspace broadcast.
• Model B (worker): a small MLP that adapts with a few inner SGD steps and is evaluated on a query set.
• Model C (curriculum engine): a REINFORCE policy over difficulty bins, rewarded for tasks near 50% success.
• Model D (guarded judge): sealed randomness, fresh selection tasks every round, a lower-confidence-bound gate, a gap monitor and a hidden noisy canary with a query budget.
• The “Mom Center” (workspace): a Global Workspace-style buffer with limited capacity, salience competition, an ignition threshold and a time-to-live.

The loop:

for each round:
    C proposes tasks; A, B train (workspace broadcast conditions A)
    B and C post summaries; W runs the competition and broadcasts winners
    D compares candidate vs last accepted on fresh tasks + hidden canary
        accept  -> snapshot, credit assignment, update trust
        reject  -> roll back A, B, C and the optimizers

I also added a two-player Shapley attribution between A and B. The two scores sum exactly to the total improvement, and an interaction term measures how much A and B co-adapt.

Study 1: the reality check

Setup. Each task is few-shot sinusoid regression, y = a·sin(wx + p). Predicting zero for everything gives an MSE of about 1.29, which is the "no learning" reference level. I ran four arms on 10 paired seeds:

• full: competitive workspace, judge on
• no_ws: broadcast replaced by zeros
• random_ws: same capacity and TTL, random winners
• no_judge: every round accepted

random_ws matters most. Without it, you can't separate "shared information helps" from "competition helps."

Pre-registration. Before the report run, I wrote down four hypotheses, my own credences, a metric (final_hard: query MSE on a hard held-out set) and a decision rule. The rule used paired bootstrap CIs, Bonferroni correction at 98.33% for the three primary comparisons, and a smallest effect of interest of 0.05 MSE. The integrity of the pre-registration rests on git commit order and SHA-256 hashes of the frozen code, not on a third-party registry, which I say plainly in the paper.

Figure 1: final_hard per arm (lower is better). Bars are means with standard errors, dots are individual seeds.

Get Abdelkabir Ouadoukou’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

What I found:

• H1 (workspace vs none): no detectable difference. Mean difference −0.010, Bonferroni CI [−0.060, +0.034]. The minimum detectable effect was about 0.068, above my 0.05 threshold. That means the study can’t tell, which is not the same as “no effect”.
• H2 (competition vs random winners): no detectable difference on the primary metric (−0.027, CI [−0.071, +0.015]).
• H3 (judge vs no judge): the judge hurt. Removing it improved final_hard by 0.086 (Bonferroni CI [−0.168, −0.014]), and no_judge won in 8 of 10 seeds. full landed at 1.048 and no_judge at 0.962.
• H4 (Shapley interaction): slightly larger in magnitude on rejected rounds (+0.006), but small and confounded.

The judge’s accept rate was 0.267, so it rejected about 73% of rounds. Each rejection rolls the model back, so guarded arms kept roughly four times fewer updates under the same round budget. That is the plausible mechanism, though I didn’t test it directly.

One more consequence: the workspace broadcast only reaches the models after an accepted round. A judge that rejects most rounds therefore also starves the workspace, which weakens H1 and H2 even further.

Lessons learned

1. The gate was too strict.I had implemented five guards: an LCB gate, a gap monitor, a hidden canary, fresh selection tasks and rollback. None were tuned for how many updates they could lose in the loop. The gap monitor resulted in around 75% of rounds being marked as overfitting on dev seeds. The gap monitor was anchored to the round-0 generalisation gap, so ordinary learning progress looked like overfitting. I swept the threshold for the gate prior to the report run using a pre-specified selection criteria. The rule, declared in advance, was to pick the smallest threshold with a mean accept rate of at least 0.4. No setting reached it, even with the monitor switched off, so the rule selected nothing and I tuned nothing. The default values (pre-registered) were used during the report run. The gate was too strict; this is a result.
2. The curriculum failed. The learnability reward peaks at 50% success. This made the REINFORCE policy favour the easier bins, as the success rate for harder bins was close to 0. The proportion of harder bins was ~0.02 or less at the final round on dev seeds. As everything was close to the zero predictor (final_hard ranged between 0.96 and 1.05 compared to ~1.29 when predicting zero), very little learning occurs for harder tasks within the toy. This reduces the power of all comparisons.
3. The judge had nothing to exploit. It is fixed, not learned, and it checks against exact ground truth, so the loop had no way to game it. H3 does not mention anything regarding learnt judges or adversarial pressure.
4. The smoke tests found silent bugs. Initially the full, no_ws and random_ws versions were producing the same results. This was due to the broadcasting not happening until two consecutive acceptances. During another run, the training loss for one round became 9.5 × 10¹⁵. This was due to the inner SGD loop diverging. This was fixed with adding a tanh bounded adapter, gradient clipping within the inner loop, loss limiting and adding a NaN guard. These bugs would not have been found in the final table.
5. The pre-registration process is not perfect, however it was still beneficial. My pre-registration was informal. I debugged using seed 0. The AI assistant ran dev seeds 100–104. I could see the results of these. All of this was mentioned in the paper. It forced me to be honest and state there was no detectable differences. It also meant I could report a result that did not fit my hypothesis.

Per-round evaluation curves, mean ± s.e. over 10 seeds. Uniform-difficulty set (left), hard set (right).

A note on AI assistance: this code, the analysis scripts and the drafting were produced with substantial help from Anthropic’s Claude, under my direction. I decided the study design and the decision to publish nulls, and I’m responsible for the content.

Where Study 2 goes

The toy taught me what to build next. Here is the plan, with the risks I can already see.

1. Verifiable tasks. I will use Python micro-coding and bug-fixing tasks, with pytest as the verifier. I can generate unlimited tasks with embedded ground truth by mutating ASTs to insert bugs into known correct functions. Difficulty is controlled by the number of mutations. Unit tests don’t prevent reward hacking by the model learning to optimise for the expected output or manipulate the tests. I need hidden held-out tests, sandboxed execution and strong privilege separation. The learning loop will not write to any of the tests, judge or harness. This means that this learning loop will only work if the base model is competent to start with, so I will start from a pretrained small coder with LoRA.
2. Improved judge. The judge in study 1 failed because of low statistical power, not because it lacked the ability to learn. To fix this I would use a sequential test on a growing held-out pool, instead of a static LCB at n=32. Second, I would add an adversary: a Red team that proposes tests. A proposed test only counts if they are validated by the reference solution.
3. Open-ended curriculum. I would replace the 5-bin REINFORCE policy with generated tasks aimed at about a 50% solve rate. This is because the gradient signal for binary rewards will be greatest here. From study 1 I would add a minimum exploration rate, a minimum criterion (all generated tasks must have a validated reference solution) and an anchor test set.
4. Improved communication. In an LLM-based Study 2, workspace messages would naturally be text. One idea is to replace them with continuous latents or discrete codebooks. However, in a code loop this is not a big issue as the cost will come from the rollouts and testing. So I would run a profiler. Study 1 already used numeric vectors and showed no detectable effect, so the open question is whether the channel carries useful information at all. To test this I would run an oracle message ablation. By directly providing the hypernetwork with the real task information. If this doesn’t help then no channel design will help. Also from a safety perspective an opaque channel between the worker and judge could enable collusion. So I would avoid any latent protocol between those two agents.
   “Recursive” has to be a measurable claim. The test is a frozen-improver arm. If letting the improver update makes the rate of improvement increase, compared with an arm where the improver stays fixed at generation 0, that is evidence of recursion.
   Otherwise it is simply iterative training.
   Each stage gets its own pre-registration. Study 2 changes the environment, judge, curriculum and channel, and changing all four at once would make attribution impossible, so I will change one thing at a time.

Conclusion: building this as an independent researcher

The most useful thing I got from Study 1 was the workflow: Write down the decision rule first, isolate the dev seeds, hash the frozen code, report the intervals that don’t fit the story, and know that “my safety mechanism cost more than it protected” is an engineering fact.

I’m not claiming a self-improving system. My system is a weak learner, my judge needs re-calibration, and I have a plan to move into a real verification environment. This is a genuine starting point.

Everything is open. The code, hashes for the frozen config, pre-registration files, analysis scripts, and paper are all available.

Repo: github.com/abdelkabirouadoukou/si-loop

If you have any experience with verification environments, judge-calibration, sequential testing or curriculum generation then I would love to hear your thoughts. Especially on the plan for Study 2. Please file an issue, make a PR, or tell me where I am wrong!