Persistent Recursive Worlds Enable Autonomous Software Evolution

Beichen Huang; Zhenyu Liang; Bowen Zheng; Ran Cheng

Source-linked AI summary

Persistent Recursive Worlds Enable Autonomous Software Evolution

Beichen Huang, Zhenyu Liang, Bowen Zheng, Ran Cheng

arXiv:2608.10450v2Aug 11, 2026cs.SEcs.AIcs.MAcs.NE

TL;DR

Long-horizon software development must remain coherent beyond any individual coding agent, raising what should persist when the active agent does not. Genesis makes the project persistent through accepted versions, repository paths, recursive delegation, and validation-gated acceptance, and reports successful formation, continuation, and redevelopment across compiler and scientific-software tasks.

Problem
Long-horizon software development needs continuity across bounded contributors, but existing systems usually preserve it by extending agent sessions, memory, managers, or shared context.
Method
Genesis represents software as a persistent recursive world in which finite-lived agents work from accepted versions and paths, delegate recursively, and advance history only through accepted consequences.
Results
Genesis formed a 248,989-line C-compiler repository from no implementation, supported continuation after foundation-model replacement, and redeveloped selected MESA modules while preserving audited numerical behaviour.
Takeaways & Limitations
Long-horizon software development can be organized around a persistent project rather than a persistent agent.
Takeaways & Limitations
The MESA result covers a core numerical and physics module chain, not a complete Rust replacement of MESA.

Abstract

from arXiv · show

Complex software systems develop over timescales that exceed the lifespan of any individual coding agent. Most agentic software systems preserve continuity through persistent sessions, memories, managers or shared context. We introduce EvoX Genesis (hereafter, Genesis), which instead makes the software project persistent while allowing local agents to remain finite-lived. Genesis represents software as a persistent recursive world: each local world is situated by an accepted version and a repository path, finite-lived agents propose local changes, recursive delegation moves work across paths, and only accepted consequences advance the persistent version history. We evaluate this organization across formation, continuation and redevelopment. Starting from a repository with no compiler implementation, Genesis used DeepSeek V4 Flash to build a Rust-based C compiler with about 250k tracked lines; the run lasted over 120 hours, archived over 1,000 agent episodes and incurred only US$44 in model-token charges. The compiler passed the complete c-testsuite and most LLVM and Csmith tests. In a separate compiler world generated with GLM 5.2, development continued after repeated agent replacement while retaining full test performance. Genesis also reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace with nearly 90k Rust lines; across six numerical workloads, it achieved median speedups of 1.55--6.87x. These results show that long-horizon software development can be organized around a persistent project rather than a persistent agent.

1 Introduction

Long-horizon software development requires continuity across bounded contributions, but existing agentic approaches usually preserve continuity by extending the agent process. Genesis instead makes the project persistent and evaluates this organization through formation, continuation, and redevelopment.

Software systems outlive individual tasks, so many bounded contributions must remain coherent as contributors change.
Genesis preserves accepted project state and history while finite-lived agents perform bounded tasks, delegate recursively, and terminate.
Genesis evaluates project-centered continuity through formation, continuation after agent replacement, and redevelopment of existing scientific software.
248,989 tracked repository lines demonstrate large-scale greenfield formation from a repository with no compiler implementation.
Genesis also supports continuation across foundation-model replacement and scoped Fortran-to-Rust redevelopment while preserving audited numerical behaviour.

2 Related Work

Related work extends software agents through repository-level evaluation, memory, coordination, versioning, and evaluator-guided program evolution. Genesis differs by making accepted project state and history, rather than agent execution state, the persistent object.

Repository-agent benchmarks now span issue resolution, releases, upgrades, sequences of changes, and greenfield repository construction.
Existing systems preserve continuity through reflection, memory, reusable skills, multi-agent coordination, persistent guidance, and execution-state records.
Genesis treats accepted project state and history as persistent while keeping agent execution state bounded to individual episodes.
Version history and modular decomposition motivate preserving accepted change as long-lived software evolves.
Evaluator-guided systems improve generated program variants through repeated evaluation, whereas Genesis focuses on persistent project organization across episodes.
Scientific redevelopment requires preserving behaviour relevant to use despite environmental and implementation changes, making verification central.

3 EvoX Genesis: Persistent Recursive Worlds

Genesis models software development as persistent recursive worlds: agents work from an accepted version and repository path, delegate locally, and propose changes without persistence until acceptance. Only validated accepted consequences advance the project history.

