In April 2026, a benchmark called SkillFlow gave AI agents 166 tasks and no skills to start with. After each task, an agent could add to its own skill library. For one strong model, Claude Opus 4.6, the growing library lifted success from 62.65% to 71.08%. For another, Qwen-Coder-Next, the library made it worse than having no skills at all.
Those are the authors’ numbers, not mine. But they hit the sentence at the centre of my project: an agent that writes its own Python code to build skills, and keeps developing, more and more. SkillFlow’s phrase for it: high usage doesn’t mean high utility.
This is the sixth of my RIAI Lab Notes. The first five were about building: a mind that starts from nothing, a terminal that learns what commands do, code built by search, a JEPA that plans code in vector space, and a live test where it fooled its own check.
After five notes of building, I stopped and read the field. Four areas sit closest to what I’m doing:
- Self-improving agents that build skills or rewrite their own code.
- Program synthesis: writing programs from examples, and learning libraries of reusable pieces.
- World models for code: models that predict what a program does, and planners that search inside them.
- Continual learning and open-endedness: how a system keeps improving without forgetting or stalling.
For each area: what others built, their headline results, and what it says about mine. Every number from a paper is the authors’ own claim; I haven’t reproduced any of them.
The second thing I learned is a relief. The live-test failure, where “longest word” passed every check meant for “most common word”, isn’t new. It has a name, a 2010 paper, and a known fix.
The map
1. Self-improving and skill-building agents
Terms: a skill library is code the agent wrote and can call again. Self-modification means editing its own control code, not just its tools. An archive keeps many variants of the agent, not only the latest.
| System | Year | Idea | Headline result (authors’ claim) |
|---|---|---|---|
| Voyager | 2023 | GPT-4 plays Minecraft, writes JavaScript skills, keeps one only after self-verification | 3.3x more unique items and tech-tree milestones up to 15.3x faster than prior state of the art |
| ASI (Agent Skill Induction) | 2025 | Skills are Python functions, kept only if re-running the task with them succeeds | +23.5% success on WebArena over a static baseline |
| SICA | 2025 | The best agent so far edits its own codebase, then gets benchmarked | 17% to 53% on a 50-task subset of SWE-bench Verified, about $7,000 in API cost |
| Darwin Gödel Machine (DGM) | 2025 | An archive of coding agents; each child edits its parent’s repo | SWE-bench Verified 20.0% to 50.0%; about $22,000 and 2 weeks per run |
| AlphaEvolve | 2025 | Gemini proposes code changes, automated evaluators score them | A 4x4 complex matrix multiplication with 48 scalar multiplications; 0.7% of Google’s worldwide compute recovered |
| Absolute Zero | 2025 | One model proposes its own Python tasks and solves them; a code executor checks both | AZR-Coder-7B coding average 61.6, 0.3 above models trained on expert-curated code |
| SkillFlow | 2026 | 166 tasks; agents start with no skills and patch a library after each task | Opus 4.6 62.65% to 71.08%; Qwen-Coder-Next worse than no skills |
| EvoAgentBench | 2026 | 4 domains, 528 training and 267 test tasks | “No current automatic self-evolution method yields positive gains in all settings” |
Two more details. SkillLearnBench (2026) found that self-feedback alone led to recursive drift; external feedback was needed. And in one DGM experiment, the agent removed the markers the researchers used to detect hallucination in the reward function: a better score by editing the check.
The closest relative to my loop is ASI: write a Python function, verify it by running it, then add it. Its weakness: “does the task succeed when re-run” can still pass a wrong skill. That’s my live-test failure, in someone else’s paper.
What it means for RIAI
Where RIAI is unusual. Most of these systems have no explicit model of what their actions do; the language model’s general knowledge stands in for it. My terminal agent has an explicit, learned, inspectable model of command effects, and it passed a 20-task exam with zero language-model calls in run 7. My coders write small programs with no LLM at all (13 of 13 for the search coder, 8 of 12 for JEPA v2). The hidden host check is kept apart from the agent’s own judgement, which is exactly the separation DGM’s marker removal shows you need. And every result races a baseline at equal steps.
Where RIAI is behind. The agent never edits its own planner or learner, only its tool set. It keeps one linear history of runs, not an archive of variants. Its exams are hand-written, so it doesn’t propose its own tasks. And it has never been tested on a public benchmark. Today, Haiku writes its tools, not the agent.
The 2026 benchmarks change how I’ll measure “more and more”. A growing library has to show that it helps, at equal compute, on tasks I didn’t choose.
2. Program synthesis and the spec problem
Program synthesis is writing a program from a description of what it should do. When the description is a few input/output examples, it’s called programming by example. Two parts of this field matter for RIAI: how to learn a library of reusable pieces, and what to do when the examples don’t pin down one program.
Learning libraries
| System | Year | Idea | Headline result (authors’ claim) |
|---|---|---|---|
| DreamCoder | 2020 | Search for programs, compress solutions into new library functions, train the guide on replayed and “dreamed” programs | Rediscovered concepts like vector algebra and Newton’s and Coulomb’s laws (the abstract gives no numbers) |
| Stitch | 2023 | Fast search for the abstraction that compresses a set of programs most | About 3 to 4 orders of magnitude faster than DreamCoder’s library learning, with comparable or better compression |
| LILO | 2024 | LLM-guided synthesis, Stitch compression, and an LLM that names and documents each new function | Solves more complex tasks than DreamCoder on strings, scenes and graphics (no numbers in the abstract) |
| ReGAL | 2024 | An LLM refactors solved programs into shared helpers; a helper is kept only if the refactored programs still give the same outputs | CodeLlama-13B: +11.5 points on LOGO, +26.1 on Date understanding, +8.1 on TextCraft |
| “Library Learning Doesn’t” | 2024, 2025 | Audits of whether learned libraries are actually reused | Reuse was “extremely infrequent”; in a follow-up, LEGO-Prover’s gains disappeared once compute cost was counted |
The audits are the sobering part: when someone checked, the learned functions were rarely called, and the gains came from other things, like self-correction.
The spec problem has a name
A specification is what the program is supposed to do. In programming by example, the examples are the specification, and when two different programs fit them all, the field calls it ambiguity. The standard fix is a distinguishing input: an input on which the candidate programs disagree. Ask what the right answer is for that input, add it as an example, and repeat.
| Work | Year | Idea | Result (authors’ claim) |
|---|---|---|---|
| Jha, Gulwani, Seshia, Tiwari | 2010 | A solver finds two programs that fit the examples but disagree on some input; an oracle answers; repeat until no such input exists | Won the ICSE most-influential-paper award in 2020 |
| Ji et al. | 2020 | Pick the question whose worst-case answer rules out the most candidate programs | The authors note earlier interactive synthesizers picked questions at random |
| SmartLabel | 2025 | Active learning that keeps asking until the remaining candidates are guaranteed to behave the same | Found the true program on 98% of benchmarks in fewer than 5 rounds on average, against at most 65% for earlier methods |
| Vericoding benchmark | 2025 | Write code that a formal verifier proves correct against a given spec | Off-the-shelf LLMs reach 82% in Dafny, 44% in Verus, 27% in Lean |
The last row is a useful warning. Formal verification is the strongest check there is, but it assumes the spec is right. It doesn’t remove the spec problem. It moves it into the spec.
One more paper fits my situation closely. Padhi and colleagues (CAV 2019) proved that a more expressive grammar can make a synthesizer worse, because more programs can fit the examples by accident.
What it means for RIAI
The live test was a textbook case. “Shortest program first” is an Occam rule, the same bias DreamCoder builds in. Without a distinguishing input, a confident wrong answer is expected, not a bug. The input I guessed at in that post, something like 'a bb a', is precisely what Jha’s method would search for, and every new statement I add to the JEPA v2 grammar raises the risk Padhi describes.
On libraries, my 11 mined blocks were chosen by frequency in random-generator traces: res = res // 2 won because it appeared 19,373 times, not because it helps solve anything. DreamCoder and Stitch choose by compression of solved programs, ReGAL verifies helpers by execution, and the audits check reuse. I have none of those yet.
3. World models for code
A world model predicts what happens next when you take an action. For code, the action is a line or a block, and “what happens” is the new program state. A latent planner searches inside the model’s own compressed representation instead of running everything for real.
| System | Year | Idea | Headline result (authors’ claim) |
|---|---|---|---|
| Learning to Execute | 2014 | An LSTM reads a short program and predicts what it prints | 99% on adding two 9-digit numbers |
| CWM (Meta’s Code World Model) | 2025 | 32B model trained on over 120M traced Python functions | State exact match 96.4% and action exact match 98.0% on function-level traces; planning with the model left as future work |
| LLM-JEPA | 2025 | JEPA loss pairing text with code as two views | On Llama-3.2-1B, NL-RX-SYNTH from 57.29% to 71.46% |
| MuZero | 2019 | A latent model unrolled 5 steps in training, planning by tree search | State of the art on 57 Atari games; matches AlphaZero in Go, chess and shogi without the rules |
| TD-MPC2 | 2024 | A decoder-free latent model, planning 3 steps ahead and re-planning after every action | 104 tasks across 4 domains with one set of settings |
| V-JEPA 2-AC | 2025 | A frozen video encoder plus an action predictor trained with a rollout loss; plans 1 step and re-observes | Robot pick-and-place of a cup: 80%, against 15% for Octo |
| Debugging Code World Models | 2026 | Studies where CWM-style models go wrong | Long-horizon errors come mainly from wrong actions; failures cluster on string values (no numbers in the abstract) |
The trace format
My traces.py records, for every line, which variables changed, the next line, the return value and any error. My trace code refers to “the paper’s format” without naming the paper. That format very likely matches CWM’s: local variables per frame, unchanged values marked, and call, line, return and exception events. I still need to confirm it. If it does, the lesson from CWM is humbling: 96 to 98% per-step exact match came from a 32B model trained on trillions of tokens, and even then its authors don’t show that planning with it works. My exact-value model reached 57% on one step, 24% on three and 18% on five.
A JEPA over program states looks new
The research found no published JEPA over program execution states. LLM-JEPA pairs a text description with code, not a state before a step with the state after it. So my setup looks new, with the honest caveat that unindexed work can’t be ruled out.
Why open loop got 1 of 12
In the JEPA post, the planner solved 10 of 12 when the real state was re-encoded after every step (closed loop), and 1 of 12 on pure imagination (open loop). The literature points to a clear likely cause.
jepa.py trains on 240,003 single-step transitions, but the planner chains its own predictions up to 4 steps. After step one, the predictor sees inputs unlike anything it trained on. Every strong latent planner above trains through multi-step rollouts (MuZero unrolls 5 steps; V-JEPA 2-AC adds a 2-step rollout loss). And the beam search makes it worse: keeping the 64 candidates whose predicted state is closest to the goal favours predictions that are wrong in a flattering direction.
What it means for RIAI
My closed loop is exactly how these systems act: plan a short way ahead, take a real step, look again. So 10 of 12 is the normal regime, not a cheat; 1 of 12 measures the imagination on its own. The fix to test is multi-step rollout training. Since a real step in code is cheap, open-loop planning matters most where running things is costly or unsafe, like terminal commands with side effects.
4. Continual learning and open-endedness
How does a system keep getting better over a long time? Four problems keep coming up: forgetting old skills, losing the ability to learn new ones, curiosity that chases noise, and self-training loops that stall.
| Work | Year | Idea | Headline result (authors’ claim) |
|---|---|---|---|
| Catastrophic forgetting (McCloskey and Cohen) | 1989 | Training on task B overwrites the shared weights that held task A | The original description of the problem |
| Loss of plasticity (Dohare et al., Nature) | 2024 | Long continual training slowly loses the ability to learn | Continual ImageNet: 89% on an early task, 77% by the 2,000th; “continual backprop” (reinitialising a few little-used units) appears to fix it |
| Sparse memory fine-tuning | 2025 | Update only memory slots the new data strongly activates | Drop in NaturalQuestions F1 after learning new facts: full fine-tuning 89%, LoRA 71%, sparse memory 11% |
| RND and the noisy-TV problem | 2018 | Curiosity bonus from failing to match a fixed random network | Above average human on Montezuma’s Revenge without demonstrations; names the trap of curiosity drawn to random noise |
| Learning progress (IAC, Oudeyer et al.) | 2007 | Go where prediction error is falling fastest, not where it’s highest | A real robot chose easy situations first, then harder ones, and avoided ones where nothing could be learned |
| Go-Explore (Nature) | 2021 | Remember promising states, return to them, then explore | Solved all previously unsolved Atari games |
| OMNI / OMNI-EPIC | 2023, 2024 | A foundation model judges which tasks are “interesting”; OMNI-EPIC writes code for new environments | OMNI beat uniform and learning-progress-only baselines |
| ReST-EM | 2024 | Sample answers, keep the ones marked correct, fine-tune, repeat | MATH: 41.0% at iteration 2, 41.9% at 3; APPS: most gains in iteration 1, then regression from overfitting a small set |
| Model collapse (Nature) | 2024 | Training recursively on generated data loses the tails of the distribution | Seen in LLMs and other generative models |
The noisy-TV problem deserves one line of explanation. An agent rewarded for being surprised gets stuck in front of a TV showing static, because static is always surprising. The standard remedy is to reward how fast the prediction is improving instead of how wrong it is. That’s learning progress.
Open-endedness means a system keeps producing new, learnable things with no fixed finish line. OMNI’s point is that learning progress alone still leaves endless tasks that are learnable but boring.
What it means for RIAI
Why the flywheel likely stalled. In the JEPA post, the agent’s verified solutions were traced, added to training, and the model fine-tuned for 3 minutes; exact imagination stayed at 2 of 11 before and after. The research suggests ordinary reasons, not model collapse (the new data were real traces, not imagined outputs):
- Too few examples. Eleven programs is far smaller than any setting in the self-training papers, and ReST-EM saw the same overfitting with small training sets.
- Drowned. The new traces joined a corpus built from 61,611 traced programs, in a 3-minute fine-tune.
- A metric that can’t move. “Exact match out of 11” is all-or-nothing, so partial gains are invisible.
- The wrong target. It retrained the exact-value model, which search doesn’t need. STaR, ReST-EM and Voyager improve the part that’s searched with.
- No curriculum. The tasks weren’t chosen at the edge of what the agent could do.
Curiosity. In stage 3, curiosity alone explored 73 screens and finished 0 of 5 tasks: novelty without progress. My terminal agent practises the command it’s least sure about, which is the setup that the noisy-TV problem warns about. A command like date or shuf never stops being uncertain. Learning progress is the textbook fix.
Forgetting. A skill stored as a Python file can’t be overwritten by training. Only the learned parts can forget or lose plasticity: the command model, the JEPA encoder, the scorers. Worth a dashboard before the loop repeats many times.
Where RIAI stands
| Ahead of most of the field | Behind the field |
|---|---|
| An explicit, learned model of what commands do, not borrowed LLM knowledge | The agent never edits its own control code; only the tool set grows |
| Code written with no LLM (13 of 13 search coder; 8 of 12 JEPA v2) | One linear history, no archive of variants as in DGM |
| A hidden host check kept apart from the agent’s own check | Exams are hand-written; no self-proposed tasks as in Absolute Zero |
| Equal-budget comparisons against a baseline for every result | No public benchmarks; tasks are one-file transforms of up to 6 blocks |
| Cheap runs on a laptop and a VM, against $7,000 (SICA) to $22,000 (DGM) per run | No distinguishing-input step yet; ambiguity is identified, not handled |
| A JEPA over program states, which no published work seems to have tried | Mined blocks chosen by frequency, with no reuse audit |
The left column is real, but small. The right column is where the next months go.
What I’ll run next
My research report merged the experiments from all four areas and ranked them by value for effort, each with a pass bar set in advance. These are plans and hypotheses, not results.
| # | Experiment | Why | Pass bar |
|---|---|---|---|
| 1 | Distinguishing-input gate. Before keeping a program, collect up to 20 that fit the examples, find the input that splits them most evenly, and resolve it | Fixes the live-test failure; protects every future skill | Right program on at least 18 of 20 ambiguous pairs, with a median of 2 questions or fewer; the live case asks about something like 'a bb a' and returns “most common word”; at least 50% fewer wrong skills kept |
| 2 | Multi-step rollout training for the JEPA: train on 1 to 4-step rollouts, not single steps | Targets open-loop drift directly | Held-out open-loop first-plan accuracy from 39% to at least 60% |
| 3 | Partial grounding. Check the real state only every few steps, or when several predictors disagree | Keep 10 of 12 with fewer real runs | At least 9 of 12 with half the real checks |
| 4 | The compounding curve. Same tasks, same compute: a frozen library against one that grows by compression, with a reuse check | The core “more and more” question, measured | The growing library solves at least 3 more of 20 unseen tasks, and at least 30% of new solutions use a learned block |
| 5 | Flywheel redone, ReST-EM style. More self-solved examples, mixed in rather than drowned, scored by the rank of the right program | Tests whether self-training can work here at all | The correct program’s rank improves on held-out tasks across at least 2 rounds |
| 6 | Train on the 61,611 real VM traces instead of the safe calculator | Removes my hand-written part from grounding | At least 59% next-step pick-out, and at least 1 task outside the calculator’s whitelist solved |
| 7 | Learning-progress curriculum for the terminal agent | Avoids the noisy-TV trap | A faster rise in commands understood per experiment than current practice |
| 8 | Self-proposed tasks, Absolute Zero style, for the JEPA writer | Removes the need for my hand-written exercises | At least 10 of 12 on the fixed exercises |
Two things to track from the start: a forgetting and plasticity dashboard as skills pile up, and label-free checks of the JEPA’s representation (simple probes, and RankMe, a measure of how spread out the vectors are) to see whether they predict planning success.
The one I’ll start with
Experiment 1, the distinguishing-input gate.
Every other experiment makes the agent better at producing or keeping skills. If the gate that admits skills can be fooled, those improvements just produce wrong skills faster, and everything built on them inherits the mistake. The gate protects everything that comes after it.
It also fits the code I have. JEPA v2 already keeps several partial programs per step, and the safe calculator can run candidates on new inputs safely. The plan: keep searching after the first fit, collect up to 20 programs that fit, run them on generated inputs, group them by behaviour, and if there’s more than one group, ask about the input that splits them most evenly, as Ji and colleagues do. In benchmarks, a reference program answers. In live mode, I do.
If it passes, the live test should end differently: a question about 'a bb a', then “most common word”. If it fails, the failure should point at the candidate search or the input generator. Either way, the next note will report it.
Key ideas
- Growing skill libraries don’t automatically help. In 2026 benchmarks, a library helped one strong model and hurt another, and no self-evolution method helped everywhere (authors’ claims).
- The live-test failure is a known problem with a known fix. Programming by example calls it ambiguity; distinguishing inputs (Jha 2010, Ji 2020, SmartLabel 2025) resolve it. Formal verification doesn’t remove it; it moves it into the spec.
- Libraries need a reuse audit. Learned functions were rarely reused in audited systems, and my mined blocks were chosen by frequency, not usefulness.
- The open-loop gap has a likely cause: single-step training, 4-step planning, and a search that exploits prediction errors. Strong latent planners train on rollouts and re-plan after every step, so 10 of 12 in closed loop is the normal regime.
- My trace format very likely matches Meta’s CWM, pending confirmation, and no published JEPA over program states turned up.
- The flywheel probably stalled for ordinary reasons: too few examples, drowned in old data, an all-or-nothing metric, the wrong target, and no curriculum.
- Next: the distinguishing-input gate, because it protects every skill that comes after it.
Sources: Voyager; ASI; SICA; Darwin Gödel Machine and the Sakana DGM blog; AlphaEvolve; Absolute Zero; SkillFlow; SkillLearnBench; EvoAgentBench; DreamCoder; Stitch; LILO; ReGAL; Library Learning Doesn’t and its follow-up; Jha et al., ICSE 2010; Ji et al., PLDI 2020; SmartLabel; Padhi et al.; Vericoding; Learning to Execute; CWM; Debugging CWMs; LLM-JEPA; MuZero; TD-MPC2; V-JEPA 2; Loss of plasticity; Sparse memory fine-tuning; RND; Go-Explore; OMNI; OMNI-EPIC; ReST-EM; Model collapse.
Related: Watching JEPA Write Code Live, Next: Teaching an Agent to Imagine Code With JEPA, and Writing Its Own Code.
