What a self-evolving learning platform actually is

A self-evolving learning platform is software that contains loops: code that reads what the product records (what children answered, what kids and parents said, what broke, how each model scored) and changes the product in response. The honest question is not whether a product has such loops but what each one may touch and who can stop it. Peabody (peabody.kids) runs four of these loops today, and every one ends at a test suite, a flag the founder owns, or an issue a human reads, never at a child. It is free through the end of 2026.

This post gives the plain definition, lists exactly what Peabody has built, looks at what the research says about software that writes its own changes, and sets out two things a self-evolving platform must never do when its users are five years old.

The honest definition

Every product changes. A self-evolving one is different in one way: some of the change is produced by the product itself. A loop reads a signal the product recorded and alters something, without a person writing the change by hand.

That description covers a lot of ground, from a sort order that updates itself to a system that rewrites its own code. So three questions matter more than the label:

• What does the loop read? (Taps, answers, feedback, test results, model evaluations.)
• What may it change? (A menu order, a flag, a line of code, what a child is asked next.)
• Who can stop it, and how fast?

The marketing version of the phrase, "the app learns from every child and gets smarter every day," answers none of the three. A product that claims it should be able to list its loops. Here is Peabody's list.

What Peabody has today

Tell Peabody. From any page, a kid, a parent or the founder can tap or type an idea, a bug, "I like this" or "confusing". Contact details are screened out before anything is stored, and a kid hears back.

The Workshop. A planned issue becomes a pull request built by a coding agent in a fresh worktree on Aaron's Mac. The change runs typecheck and the lane's tests, is checked against protected paths (the safety code, the prompts, the learning invariants), is read by a tough reviewer, gets one fix round, and then becomes a pull request. Only Aaron merges. Today only bugs and tweaks build on their own; a feature request gets a plan, not code.

The learning invariants. A test suite fences every game: it must ask the practice brain for its questions; every answer is three boxes; Just play is the only question-free mode; a question answered right is never asked again (the constant is 1); 80% of a rung must be solid to pass it; review intervals must increase; ladders run in grade order; and simulated children never get an empty deck. Editing the suite needs the founder's own label on the change.

The model gateway. Every AI call goes through one gateway, is budgeted per child (a day is capped at 40 non-safety calls; a story is about seven calls and costs 1.5 to 2.5 cents) and is logged. Anthropic's models hold the slots today. Eleven open models are registered at rank 0, and any of them can earn a slot only by passing the same safety evaluations, with the rank recorded in a dated measurement file.

The popularity sort. Games are ranked by how much kids actually play them. Unpopular ones go to a Trash tab, and there is no thumbs-down. Twenty home layouts and backdrops rotate, and kids can give each a thumbs up.

Two rules sit over all of it. A loop may act only by flipping a flag Aaron owns or by filing an issue that re-enters the front door. And no loop ranks children or rewards them at random. The practice brain that chooses a child's next question is ordinary code with published constants: AI writes the stories; code decides the rest.

What the research says about software that writes its own changes

The question "can an agent be trusted to change a product" now has data, though all of it comes from open-source repositories.

A 2026 study of the AIDev dataset (37,623 pull requests by five coding agents across 2,807 repositories, December 2024 to mid 2025) found merge rates of about 83% for Codex, 54% for Devin, 43% for Copilot, and 59% for Claude Code on a small sample of 459 (arXiv 2609.17598, 2026). Pooled agent code was less likely than human code to contain a security smell. A secondary analysis of the same data put revert rates at 6.1% for Codex and 14.5% for Devin (dev.to, 2026). The honest reading: agent pull requests merge at roughly human rates in open source, and nobody yet knows the long-term maintenance cost.

The clearest description of an agent-first internal loop is OpenAI's 2026 "harness engineering" post: the agent opens a pull request, reviews its own diff, requests reviews from other agents, responds to human feedback, and background agents open small refactoring pull requests that are reviewable in under a minute (OpenAI, 2026). GitHub's Copilot coding agent turns an assigned issue into a draft pull request worked on in the background (GitHub, 2025).

What the literature does not contain is a documented case of a product that turns end-user feedback into agent-written pull requests. Peabody's Tell Peabody to Workshop loop is ahead of what has been published, which is a reason to write its rules down carefully rather than a reason to boast.

The guardrails the sources support

The ACL paper matters more than it looks. Prompted language-model "students" do a poor job of behaving like real learners across linguistic, behavioral and cognitive measures, so a self-evolving platform that tests its changes on an LLM pretending to be a first grader is testing against a mirror. Peabody's simulated children are rule-driven (a perfect kindergartner, a kindergartner at 60%, a second grader at 85%) and they check invariants, not learning gains.