A local software world is defined by an accepted version and repository-relative path that determine inherited project state and local responsibility.
Transient agency: Finite-lived agents receive episode objectives, produce candidate changes, and are re-instantiated later from accepted versions and paths rather than persistent private state.
Recursive delegation: Recursive delegation starts child work at a more specific path while keeping the accepted version fixed, thereby localizing work without advancing project history.
Accepted software events: Only an accepted software event advances the accepted version; rejected changes leave it unchanged.
The implementation persists project-specific state through version-controlled context, Git commits, archive references, branches, and worktrees, while scheduler and temporary execution state remain infrastructure.

4 Evaluation

Genesis was evaluated through formation, continuation across agent and model replacement, and redevelopment of scientific software. Across these settings, bounded episodes accumulated into large systems while preserving reported tests or numerical behaviour.

Formation: Formation produced a 248,989-line compiler repository from an implementation-empty starting point after 123.4 h and 1,019 archived episodes.The process reached delegation depth five and used recursive accumulation rather than monolithic generation.
Formation: The compiler passed 220/220 c-testsuite cases, 32/36 evaluated LLVM cases, 93/93 executed Csmith programs, recorded LZ4 and SQLite checks, and 2,904 Rust workspace tests.The evaluations are reported separately because their meanings and denominators differ.
Continuation: GLM 5.2 and DeepSeek V4 Flash continued the same completed compiler world after agent replacement, passing 1,445/1,448 and 1,820/1,820 cases in their respective retained LLVM sets.The retained LLVM sets differed, so the pass rates are not a head-to-head comparison on one fixed test set.
Continuation: The continuation branches resumed from a shared completed compiler but diverged in agent counts, delegation depth, commit history, code churn, and final repository size.The inherited project supplied obligations without prescribing one future trajectory.
Redevelopment: The MESA redevelopment reimplemented 13 mapped module directories as Rust crates, covering 139,414 physical Fortran lines while excluding higher-level engines such as star, astero, and binary.Validation used six standalone workloads with median runtimes measured over 25 post-warm-up runs per implementation.
Redevelopment: The Rust workspace contained 89,946 physical lines, passed 1,052 tests with no failures, and achieved lower median runtime in all six audited workloads, with speedups from 1.55× to 6.87×.The timing comparison is specific to the reported builds, host, and benchmark harness.

5 Discussion

Genesis places continuity in the accepted project rather than in a persistent agent, separating finite-lived reasoning from persistent software history. The experiments support formation, continuation, and redevelopment, but do not isolate which mechanisms are necessary.

Project-centered continuity: Genesis persists code, path-specific context, constraints, validation results, and history while local agents terminate and are repeatedly instantiated.The accepted project, rather than an auxiliary memory attached to an agent, is the persistent object.
Project-centered continuity: Persistence and agency remain separate: the accepted version specifies what exists, repository paths situate responsibility, and parent-mediated acceptance determines inherited history.The software world has no persistent private intention, conversation, or cognitive identity.
Evidence: Across formation, continuation, and redevelopment, the reported observations show that development-process lifetime can exceed the lifetime of the agents acting within it.The three settings respectively accumulated a compiler, continued one after replacement, and preserved audited numerical behaviour during redevelopment.
Project-centered continuity: Starting from the same completed compiler, different models produced different routes forward while sharing the same past and obligations.The continuation results therefore show persistence constraining inheritance without fixing the next state.
Evidence and causal boundaries: The experiments do not provide a complete causal decomposition of the mechanism or establish that recursive delegation is superior to flat or alternative organizations.They also do not determine which persistent records are necessary for continuity.
Evidence and causal boundaries: Controlled comparisons of persistent records, agent persistence, organization, acceptance, and validation are needed before treating every component as necessary.Until then, the results support capability under the reported organization rather than component-wise necessity.
Scope of software evolution: In this paper, software evolution means a software system’s formation, inheritance, and change through accepted version history, not biological evolution or model-parameter learning.Variation arises from local candidate changes, while persistence comes from accepted project history.
Scope of software evolution: Autonomy is bounded by human-provided objectives, tools, validation sources, and controller limits.Genesis continues development within those conditions rather than without external goals or infrastructure.

6 Conclusion

Genesis organizes long-horizon software development around a persistent recursive project rather than a persistent agent. Reported runs formed a compiler, continued one across model replacement, and redeveloped MESA modules while preserving audited numerical behaviour.

Conclusion: Genesis makes accepted project state persistent while finite-lived agents propose changes, delegate recursively, and advance version history only through accepted consequences.The paper identifies determining which persistent records and recursive mechanisms are necessary as the next step.
Conclusion: The reported organization supported formation, continuation after foundation-model replacement, and redevelopment of selected MESA modules with preserved audited numerical behaviour.These findings motivate a broader hypothesis about carrying development across changing episodes of intelligence.

