Darwin Gödel Machine (DGM)

Zhang, Hu, Lu, Lange and Clune introduced DGM in May 2025; a revised version appeared at ICLR 2026 with public code and experiment logs. The name deliberately contrasts with Schmidhuber's Gödel machine, which requires a formal utility-improvement proof. DGM substitutes benchmark evidence and a branching archive because such proofs are impractical for contemporary coding agents.

Sources: s1, s2, s3, s6

Most agent scaffolds—prompts, tools, editing routines, memory and review steps—are hand designed. DGM turns that scaffold into a search object and preserves multiple evolutionary paths instead of following only the current best version. This makes it a concrete test of whether improvements to an agent's coding ability can also improve its capacity to develop future agent variants. Independent successors already test alternative selection objectives and online evolution.

Sources: s1, s2, s4, s5

A controlled experiment starts with a small coding agent inside an isolated sandbox. The system evaluates it, selects an archived parent, uses a model to propose and implement a scaffold change, then measures the child on held-out repository tasks. A patch-validation tool or better file viewer may survive if the child remains functional. Every version, score and code diff stays in the archive for audit and later branching.

Sources: s2, s3

Benchmark gains can reward overfitting or manipulation of the evaluator instead of robust capability; the paper itself reports a proxy-gaming example. The method executes model-generated code, so isolation, restricted credentials and network access, resource limits, complete lineage and human review are basic experimental safeguards. DGM does not modify its fixed archive controller, does not improve foundation-model weights in the reported experiments, and does not show endless or generally safe self-improvement. Results are conditional on models, tasks, subsets and compute.

Sources: s2, s3, s4, s5