The Goodhart risk

The biggest danger in a self-evolving platform is not a bad pull request. It is a loop pointed at the wrong number.

Hanus and Fox (Computers & Education, 2015) compared two otherwise identical college courses, one with mandatory badges and a leaderboard. The gamified course produced lower intrinsic motivation, lower satisfaction and lower final exam scores, with the drop in motivation doing the damage (PDF). The formal literature on Goodhart's law in reinforcement learning says why: as pressure on a proxy rises, the proxy and the real goal come apart (arXiv 2310.09144, 2023). Doroudi, Aleven and Brunskill's 2019 review of reinforcement learning for instructional sequencing (41 studies) found it worked best when constrained by ideas from the learning sciences, and recommended offline analyses that do not depend on a single model (IJAIED, 2019).

Engagement is the proxy that wins by default, because it is the easiest thing to measure. Duolingo's published bandit, for example, chooses reminder templates and raised daily active users by 0.5% and new-user retention by 2% (Yancey and Settles, KDD 2020). That is a reasonable thing to optimize for adults learning French. It is the wrong thing to optimize for a six-year-old.

So the rule, in plain words: no loop may optimize session time, streaks or points. The reward for any loop that touches learning must be a learning outcome, such as whether a fact is still known a day later, whether a skill transfers to a question that looks different, or whether a rung is passed within a sensible number of tries.

Where does Peabody's play-time ranking sit against that rule? It reads play time, and it changes one thing: the order of a menu. It does not touch the practice brain, the ladder, the review schedule or what any child is asked. That is the line, and it is the kind of line a parent should be able to find in any product that calls itself self-evolving.

What "self-evolving" must never mean for kids

Two things.

No experiments on children without tiers. In 2018 Pearson tested growth-mindset messages on more than 9,000 students at 165 institutions without consent; the results were mixed and the backlash was public (EdWeek, 2018). Khan Academy's current framework is the best public template: experiments limited to US users aged 13 and older, easy for adults to opt out of, designed not to disrupt a classroom, randomized at the group level when needed; invisible changes run freely, visible changes are checked, higher-risk tests need sign-off; and every test carries guardrail metrics such as "giving away the answer" (GrowthBook case study, 2025). Peabody runs no randomized experiments on children today. If it ever does, those tiers are the floor.

No engagement-maximizing loops. A loop that learns what keeps a child tapping will find it, and the finding will not be reading. Bastani and colleagues' field experiment with about 1,000 high-school students (2024) is the warning from the other direction: a change that looked helpful, free access to GPT-4 during practice, lifted practice grades and then left students 17% worse on the unassisted exam than peers who never had it; a hint-only version mostly removed the harm (Bastani et al., 2024). Helpful-looking and good for learning are not the same thing, and only a learning measure can tell them apart. There is more on what that means for safety in is AI safe for kids' learning.

What this doesn't show

Peabody has not been tested in a trial, and nothing here is a claim about outcomes. The merge-rate data is from open-source projects, not from products used by children. The Workshop's own record is small and private to one repository. The learning invariants check that rules hold; they cannot check that the rules are the right ones. And a loop that only files issues still shapes what gets built next, which is a soft kind of power worth watching.

What a parent can do

Ask any app that calls itself adaptive, self-improving or self-evolving three questions: what does it read, what may it change, who can stop it. A good answer fits on one page. If you want to see how a loop looks from the inside, tap Tell Peabody on any page, or start free and let your child make a story; the rulebook for what happens next is published.

Questions parents ask

Does a self-evolving platform change what my child is taught on its own?

Not in Peabody. The practice brain's rules are fixed code with published numbers, fenced by tests that an automated change cannot edit. The loops that exist change a games menu, a model's rank, or a pull request a human must merge.

Is the AI rewriting Peabody's code?

A coding agent writes proposed changes for bugs and tweaks, in a separate copy of the code, and they become pull requests after tests, protected-path checks and a reviewer. Only the founder merges. Features get a plan, not code.

Why not let the app find what keeps kids playing longest?

Because longest is not the goal. Hanus and Fox (2015) found that engagement machinery can lower motivation and exam results at the same time. Any loop that touches learning in Peabody must be rewarded by a learning outcome, not by time, streaks or points.

Is Peabody free?

Yes, free through the end of 2026, with no ads and no account needed for a child.