7 Formal Definition of Persistent Recursive Worlds

Persistent recursive worlds separate persistent project state from finite-lived agent computation. The model situates local work by an accepted version and repository path, with recursive delegation changing work location while accepted events alone advance project history.

7.1 Minimal model: The minimal model represents a local world with an accepted software version, repository-relative path, finite-lived agent computation and accepted software events.Recursive organization, context, constraints, validation results, skills and provenance are stored in the accepted version.
7.2 Local software worlds: A local world (v, p) fixes the complete accepted project through v while p determines where an agent starts and which context, responsibility and scope apply.The path is not a partial repository copy or separate software state.
7.3 Finite-lived agents: A finite-lived agent may retain private execution state during an episode, while managers delegate and judge work and leaf executors directly modify software.Private execution state is not part of accepted version history.
7.4 Accepted changes: A candidate changes the accepted project only through an accepted event that advances v to v′, with explicit path mapping required for moves, renames or deletions.Parents use scope checks, tests, integration results and, when needed, scientific checks to decide acceptance.
7.4 Accepted changes: Rejected candidates do not advance the accepted version, although saved failure reasons may themselves become separate accepted events.This distinguishes rejected code from persistent records about its failure.
7.5 Recursive delegation: Recursive delegation moves work from path p to child path q within the same version and does not automatically accept the child’s changes.The parent must accept the returned result before the version advances.
7.6 Persistent recursive worlds: Persistence combines accepted version history with recursive work across paths, so later agents inherit the accepted project, history and saved operational records rather than private conversations.Reopening, pruning and regrowth are accepted changes, whereas delegation alone does not change the version.
7.8 Scope of the model: The model concerns software development carried by accepted versions, not reproducing-agent populations or foundation-model parameter learning.What accumulates is project history plus context and constraints available to later work.

8 Evidence and Measurement Conventions

The evidence package separates experiments, repository versions and measurement conventions so that reported counts and validations retain their intended scope.

Evidence packages: The Supplementary Information organizes evidence into compiler formation, compiler continuation and MESA-to-Rust migration packages.These packages contain task instructions, archived summaries, repository versions and supporting tables, figures or source data.
Repository versions: Git commit IDs identify reported repository versions but not non-Git logs or validation reports byte for byte.Repository identity therefore does not imply exact replayability of every associated record.
Repository versions: Both continuation runs start from the GLM-generated compiler at commit 37216cfa254a, not from the separate DeepSeek formation compiler.This distinction prevents treating the formation repository as the continuation baseline.
Measurement conventions: Measurement conventions distinguish archived episodes, wall time, agent-hours, retained commits, physical repository lines, token accounting and validation families.Archived organization statistics may exclude missing-parent records, and retention indicates integration rather than independent correctness.

9 Formation: A C Compiler from Scratch

Genesis formed a Rust C compiler from an implementation-empty repository through recursive, multi-episode development. The resulting repository was large and externally tested, while the authors bound claims by the task specification and measurement conventions.

9.1 Evidence source: The formation evidence is drawn from a DeepSeek run separate from the older GLM 5.2 compiler history.Repository growth was recomputed from the final Git repository, while validation came from final results and committed test-harness documentation.
9.2 Task and initial specification: The task requested an independent Rust C compiler for LLVM-oriented workflows with Clang-compatible invocation, object and linker integration, LLVM IR export and external evaluation.The compiler used a custom typed CIR rather than LLVM IR.
9.3 Initial repository and run phases: The first root session began with only .gitignore and genesis.toml, and a second root phase continued from the first phase’s generated repository and handoff summary.The two root sessions were sequential phases of one run, not independent repeats.
9.4 Human-provided information: Human input specified language, organization, interfaces, targets and tests, but did not provide compiler code or concrete module implementations.The experiment therefore tests automated implementation under a detailed specification rather than architecture-free formation.
9.5 Evaluation targets: C11 and selected C23 extensions were targeted, but the recorded tests do not prove complete C11 conformance.LLVM is a toolchain and test source here, not a C-language standard, and external validation families were reported separately.
9.7 Run configuration and archive structure: 1,019 archived episodes and 1,015 records in the reconstructed parent–child tree describe different archive scopes from the 1,065 spawned-agent count.Four archived records had missing parent IDs, and run totals, Git history, line counts and tests are reported separately.
9.8.1 Resource use and repository size: 248,989 physical lines across 750 tracked text files included 219,676 Rust lines in 354 source files, measuring repository size rather than compiler implementation size or quality.Counts include comments, blank lines, documentation, tests and validation material, with no tracked binary files.

