[Paper] DARWIN: Dynamic Agentically Rewriting Self-Improving Network

Source: arXiv - 2602.05848v1

Overview

The paper introduces DARWIN, a self‑improving GPT system that treats language models as “agents” that can rewrite each other’s training code. By borrowing ideas from genetic algorithms, DARWIN lets multiple GPT instances mutate, evaluate, and select the most promising code changes, achieving measurable gains in efficiency and perplexity with only a handful of iterations.

Key Contributions

• Agentic code‑mutation loop: Independent GPT agents generate and apply code edits to one another, mimicking biological mutation.
• Genetic‑algorithm selection: After each mutation round, agents are benchmarked; the top performers seed the next generation.
• Persistent JSON memory: A lightweight, version‑controlled log tracks every code change, reasoning trace, and performance metric, enabling reproducibility and analysis.
• Bidirectional HITL interface: The system can request human‑in‑the‑loop upgrades (e.g., new datasets, script refactoring) and incorporate them automatically.
• Proof‑of‑concept with OpenAI API + nanoGPT: Demonstrates the concept using off‑the‑shelf APIs and a minimal GPT training stack, keeping costs low while still delivering measurable improvements.

Methodology

1. Initialize a population – Several GPT agents are instantiated, each paired with its own copy of the nanoGPT training script.
2. Self‑editing phase – Each agent receives a prompt describing the current training code and its recent performance. It then proposes edits (e.g., hyper‑parameter tweaks, data‑loader changes, optimizer adjustments).
3. Mutation & persistence – Proposed edits are applied to a fresh copy of the code, and the resulting configuration is stored in a JSON “memory” file that records the edit, the rationale, and the previous state.
4. Evaluation phase – The mutated training runs are executed (via the OpenAI API for code generation and local compute for training). Metrics such as Model FLOPS Utilization (MFU) and perplexity are collected.
5. Selection – A genetic‑algorithm style tournament selects the top‑k agents based on a weighted fitness function (MFU + perplexity). These survivors become parents for the next iteration, inheriting their code base.
6. Human‑in‑the‑loop (HITL) loop – When an agent’s reasoning flags a missing resource (e.g., a larger corpus), it can request a human to supply the asset; the system then integrates the upgrade automatically.
7. Iterate – Steps 2‑6 repeat for a fixed number of generations (five in the paper’s experiments).

Results & Findings

• Efficiency boost: Slightly higher MFU indicates the evolved training scripts make better use of available GPU cycles (e.g., tighter data pipelines, reduced idle time).
• Quality improvement: Perplexity reduction shows the model learns a bit more effectively from the same data, likely due to better optimizer settings or curriculum tweaks.
• Rapid convergence: Noticeable gains were achieved in just five mutation‑selection cycles, suggesting the evolutionary loop can quickly discover low‑hanging‑fruit optimizations.

Practical Implications

• Automated ML Ops: DARWIN’s agentic code‑mutation can be integrated into CI/CD pipelines to continuously refine training scripts without manual hyper‑parameter sweeps.
• Cost‑effective scaling: By extracting modest performance gains per iteration, organizations can squeeze more training throughput out of existing hardware, delaying expensive hardware upgrades.
• Self‑servicing data pipelines: The HITL request mechanism lets models flag missing data or better preprocessing steps, turning data engineers into “approval” actors rather than primary implementers.
• Open‑source extensibility: Because the core loop relies on JSON logs and plain‑text prompts, developers can plug in alternative model families (e.g., LLaMA, Falcon) or custom training frameworks with minimal friction.
• Research acceleration: Early‑stage experiments can be run on cheap cloud credits; the evolutionary loop surfaces promising code changes that can later be validated at scale.

Limitations & Future Work

• Small performance margin: The reported improvements, while statistically meaningful, are modest; larger gains may require more sophisticated mutation operators or longer evolutionary runs.
• Reliance on external LLMs: Using the OpenAI API for code generation adds latency and cost, and introduces a dependency on a proprietary model.
• Scalability of evaluation: Each mutation still requires a full training run, which can become prohibitive for larger models or datasets.
• Limited diversity of mutations: The current prompt templates focus on hyper‑parameters and script structure; future work could explore architecture‑level mutations (e.g., layer sizes, attention patterns).
• Robustness of HITL requests: The paper’s demo uses manual interventions; automating safe dataset acquisition and version control remains an open challenge.

DARWIN opens a compelling avenue for “self‑optimizing” AI development pipelines, turning language models into both the designers and testers of their own training code. While still in its infancy, the approach hints at a future where model improvement cycles are largely autonomous, freeing engineers to focus on higher‑level system design.

Authors

• Henry Jiang

Paper Information

• arXiv ID: 2602.05848v1
• Categories: cs.NE, cs.AI, cs.CL
• Published: February 5, 2026
• PDF: Download PDF