10 Continuity: Development Across Foundation-Model Replacement

Continuation tested whether a completed compiler could remain workable after repeated agent replacement and foundation-model change. Both observed branches advanced the inherited world, but their results are not equal-resource or fixed-test-set comparisons.

10.1 Starting point and setup: The continuation study used a separate compiler history with initial GLM 5.2 development followed by GLM 5.2 and DeepSeek V4 Flash continuation branches.Both branches started from the same completed GLM compiler and received the same project context, objective, test families and controller limits.
10.2 Evaluation: Both continuations used the same Rust, LLVM SingleSource, c-testsuite, LZ4 and SQLite test families at -O0, but saved LLVM case lists differed between snapshots.Reported fractions therefore apply to each branch’s own saved list rather than one fixed test set.
10.3 Run settings, lineage and results: One completed run was performed for each continuation path, so the results describe these runs rather than a repeatable model effect.Both branches used the same recorded depth, retry, turn and context-compression limits.
10.3 Run settings, lineage and results: DeepSeek finished earlier but used more agents, concurrent episodes, archived agent-hours and tokens, so wall time is not an equal-resource speed comparison.The continuation archive records 97 GLM records and 168 DeepSeek records, with observed depths d4 and d8 respectively.
10.4 Resource use: The two continuation runs cannot be compared as equal-budget efficiency tests because DeepSeek used substantially more total tokens despite high prompt-cache reuse in both runs.Cost efficiency is also not compared because GLM continuation cost was reconstructed while other costs came from archive records.
10.5 Validation caveats: The saved LLVM case lists differed, three GLM non-passing cases lacked available per-case diagnostics, and several validation values were not rerun during supplementary preparation.These conditions constrain interpretation of branch-specific test fractions.
10.6 Interpretation: Both branches extended the same completed GLM compiler world, demonstrating continuation after agent turnover and model replacement in the observed runs.The evidence does not show why continuity was possible, whether non-code records were necessary or which model is better.

11 Redevelopment: MESA from Fortran to Rust

Genesis redeveloped 13 mapped MESA modules from Fortran into Rust while preserving audited numerical behavior. The scoped workspace passed its tests, matched key numerical checks, and showed lower median runtimes across six workloads under the reported setup.

Scope and source size: 13 MESA module directories were mapped one-to-one to Rust crates, covering 139,414 physical Fortran lines and 87,328 mapped Rust lines including crate-local tests.The separate workspace-wide count was 89,946 Rust lines; all counts include comments and blank lines.
Scope and source size: The migration excluded higher-level engines and broader components, so it represents a core numerical and physics module chain rather than a complete Rust replacement for MESA.Excluded areas include star, astero, binary, adipls, stella and gyre engines, among others.
Execution and validation: The migration used concurrent recursive work: archived episodes overlapped by up to 22, while context-path history recorded 34 observed paths and 26 later accepted file updates.The concurrency count measures active assignments, not CPU use, and the context archive does not show which agent read each file or whether updates improved performance.
Execution and validation: The timing results apply only to the reported binaries, host, toolchains, timer choices, and benchmark harness, rather than establishing a general Rust-versus-Fortran speed comparison.The workloads were single-threaded and CPU-bound, and Fortran and Rust used different timing mechanisms for some cases.
Execution and validation: Across six audited numerical workloads, Rust had the lower median runtime in every case, with measured speedups from 1.55× to 6.87×.EOS lookup and Newton solve were bit-exact; relative checksum differences for the other workloads ranged from 5.1 × 10−15 to 3.1 × 10−9.

12 Evidence Boundaries and Audit Notes

The evidence package separates what the experiments demonstrate from unresolved issues and records measurement inconsistencies explicitly. It also states that the present experiments do not isolate the causal contribution of individual persistent records or recursive mechanisms.

Measurement boundaries: The MESA workspace has a one-line physical Rust count discrepancy, but the reported mapped 13-crate comparison consistently uses 87,328 lines.The discrepancy is 89,946 versus 89,945 in independent counting paths and is excluded from the main comparison.
Causal boundaries: The experiments establish observed capabilities under the reported settings but do not isolate the causal contribution of every persistent record or recursive mechanism.A proposed direct test would hold executable code fixed while changing accepted non-code development records.
Causal boundaries: Testing that causal question would require identical executable code with different accepted non-code records, followed by the same task, path, model, tools, evaluator, and resource budget.The study did not run this experiment.