Paper deep dive

Persistent Recursive Worlds Enable Autonomous Software Evolution

Beichen Huang, Zhenyu Liang, Bowen Zheng, Ran Cheng

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 90

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%

Last extracted: 8/13/2026, 5:38:14 AM

Summary

The paper introduces EvoX Genesis, a framework for autonomous software evolution that treats software projects as persistent recursive worlds. Unlike systems that rely on persistent agent memory, Genesis allows finite-lived agents to operate within specific repository paths and versions, with continuity maintained through the project's version history and accepted changes. The system was evaluated on three tasks: building a C compiler from scratch (formation), continuing development after agent/model replacement (continuation), and redeveloping MESA modules from Fortran to Rust (redevelopment). Results showed successful compilation, test passing, and significant performance speedups, demonstrating that long-horizon development can be organized around the project rather than the agent.

Entities (9)

EvoX Genesis · software-system · 98%DeepSeek-V4-Flash · ai-model · 95%GLM 5.2 · ai-model · 95%Persistent Recursive World · concept · 92%C Compiler · software-artifact · 90%MESA · software-project · 90%Csmith · test-suite · 85%c-testsuite · test-suite · 85%LLVM · test-suitetoolchain · 85%

Relation Signals (9)

C Compiler → passed → c-testsuite

confidence 95% · The compiler passed the complete c-testsuite

EvoX Genesis → produced → C Compiler

confidence 95% · Genesis used DeepSeek V4 Flash to build a Rust-based C compiler

EvoX Genesis → uses → Persistent Recursive World

confidence 95% · Genesis represents software as a persistent recursive world

C Compiler → passed → Csmith

confidence 90% · The compiler passed ... most ... Csmith tests.

C Compiler → passed → LLVM

confidence 90% · The compiler passed ... most LLVM ... tests

EvoX Genesis → reimplemented → MESA

confidence 90% · Genesis also reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace

MESA → reimplementedas → Rust workspace

confidence 90% · reimplemented 13 MESA modules with over 100k Fortran lines as a Rust workspace

EvoX Genesis → utilizes → GLM 5.2

confidence 90% · In a separate compiler world generated with GLM 5.2

EvoX Genesis → utilizes →

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract: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.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

88,957 characters extracted from source content.

Expand or collapse full text

Persistent Recursive Worlds Enable Autonomous Software Evolution Beichen HuangZhenyu LiangBowen ZhengRan Cheng ∗ Department of Data Science and Artificial Intelligence, The Hong Kong Polytechnic University Hong Kong SAR, China ∗ Correspondence: ran-peter.cheng@polyu.edu.hk Abstract Complex software systems develop over timescales that exceed the lifespan of any individual coding agent. Most agentic software systems preserve continuity through per- sistent sessions, memories, managers or shared context. We introduceEvoX Genesis 1 (hereafter,Genesis), which instead makes the software project persistent while allowing local agents to remain finite-lived.Genesisrepresents software as a persistent recur- sive 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,Genesisused 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.Genesisalso 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.87×. These results show that long-horizon software development can be organized around a persistent project rather than a persistent agent. 1 Introduction Software tasks end; software systems do not. A repository that survives for months or years accumulates interfaces, tests, architectural commitments, partial solutions and failures that constrain what later contributors can do. Long-horizon software development is therefore not simply a longer coding task. It is a continuing process in which many bounded contributions must remain coherent even when the contributor changes. Large language models (LLMs) have made repository-level software development increasingly autonomous. Modern coding agents can inspect code, execute tools, modify files and validate their own changes, and benchmarks now extend from issue resolution to multi-step repository construction and software evolution (Ding et al., 2025; Jimenez et al., 2024; Thai et al., 2025; X. Wang et al., 2025; X. Xu et al., 2026; J. Yang et al., 2024). Yet long-horizon systems still face a continuity problem. A larger context window, persistent memory, a manager agent or a shared scratchpad can keep more information available, but these approaches usually preserve continuity by extending some part of the agent process itself. This raises a more basic question: what must persist when the active agent does not? 1 Project Website: https://genesis.evox.group/ arXiv:2608.10450v2 [cs.SE] 12 Aug 2026 EvoX GenesisPreprint We study an alternative organization in which continuity belongs to the software project. We introduce EvoX Genesis(hereafter,Genesis), a system that represents software as a persistent recursive world. The accepted project state and its history persist; local agents do not. A finite-lived agent enters the project from an accepted version and a repository path, performs a bounded task, proposes a change and terminates. Recursive delegation moves work to more specific paths without immediately changing the accepted version, while validation-gated acceptance determines which consequences become part of the history inherited by later agents. This formulation separates two timescales that are often conflated: the lifetime of an individual coding agent and the lifetime of the software development process. The former can remain bounded while the latter extends across many episodes, contributors and even foundation models. In this sense, Genesisdoes not attempt to make one agent persistent. It makes the project persist and repeatedly re-instantiates agency within it. We evaluate this idea through three stages of software development. Formation asks whether many finite-lived episodes can accumulate into a complex system from an implementation-empty repository. Continuation asks whether an already developed world remains workable after repeated agent replacement and a change of foundation model. Redevelopment asks whether the same organization can transform an existing scientific codebase while preserving tested numerical behaviour. Our contributions are fourfold: •We formulate a persistent recursive world using a minimal version–path model that distin- guishes local agency, recursive delegation and accepted software events. • We implement this formulation inEvoX Genesis, where finite-lived manager and executor agents work in path-scoped contexts and only accepted consequences advance the persistent project history. •We demonstrate large-scale greenfield formation by constructing a C compiler from a repository with no compiler implementation, yielding a 248,989-line repository and broad external test coverage. •We show that the same project-centered organization supports continuation across foundation- model replacement and scoped redevelopment of MESA modules from Fortran to Rust while preserving the audited numerical behaviour. 2 Related Work 2.1 Coding agents and long-horizon software development Repository-level coding agents combine LLMs with file inspection, command execution, editing and test feedback. SWE-bench, SWE-agent and OpenHands established issue-level evaluation and general software-agent platforms (Jimenez et al., 2024; X. Wang et al., 2025; J. Yang et al., 2024). More recent benchmarks extend the horizon to releases, upgrades and sequences of changes (Shastry et al., 2026; Thai et al., 2025; X. Xu et al., 2026), while greenfield benchmarks study repository construction from natural-language specifications (Ding et al., 2025). These settings expose a challenge beyond solving one patch at a time: later work can become harder as interfaces shift, assumptions diverge and technical debt accumulates (Orlanski et al., 2026).Genesisfocuses on how one accepted project remains developable across many such episodes. 2.2 Memory, coordination and persistent project state Agent systems preserve continuity in several ways. Reflection and memory mechanisms retain selected experience, reusable skill libraries preserve procedures, and multi-agent systems maintain coordination through roles and workflows (S. Gao et al., 2026; S. Hong et al., 2024; Shinn et al., 2023; G. Wang et al., 2024). Other approaches store project commitments outside the active conversation or place persistent guidance beside the repository (Gloaguen et al., 2026; Yan et al., 2026). Execution-state systems explicitly record what an agent has observed, changed and attempted (Z. Wang et al., 2026). Genesisdoes not claim that memory, short-lived workers or hierarchical task decomposition are 2 EvoX GenesisPreprint individually new. Its organizing choice is to treat the accepted project state and history as the object that persists, while agent execution state remains episode-bounded. Version history is particularly relevant because software already carries accepted change over time. EvoGit allows independent agents to modify and recombine code versions through a Git graph without centralized coordination, explicit message passing or shared memory (Huang et al., 2025). Classical software-engineering work likewise emphasizes that modular decomposition constrains later change (Parnas, 1972) and that change is intrinsic to long-lived software (Lehman, 1980).Genesis builds on this view but couples accepted version history to recursive, path-situated agent instantiation and parent-mediated acceptance. 2.3 Program evolution and scientific software redevelopment Repeated generation and evaluation can also organize substantial code change. FunSearch evolves programs against explicit evaluators, AlphaEvolve extends evaluator-guided evolution to more complex algorithmic code, and ERA searches empirical scientific software against explicit quality metrics (Ayg ̈un et al., 2026; Novikov et al., 2025; Romera-Paredes et al., 2024). These systems establish that model-generated program variants can be improved through repeated evaluation. Our focus differs: we follow the continuing history of one software project rather than a population or search tree of candidate programs. Scientific software provides a demanding redevelopment setting because reproducibility depends not only on whether new code runs, but on whether behaviour relevant to scientific use survives environmental and implementation change. Research code can be difficult to reproduce outside its original environment (Moreau et al., 2023; Trisovic et al., 2022); explicit versions and reusable software are therefore central to research-software stewardship (Barker et al., 2022). Recent commentary has also warned that weakly verified AI-assisted changes can threaten scientific-software quality (O’Brien, 2025). We use Modules for Experiments in Stellar Astrophysics (MESA) (Paxton et al., 2011) redevelopment as a first test of whether substantial implementation change can preserve audited numerical behaviour. 3 EvoX Genesis: Persistent Recursive Worlds 3.1 Persistent recursive worlds Genesisorganizes development around a persistent accepted project rather than a persistent agent identity. At any point, an agent is situated by two coordinates: an accepted version that determines the project it inherits and a repository-relative path that determines where its local responsibility begins. We call this pair a local software world, 푤 = (푣, 푝),(1) where푣denotes an accepted software version and푝a repository-relative path. The version fixes the complete accepted project state and its inheritable history; the path situates agency within that project. An agent may inspect the complete project represented by푣, but it begins from푝and receives the context, responsibility and modification scope associated with that location. The path is therefore not a partial copy of the repository and not an additional software state. In the implementation, the accepted project can include source files, path-specific context, constraints, validation results, reusable skills and provenance records. 3.2 Transient agency and recursive delegation A finite-lived agent퐴 푖 receives an episode objective푔 푖 in local world(푣, 푝)and produces a candidate change Δ 푖 = 퐴 푖 (푣, 푝),푔 푖 .(2) The agent can execute multiple model–tool turns during one supervised episode, but its private conversation and scratch state are not intentionally carried as the identity of a later agent. Later work is re-instantiated from an accepted version and path. 3 EvoX GenesisPreprint Figure 1. Persistent recursive worlds. a, An accepted software version can be viewed from different repository-relative paths, defining local worlds 푤 = (푣, 푝). The version 푣 fixes the accepted project state and history, while the path 푝 sets where an agent starts and what it is responsible for. Recursive delegation (푣, 푝)⇝ (푣,푞) starts a child agent at path 푞 without changing the accepted version 푣. b, A finite-lived agent receives a local objective and proposes a change. The responsible parent accepts, rejects or requests more work using tests, constraints and integration evidence. The isolated worktree is an execution workspace created from the accepted version; it is not a second software world or a partial repository in the formal model. c, Only an accepted change creates a software event(푣, 푝) → (푣 ′ , 푝 ′ )and advances the accepted version history. A rejected candidate leaves the accepted version unchanged, and the agent’s private execution state ends with the episode. Recursive delegation changes where work is instantiated without immediately changing the accepted version. A parent agent at path 푝 can create a child at path 푞 in the same version, (푣, 푝)⇝ (푣,푞).(3) The child works from푞while푣remains fixed, and may recursively delegate again. Leaf executors directly modify the software; root and intermediate managers decompose objectives, delegate subtasks and review returned results. Thus recursion localizes work within the current accepted project without itself advancing the project history. 3.3 Validation and persistent lineage A candidate change becomes persistent only through an accepted software event, (푣, 푝) −→ (푣 ′ , 푝 ′ ),(4) 4 EvoX GenesisPreprint which advances the accepted project from푣to푣 ′ . Usually푝 ′ = 푝; an accepted rename, move or deletion may instead map the path to푝 ′ . The responsible parent decides whether a returned contribution is accepted, rejected or requires further work using the available tests, constraints and integration evidence. A rejected code change leaves the accepted version unchanged. If useful failure information is explicitly stored in context, tests, constraints or provenance, that stored record can become part of a later accepted version even though the rejected code itself does not. The persistence claim therefore concerns project-specific state rather than every process involved in execution. In the released implementation, directory-scoped nodes assemble context from version- controlledCONTEXT.mdrecords, accepted changes are stored through Git commits and protected archive references, and proposed changes are isolated on agent-specific branches and worktrees. Scheduler state, supervised BEAM processes and temporary worktrees provide execution infrastructure rather than the persistent identity of the project. The experiments below evaluate the capabilities of this organization; they do not audit the erasure of every possible provider-side state or isolate the causal contribution of each persistent record. 4 Evaluation 4.1 Evaluation design We evaluateGenesisalong three increasingly demanding forms of continuity. Formation asks whether bounded local episodes can accumulate into a complex software system from an implementation-empty repository. Continuity asks whether an already developed world remains workable after repeated agent replacement and a change of foundation model. Redevelopment asks whether an existing scientific codebase can be transformed while preserving tested numerical behaviour. Each setting uses the same project-centered organization but a different starting condition and validation target. Humans provide the initial task specification, available tools and controller limits. The compiler task includes substantial behavioural and architectural constraints but no compiler implementation or concrete repository decomposition; the continuation study starts from a completed compiler and a high-level continuation objective; the MESA study supplies the reference software, redevelopment objective, compatibility and validation requirements, and performance goals. The archives record objectives, accepted repository histories, agent records and resource summaries, but not a complete audit log of every human action. We therefore report the observed evidence without treating missing intervention records as proof of zero human involvement. An archived episode is one recorded finite-lived task episode; spawned-agent counts can be larger when some spawned agents are absent from the archive. Retention means that a contribution’s commit lies in the ancestry of the final accepted repository, not that the contribution was independently correct. Wall time is measured from the top-level start to finish and differs from summed agent-hours when episodes overlap. Reported US-dollar amounts are foundation-model token charges only and exclude local hardware, storage, controller overhead, networking and labour. Repository line counts are physical-line counts under experiment-specific rules and describe repository size rather than software complexity or feature completeness. The evidence package contains one DeepSeek compiler-formation run, one GLM continuation, one DeepSeek continuation and one MESA-to-Rust redevelopment run; the study therefore describes capabilities under the recorded settings rather than estimating run-to-run success rates. Full protocol, archive and measurement details are provided in the Supplementary Information. 4.2 Formation: a C compiler from scratch Setup. The first test asks whether a persistent software world can grow into a complex system when there is no implementation to inherit. The run used DeepSeek V4 Flash withxhighreasoning effort and a 150,000-token context-compression threshold. The first root session began from commit 41e087ce90f3, containing only.gitignoreandgenesis.toml; a second root phase inherited the generated repository and a handoff summary. The task requested a clean-room C compiler in Rust for LLVM-centric workflows, including a Clang-compatible command-line interface, standard object-file and linker integration, LLVM IR export, C11 as the primary language target, and mandatory x86 and x86-64 back ends. Direct use or translation of Clang/LLVM source was prohibited. External evaluation sources included c-testsuite, LLVM test programs, LZ4 and SQLite, with Csmith programs 5 EvoX GenesisPreprint a InitializationOptimization Supporting codeFront endIR & optimizationBack end 0 150k 300k Lines of Code 113.8k 249.0k 0 2.2 4.5 Input tokens (B) Cached inputUncached inputCache hit 97.4% 1.03B / US$13.57 4.13B / US$44.38 01.002345.14 Elapsed time (days) b LLVM test suite 0-36 32/36 (88.9%) c-testsuite 0-220 220/220 (100%) Csmith 0-93 executed 93/93 executed (100%) LZ4 0-8 8/8 passed SQLite 0-2 stages compiled + SQL sanity queries passed Rust unit tests 0-3,000 2,904 passed Internal corpus 0-106 106/106 (100%) c InitializationOptimization RetainedOtherUnresolved929/1,015 retained 0 15 30 Active agents peak 28peak 29 0 100 200 Completed episodes 01.002345.14 Elapsed time (days) d Front endIR & optimizationBack end Integration / validationCross-cutting 0255075100 Initialization 0.00-1.00 d 41%26%20%13% 140.0 h Optimization 1.00-5.14 d 35%20%34% 401.3 h Share of Agent time (%) Figure 2. Formation of a C compiler with DeepSeek V4 Flash through recursive development. a, Growth of the jcc codebase and cumulative input-token use against elapsed time; the phase boundary separates initialization from optimization. b, Final validation across LLVM, c-testsuite, Csmith, LZ4, SQLite, Rust workspace tests and the internal compiler corpus. c, Active agents and completed episodes throughout development, with episodes distinguished by whether their contributions were retained in the final accepted repository history. d, Agent time partitioned among front-end, intermediate-representation and optimization, back-end, integration and validation, and cross-cutting work during the two phases. Dollar annotations denote model-token charges only, not total compute, infrastructure or labour cost. generated and executed by the committed harness. The task supplied no compiler implementation code or concrete repository decomposition. Results.Formation proceeded through recursive accumulation rather than one monolithic generation step. Managers divided the root objective across repository paths, finite-lived agents worked on local pieces, and parent agents reviewed returned changes before those changes entered the accepted project. Over 123.4 h, the run archived 1,019 agent episodes and reached delegation depth five. The final repository contained 248,989 physical lines in 750 tracked text files, at a provider-recorded model-token cost of US$44.38. These counts include comments and blank lines and therefore describe repository size rather than software complexity. The resulting compiler passed 220/220 reported c-testsuite cases, 32/36 evaluated LLVM cases and 93/93 executed Csmith programs, together with the recorded LZ4 and SQLite checks and 2,904 Rust workspace tests. Because these evaluations have different meanings and denominators, we report them separately rather than combine them into one score. Interpretation. Compiler construction couples decisions made at different times: choices in the front end constrain type checking, the intermediate representation constrains optimization and code generation, and later integration can expose problems in components that appeared locally complete. No single agent episode spanned this development. Earlier accepted changes instead became the starting point for later agents, while later failures were repaired with the rest of the project in place. The experiment therefore establishes large-scale formation under the stated task contract and makes the accumulation of bounded contributions into one interdependent software system directly observable. 4.3 Continuity: development across foundation-model replacement Setup. The second test asks whether a completed software world can continue after the agents that built it are gone, and whether continuation remains possible when the foundation model itself 6 EvoX GenesisPreprint a 04896136.6142148154160 0 40k 80k 120k 0 1 2 3 Initial development (GLM 5.2)GLM 5.2DeepSeek V4 Flash 117.0k 2.812B 133.2k 3.177B 105.4k 2.265B Lines of code Tokens (B) Elapsed time (h) b Initial dev.GLM 5.2DeepSeek V4 Flash c-testsuite: 220/220 in all stages LLVM SingleSource retained manifests 1558/1870 1445/1448 1820/1820 Rust unit tests workspace count 1136 1226 (+90) 1350 (+214) Project lines physical lines 105.4k 117.0k 133.2k c 04896136.6142148154160 0 5 10 15 20 Initial development (GLM 5.2)GLM 5.2DeepSeek V4 Flash peak 21 peak 9 peak 19 Elapsed time (h) Number of active agents d DeletedAdded GLM 5.2 net +10.0k -6.4k+16.5k DeepSeek V4 Flash net +23.2k -2.8k+25.9k e cached / fresh; cost (USD) Initial dev. (GLM) 2.246B input; $762.59 96.34% cached 3.66% fresh GLM 5.2 cont. 543.6M input; $168.35 est. 98.27% cached 1.73% fresh DeepSeek V4 Flash cont. 902.8M input; $7.49 97.96% cached 2.04% fresh Figure 3. Continuation of the same compiler world with GLM 5.2 and DeepSeek V4 Flash. a, Codebase growth and cumulative token use across initial GLM 5.2 development and the two continuations from the same completed GLM jcc world. b, Compiler validation and project growth for the three recorded snapshots. The retained LLVM SingleSource test sets differ among snapshots, so the fractions are reported within each snapshot rather than compared on one fixed test set. c, Concurrent agent activity across initial development and both continuation runs. d, Lines added and deleted during each continuation relative to the shared starting codebase. e, Cached and fresh input-token fractions and corresponding recorded or reconstructed model-token costs. The costs were obtained differently for the two continuation runs, and the runs did not use matched resources, so no normalized dollar-efficiency comparison is made. changes. This study uses a compiler history separate from the DeepSeek formation run. Both continuation branches start from the same completed jcc repository generated with GLM 5.2 at commit37216cfa254a, receive the same completed project, prior-task context, user-level objective, evaluation families and controller limits, and run on the same dedicated machine. One branch continues with GLM 5.2 and the other switches to DeepSeek V4 Flash. Both use maximum depth eight, retry limit 15, 2,048 root turns, 128 delegated turns and a 150,000-token compression threshold. The retained LLVM test sets differ across snapshots, and the two branches do not use a matched token or wall-clock budget; the experiment is therefore descriptive rather than a controlled model comparison. Results. Both branches resumed development through repeated replacement of finite-lived agents. GLM 5.2 passed 1,445/1,448 cases in its retained LLVM test set, whereas DeepSeek V4 Flash passed 1,820/1,820. GLM used 98 agents and reached observed depth four, while DeepSeek used 178 agents and reached depth eight. The retained LLVM test sets were not identical, so these pass rates describe each completed snapshot rather than a head-to-head comparison on one fixed test set. Even so, both branches advanced the same inherited compiler instead of rebuilding it from the beginning. Interpretation. Model replacement changes the process that proposes local changes, yet both branches resumed from the same completed compiler and then diverged in agent counts, delegation depth, commit history, code churn and final repository size. The inherited world therefore acted as a common starting point and a set of obligations rather than a script that fixed the next state. Persistence constrained what had to be inherited without fixing how the future had to unfold. The significance of this experiment is continuation across model replacement, not a ranking of GLM and DeepSeek. 7 EvoX GenesisPreprint a 0 0.4M 0.8M 1.2M 1.6M 0 200M 400M 600M 800M 08162432.533.2231.72 1.390M 1.391M 764.0M 788.5M Lines of code Cumulative tokens InitializationOptimization Elapsed time (hours) 0-.5.5-11-1.51.5-22-33-55-1010-2020-50>50 Agent groups by total token usage (millions) 92 94 96 98 Mean cache hit rate (%) 92.7% 95.2% 96.4% 97.6% 96.4% 97.2% 96.8% 96.1% 97.0% 96.5% Overall mean 96.0% b c const const utils utils math math mtx mtx auto_diff auto_diff num num interp_1d interp_1d interp_2d interp_2d chem chem eos eos forum forum colors colors rates rates neu neu net net kap kap ionization ionization atm atm turb turb gyre gyre star_data star_data star star astero astero binary binary FOUNDATION PHYSICS STELLAR 40retained102MESA-only1Rust-only 0.010.11 Median runtime (s) End-to-end burn EOS lookup Opacity lookup 2D interpolation ROS2 integration Newton solve FortranRust 1.55× 1.60× 1.98× 1.58× 5.30× 6.87× Speedup 3.1e-9 bit-exact 1.3e-13 4.9e-12 5.1e-15 bit-exact Checksum all <1e-8 d Figure 4. Redevelopment of selected MESA modules in Rust. a, Repository growth and cumulative input-token use during the MESA-to-Rust migration. The plotted repository line count is the size of the generated repository, not the number of MESA source lines migrated. b, Mean prompt-cache hit rates for agent groups defined by total token use. c, Dependencies among the mapped modules, classified as present in both dependency graphs, absent as direct Rust crate dependencies, or newly present in Rust. d, Numerical agreement and median runtime for corresponding Fortran and Rust implementations across six audited workloads. 4.4 Redevelopment: MESA from Fortran to Rust Setup. The third test asks whetherGenesiscan inherit scientific software, change its implemen- tation language and preserve the numerical behaviour that matters. Modules for Experiments in Stellar Astrophysics (MESA) 2 is an open-source suite for one-dimensional stellar-evolution calcula- tions (Paxton et al., 2011). The study used a lightly modified MESA fork at commit461dcba94f33 as a read-only reference and DeepSeek V4 Flash to reimplement 13 mapped module directories as corresponding Rust crates. The reported scope covers basic numerical and physics modules and contains 139,414 physical Fortran lines including module-level tests; higher-level MESA engines such asstar,asteroandbinaryare outside the migration. Numerical validation used six standalone workloads covering end-to-end burn, EOS lookup, opacity lookup, two-dimensional interpolation, ROS2 integration and Newton solve. Each reported runtime is the median of 25 post-warm-up measurements per implementation; full build flags, CPU pinning and the separate 40-run burn check are reported in the Supplementary Information. Results.The run completed the scoped rewrite in 33.22 h, spawned 272 agents and produced a Rust workspace containing 89,946 physical Rust lines including tests and benches. The workspace passed 1,052 tests with no failures and 18 ignored tests, at a provider-recorded model-token cost of US$10.64. Across the six audited numerical workloads, EOS lookup and Newton solve were bit-exact; relative checksum differences for the other four workloads ranged from5.1× 10 −15 to3.1× 10 −9 . Rust had 2 MESA source repository: https://github.com/MESAHub/mesa/ 8 EvoX GenesisPreprint the lower median runtime in all six workloads, with measured speedups from 1.55×to 6.87×. The timing comparison is specific to the reported builds, host and benchmark harness. Interpretation. The compiler experiment began with no implementation, whereas the MESA experiment began with a mature system whose numerical behaviour already had meaning. The task was therefore not simply to produce Rust code: implementation could change, but the tested numerical relationships carried by the original software had to survive. The resulting workspace differs substantially from the Fortran source in size and dependency structure, yet the audited workloads remained numerically aligned. This movesGenesisfrom constructing a new software world to redeveloping an existing one while preserving the tested behaviour that gave the original code its scientific value. 5 Discussion 5.1 Project-centered continuity The central design choice inGenesisis where continuity resides. Many long-horizon agent systems extend an agent process through longer context, explicit memory, a persistent manager or shared state.Genesisinstead makes the accepted project the persistent object. Code, path-specific context, constraints, validation results and history remain available to later work, while local agents can terminate. The software world is therefore not an auxiliary memory attached to a long-lived agent; it is the project state from which successive agents are instantiated. This interpretation does not make the software world itself an agent. The world has no persistent private intention, conversation or cognitive identity. Reasoning remains in finite-lived agents. The accepted version specifies what exists, the path situates local responsibility, and parent-mediated acceptance determines which consequences become part of the history inherited by later work. Persistence and agency are therefore separated rather than transferred from one subject to another. The three experiments cover formation, continuity and redevelopment. In the compiler-formation run, more than a thousand finite-lived episodes accumulated into one interdependent software system. In the continuation study, a completed compiler remained developable after repeated agent replacement and a foundation-model change. In the MESA study, the same project-centered organization supported substantial scientific-software redevelopment while preserving the audited numerical behaviour. Together, these observations show that, under the reported settings, the lifetime of the development process can exceed the lifetime of the agents acting within it. The continuation experiment further shows that persistence does not prescribe a single future. Starting from the same completed compiler, GLM 5.2 and DeepSeek V4 Flash produced different delegation depths, agent counts, commit histories, code churn and final repository sizes while both continued development. The accepted project supplied a shared past and a common set of obligations, but different models took different routes forward. Likewise, the MESA experiment raises a stronger standard for inheritance: a scientific successor is useful only if externally meaningful behaviour survives implementation change. 5.2 Evidence and causal boundaries The present experiments establish capability across three distinct regimes, but they do not yet provide a complete causal decomposition of the mechanism. Recursion was operationally central in all reported runs, reaching observed depths of five in compiler formation, four and eight in the two continuation branches, and four in MESA redevelopment. These observations show that recursive delegation was extensively used, but they do not establish that recursion is causally superior to flat or alternative organizations. Similarly, the continuation results show that development can proceed across agent and foundation-model replacement, but they do not by themselves determine which persistent records are necessary for that continuity. The clearest next experiments therefore concern mechanism causality. One test holds executable code fixed while changing accepted non-code development records, asking whether future construction changes under the same model, task and budget. A second compares fresh agents with persistent agents while holding the saved project state fixed. Together with flat-organization, hierarchical-acceptance 9 EvoX GenesisPreprint and validation ablations, these experiments can determine which components of the persistent recursive world are necessary for the observed long-horizon capabilities. Until such controlled comparisons are available, the present results should be read as evidence that the reported organization supports formation, continuity and redevelopment, rather than as proof that every component is individually necessary. 5.3 Scope of software evolution Our use of software evolution is practical rather than biological. It denotes the trajectory through which a software system forms, inherits earlier structure and changes through accepted version history. Agents do not reproduce, and the present study does not claim Darwinian evolution, open-ended self-modification or learning of the foundation-model parameters. Instead, variation arises from local candidate changes, persistence from accepted project history, and continued development from repeated re-instantiation of finite-lived agency within that history. Likewise, autonomous is bounded rather than absolute. Humans provide the initial objectives, available tools, validation sources and controller limits; within those conditions,Genesisdecomposes work, instantiates local agents, executes development actions and determines which validated consequences enter the persistent project. The claim is therefore not that software develops without external goals or infrastructure, but that a long-horizon development process can continue without requiring a persistent intelligent agent to carry its identity or history. 6 Conclusion EvoX Genesis reorganizes long-horizon software development around a persistent recursive project rather than a persistent agent. A local world is situated by an accepted version and a repository path; finite-lived agents propose changes; recursive delegation moves work across paths; and accepted consequences advance the version history inherited by later agents. Under this organization, the reported runs formed a large C compiler from an implementation-empty repository, continued an existing compiler after foundation-model replacement and redeveloped selected MESA modules in Rust while preserving the audited numerical behaviour. These results motivate a broader hypothesis: persistent project state can carry software development across changing episodes of intelligence. Determining exactly which persistent records and recursive mechanisms are necessary is the next step. References Ayg ̈un, E., Belyaeva, A., Comanici, G., Coram, M., Cui, H., et al. (2026). “An AI system to help scientists write expert-level empirical software”. In: Nature 654, p. 909–916. doi:10.1038/s41 586-026-10658-6. Barker, M., Hong, N. P. C., Katz, D. S., Lamprecht, A.-L., Martinez-Ortiz, C., et al. (2022). “Introducing the FAIR Principles for research software”. In: Scientific Data 9, p. 622. doi: 10.1038/s41597-022-01710-x. Ding, J., Long, S., Pu, C., et al. (2025). “NL2Repo-Bench: Towards Long-Horizon Repository Generation Evaluation of Coding Agents”. In: arXiv preprint arXiv:2512.12730. doi:10.48550/a rXiv.2512.12730. arXiv: 2512.12730 [cs.CL]. Gao, S., Zeng, W., Yu, Z., Wangni, J., Wang, C., Cai, K., He, S., and Lyu, M. R. (2026). “SWE-MeM: Learning Adaptive Memory Management for Long-Horizon Coding Agents”. In: arXiv preprint arXiv:2606.28434. doi: 10.48550/arXiv.2606.28434. Gloaguen, T., M ̈undler, N., M ̈uller, M., Raychev, V., and Vechev, M. (2026). “Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?” In: arXiv preprint arXiv:2602.11988. doi: 10.48550/arXiv.2602.11988. Hong, S., Zhuge, M., Chen, J., Zheng, X., Cheng, Y., Wang, J., Zhang, C., Wang, Z., Yau, S. K. S., Lin, Z., Zhou, L., Ran, C., Xiao, L., Wu, C., and Schmidhuber, J. (2024). “MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework”. In: International Conference on Learning Representations. Huang, B., Cheng, R., and Tan, K. C. (2025). “EvoGit: Decentralized Code Evolution via Git-Based Multi-Agent Collaboration”. In: arXiv preprint arXiv:2506.02049. doi:10.48550/arXiv.2506 .02049. arXiv: 2506.02049 [cs.SE]. 10 EvoX GenesisPreprint Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., and Narasimhan, K. (2024). “SWE- bench: Can Language Models Resolve Real-World GitHub Issues?” In: International Conference on Learning Representations. Lehman, M. M. (1980). “Programs, Life Cycles, and Laws of Software Evolution”. In: Proceedings of the IEEE 68.9, p. 1060–1076. doi: 10.1109/PROC.1980.11805. Moreau, D., Wiebels, K., and Boettiger, C. (2023). “Containers for computational reproducibility”. In: Nature Reviews Methods Primers 3, p. 50. doi: 10.1038/s43586-023-00236-9. Novikov, A., V ̃u, N., Eisenberger, M., et al. (2025). “AlphaEvolve: A coding agent for scientific and algorithmic discovery”. In: arXiv preprint arXiv:2506.13131. doi:10.48550/arXiv.2506.13131. arXiv: 2506.13131 [cs.AI]. O’Brien, G. (2025). “Threats to scientific software from over-reliance on AI code assistants”. In: Nature Computational Science 5, p. 701–703. doi: 10.1038/s43588-025-00845-2. Orlanski, G., Roy, D., Yun, A., Shin, C., Gu, A., Ge, A., Adila, D., Roberts, N., Sala, F., and Albarghouthi, A. (2026). “SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks”. In: arXiv preprint arXiv:2603.24755. Version 2. doi:10.48550/a rXiv.2603.24755. Parnas, D. L. (1972). “On the criteria to be used in decomposing systems into modules”. In: Communications of the ACM 15.12, p. 1053–1058. doi: 10.1145/361598.361623. Paxton, B., Bildsten, L., Dotter, A., Herwig, F., Lesaffre, P., and Timmes, F. (2011). “Modules for Experiments in Stellar Astrophysics (MESA)”. In: The Astrophysical Journal Supplement Series 192.1, p. 3. doi: 10.1088/0067-0049/192/1/3. arXiv: 1009.1622 [astro-ph.SR]. Romera-Paredes, B., Barekatain, M., Novikov, A., et al. (2024). “Mathematical discoveries from program search with large language models”. In: Nature 625, p. 468–475. doi:10.1038/s41586 -023-06924-6. Shastry, K. N. A., Senrayan, G., Satapara, S., Panda, P., and Devaguptapu, C. (2026). “Beyond Isolated Tasks: A Framework for Evaluating Coding Agents on Sequential Software Evolution”. In: arXiv preprint arXiv:2604.03035. doi: 10.48550/arXiv.2604.03035. Shinn, N., Cassano, F., Gopinath, A., Narasimhan, K., and Yao, S. (2023). “Reflexion: Language Agents with Verbal Reinforcement Learning”. In: Advances in Neural Information Processing Systems. Vol. 36. Thai, M. V. T., Le, T., Manh, D. N., Nhat, H. P., and Bui, N. D. Q. (2025). “SWE-EVO: Bench- marking Coding Agents in Long-Horizon Software Evolution Scenarios”. In: arXiv preprint arXiv:2512.18470. doi: 10.48550/arXiv.2512.18470. Trisovic, A., Lau, M. K., Pasquier, T., and Crosas, M. (2022). “A large-scale study on research code quality and execution”. In: Scientific Data 9, p. 60. doi: 10.1038/s41597-022-01143-6. Wang, G., Xie, Y., Jiang, Y., Mandlekar, A., Xiao, C., Zhu, Y., Fan, L., and Anandkumar, A. (2024). “Voyager: An Open-Ended Embodied Agent with Large Language Models”. In: Transactions on Machine Learning Research. url: https://openreview.net/forum?id=ehfRiF0R3a. Wang, X., Li, B., Song, Y., Xu, F. F., Tang, X., Zhuge, M., et al. (2025). “OpenHands: An Open Platform for AI Software Developers as Generalist Agents”. In: International Conference on Learning Representations. Wang, Z., Xu, Y., Li, C., Peng, C., Adams, B., Hassan, A. E., and Chen, T.-H. (2026). “Turning Interaction History into Execution State: A Runtime Layer for Long-Horizon Coding Agents”. In: arXiv preprint arXiv:2608.00808. doi:10.48550/arXiv.2608.00808. arXiv:2608.00808 [cs.SE]. Xu, X., Yang, R., Shen, H., Xu, W., Gao, B., Wu, R., et al. (2026). “RoadmapBench: Evaluating Long-Horizon Agentic Software Development Across Version Upgrades”. In: arXiv preprint arXiv:2605.15846. doi: 10.48550/arXiv.2605.15846. Yan, L., Chen, X., and Zhang, X. (2026). “When the Specification Emerges: Benchmarking Faithfulness Loss in Long-Horizon Coding Agents”. In: arXiv preprint arXiv:2603.17104. doi:10.48550/ar Xiv.2603.17104. Yang, J., Jimenez, C. E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., and Press, O. (2024). “SWE- agent: Agent–Computer Interfaces Enable Automated Software Engineering”. In: Advances in Neural Information Processing Systems. Vol. 37, p. 50528–50652. doi:10.52202/079017-1601. 11 Persistent Recursive Worlds Enable Autonomous Software Evolution Beichen HuangZhenyu LiangBowen ZhengRan Cheng ∗ Department of Data Science and Artificial Intelligence, The Hong Kong Polytechnic University Hong Kong SAR, China ∗ Correspondence: ran-peter.cheng@polyu.edu.hk Contents 1 Introduction1 2 Related Work2 2.1Coding agents and long-horizon software development . . . . . . . . . . . . . . .2 2.2Memory, coordination and persistent project state . . . . . . . . . . . . . . . . . .2 2.3Program evolution and scientific software redevelopment . . . . . . . . . . . . . .3 3 EvoX Genesis: Persistent Recursive Worlds3 3.1Persistent recursive worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3 3.2Transient agency and recursive delegation . . . . . . . . . . . . . . . . . . . . . .3 3.3Validation and persistent lineage . . . . . . . . . . . . . . . . . . . . . . . . . . .4 4 Evaluation5 4.1Evaluation design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5 4.2Formation: a C compiler from scratch . . . . . . . . . . . . . . . . . . . . . . . .5 4.3Continuity: development across foundation-model replacement . . . . . . . . . . .6 4.4Redevelopment: MESA from Fortran to Rust . . . . . . . . . . . . . . . . . . . .8 5 Discussion9 5.1Project-centered continuity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9 5.2Evidence and causal boundaries . . . . . . . . . . . . . . . . . . . . . . . . . . .9 5.3Scope of software evolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 6 Conclusion10 7 Formal Definition of Persistent Recursive Worlds14 7.1Minimal model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.2Local software worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.3Finite-lived agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.4Accepted changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 EvoX GenesisPreprint 7.5Recursive delegation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14 7.6Persistent recursive worlds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 7.7Reopening and structural changes . . . . . . . . . . . . . . . . . . . . . . . . . .15 7.8Scope of the model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 8 Evidence and Measurement Conventions15 8.1Evidence sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 8.2Repository versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15 8.3Measurement and accounting conventions . . . . . . . . . . . . . . . . . . . . . .16 9 Formation: A C Compiler from Scratch16 9.1Evidence source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 9.2Task and initial specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 9.3Initial repository and run phases . . . . . . . . . . . . . . . . . . . . . . . . . . .16 9.4Human-provided information . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 9.5Evaluation targets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .16 9.6External validation sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .17 9.7Run configuration and archive structure . . . . . . . . . . . . . . . . . . . . . . .17 9.8Developmental lineage and complete results . . . . . . . . . . . . . . . . . . . . .17 9.8.1Resource use and repository size . . . . . . . . . . . . . . . . . . . . . . .18 9.9Archive completeness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 10 Continuity: Development Across Foundation-Model Replacement20 10.1 Shared starting world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .20 10.2 Evaluation protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21 10.3 Run settings, lineage and results . . . . . . . . . . . . . . . . . . . . . . . . . . .21 10.3.1 Resources, repository growth and validation . . . . . . . . . . . . . . . . .23 11 Redevelopment: MESA from Fortran to Rust25 11.1 Starting system and run settings . . . . . . . . . . . . . . . . . . . . . . . . . . .25 11.2 Migration scope and module mapping . . . . . . . . . . . . . . . . . . . . . . . .25 11.3 Run timeline and concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . .27 11.4 Numerical validation and runtime . . . . . . . . . . . . . . . . . . . . . . . . . .28 11.5 Dependency structure and recursive context . . . . . . . . . . . . . . . . . . . . .29 12 Evidence Boundaries and Audit Notes31 12.1 What each experiment establishes . . . . . . . . . . . . . . . . . . . . . . . . . .31 12.2 Observed failures and missing records . . . . . . . . . . . . . . . . . . . . . . . .31 12.3 Causal tests not performed in this study . . . . . . . . . . . . . . . . . . . . . . .32 13 EvoX GenesisPreprint 7 Formal Definition of Persistent Recursive Worlds 7.1 Minimal model The minimal model uses four objects: an accepted software version푣, a repository-relative path푝, a finite-lived agent computation퐴 푖 and an accepted software event. Recursive organization, Context, constraints, validation results, skills and provenance are stored in the accepted version rather than modeled as separate state variables. 7.2 Local software worlds A local software world is 푤 = (푣, 푝).(5) The accepted version푣fixes the complete project and its saved history. The path푝says where the agent starts and which Context, responsibility and scope apply. An agent may inspect the complete project represented by 푣; 푝 is neither a partial copy of the repository nor a separate software state. A version is an accepted software state, not necessarily a bare Git SHA. In the runtime it can be a validated commit, checkpoint or merge together with the Context, constraints, tests, skills and provenance that later work can inherit. Intermediate worktrees and rejected candidates are not accepted versions. 7.3 Finite-lived agents For an episode-level objective푔 푖 in local world(푣, 푝), a finite-lived agent produces a candidate change Δ 푖 = 퐴 푖 (푣, 푝),푔 푖 .(6) An agent may keep private execution state during its episode. The model uses two roles: managers at root and intermediate nodes decompose objectives, delegate work and judge returned results; leaf executors directly modify the software. Runtime labels such as codebase lead, codebase investigator and task scheduler are implementation labels, not additional roles in the model. Private execution state is not part of the accepted version history. 7.4 Accepted changes A candidate enters the accepted version history only through an accepted event (푣, 푝) −→ (푣 ′ , 푝 ′ ).(7) The event advances the accepted project from푣to푣 ′ . Usually푝 ′ = 푝; a rename, move or deletion can instead require an explicit path mapping. For delegated work, the parent decides whether to accept, reject or request further work using the relevant scope checks, tests, integration results and, where needed, scientific checks. A rejected candidate does not advance the accepted version. If a failure reason is saved in Context, tests, constraints or provenance, that saved record is a separate accepted event; the rejected code itself is not. 7.5 Recursive delegation Recursive delegation changes where the agent works without changing the accepted version: (푣, 푝)⇝ (푣,푞).(8) A parent agent working from푝invokes a child at푞in the same accepted version푣. This does not create a new accepted version or automatically accept the child’s work. Intermediate children may delegate again; leaf executors return direct software changes. The version advances only after the parent accepts a returned result. The two operations differ as follows: 14 EvoX GenesisPreprint OperationVersionWorking path Recursive delegation(푣, 푝)⇝ (푣,푞)unchangedchanges from 푝 to 푞 Accepted event(푣, 푝) → (푣 ′ , 푝 ′ )advances to 푣 ′ remains 푝 or is explicitly mapped 7.6 Persistent recursive worlds A persistent recursive world combines two kinds of continuity: 1.an accepted version history, in which accepted results advance the project from one version to the next; and 2.recursive work across paths, in which new finite-lived agents are started from different paths within the current accepted version. The model does not require private conversation to persist across episodes. Later work starts from an accepted version and path. What persists is the accepted project and its history, together with Context, constraints, validation results, skills and saved failure records. 7.7 Reopening and structural changes The words modify, expand, integrate, close, reopen, prune and regrow describe kinds of accepted changes. They are not additional mathematical objects. Closing or reopening changes the accepted version history; pruning and regrowth can require several accepted events and path mappings; recursive delegation itself does not change the version. Delegating to a child path does not itself change the software. A proposed structural change becomes part of the world only after its result is accepted into a new version. 7.8 Scope of the model The model describes software development carried by accepted versions while individual agent computations are short-lived. It is not a population model of reproducing agents, and it does not say that the foundation model learns new parameters during a run. What accumulates is the accepted project history and the Context and constraints available to later work. 8 Evidence and Measurement Conventions 8.1 Evidence sources The Supplementary Information uses three evidence packages: compiler formation, compiler continuation and MESA-to-Rust migration. They contain the task instructions, archived run summaries, repository versions and the tables, figures or source data used below. 8.2 Repository versions Git commit IDs identify the reported repository versions. They do not identify non-Git logs or validation reports byte for byte. Table S1. Repository commits used in the three experiments. RepositoryVersionCommit ID (SHA-1) jccDeepSeek generated jcca8c116ec7ed3d59479ad3be8fed3e63384f50a87 jccGLM generated jcc37216cfa254a40e40af48cd528743fd7f2d6737c jccGLM generated jcc continued with DeepSeek10077f65686102deef2c228e8a49b0569218ec48 jccGLM generated jcc continued with GLMab58a91460adb24e9349a554e02d4522d3ae2db4 mesa-rsDeepSeek ported mesa2ad071e658f8d4de21a9f0e906592c364e10023 Both continuation runs start from the GLM-generated Task 1 compiler at commit37216cfa254a. The DeepSeek compiler at commita8c116ec7ed3comes from the separate formation study and is not the starting point for continuation. 15 EvoX GenesisPreprint 8.3 Measurement and accounting conventions Unless a subsection states otherwise, the following conventions are used across the evidence package. An episode is one row inarchiverecords. Wall time is the top-level finish time minus the start time. Agent-hours are the sum of archived episode durations, so they exceed wall time when episodes overlap. Parent–child tree statistics exclude records whoseparentidis absent from the archive and any descendants of such records. A record is called retained when its commit is an ancestor of the final repository; this shows integration, not correctness. Physical repository lines count every line in tracked text files, including blank lines, comments and non-Rust files. They measure repository size, not compiler implementation size alone. Token and cost quantities are reported from the available run records and are not normalized across experiments when the underlying accounting differs. Validation families with different denominators or meanings are kept separate rather than collapsed into a single score. 9 Formation: A C Compiler from Scratch 9.1 Evidence source The main run record for compiler formation isdata/archive-deepseek-llvm.json. Repository growth and composition were recomputed from the Git repository at final commita8c116ec7e d3d59479ad3be8fed3e63384f50a87; validation results come from the final root result and the committed test-harness documentation. This DeepSeek run is separate from the older GLM 5.2 compiler used in Section 10. 9.2 Task and initial specification The compiler experiment was oneGenesisrun from 2 August to 7 August 2026 (UTC) using DeepSeek V4 Flash. The task asked for an independent C compiler written in Rust for LLVM-oriented toolchains and tests. It required a Clang-compatible command-line interface, standard object-file and linker integration, LLVM IR export and evaluation with the LLVM test suite. The compiler used a custom typed CIR with arena/index-based storage rather than LLVM IR, and direct use or translation of Clang/LLVM source was prohibited. C11 was the main language target, C23 was a stretch goal, x86 and x86-64 were required back ends and AArch64 was optional. The task therefore supplied substantial high-level design, toolchain and testing constraints. The run tests implementation from a repository with no compiler code; it does not test architecture-free formation. 9.3 Initial repository and run phases The first root session began at commit41e087ce90f3, which contained only.gitignoreand genesis.tomland no compiler implementation. Each delegated agent worked in its own Git worktree. The second root session began from the first session’s final commit,04d64b89d504, and received the accepted compiler repository plus a handoff summary of completed work, validation results, known gaps and next steps. The two root sessions are two phases of the same run, not independent repeats. 9.4 Human-provided information The root objective specified the implementation language, high-level compiler organization, typed intermediate representation, command-line compatibility, target architectures and test sources. Humans did not provide compiler code or concrete module implementations. The run therefore tests automated implementation under a detailed human specification, not architecture-free formation. 9.5 Evaluation targets The language targets were C11 and selected C23 extensions. Compiler behaviour was checked with the recorded test suites and project compilation tests described below. These tests do not prove complete C11 conformance. 16 EvoX GenesisPreprint 9.6 External validation sources LLVM (upstream:https://github.com/llvm/llvm-project) is used as a toolchain and test source, not as a C-language standard. Here, “LLVM-compatible” means thatjccworks with LLVM-oriented workflows and is tested on LLVM test programs; it does not mean thatjccreused LLVM code or LLVM’s internal IR. c-testsuite, the LLVM test suite, LZ4 and SQLite supplied external test programs, and Csmith programs were generated by the committed harness. The results are reported separately because these tests measure different things. 9.7 Run configuration and archive structure The run had two root sessions in sequence. The archive contains 1,019 episode records, while the top-levelagentcountreports 1,065 spawned agents, so archive-based organization statistics use only the records that are present. Four archived records point to missing parent IDs and have no archived descendants, leaving 1,015 records for the reconstructed parent–child tree. Token and cost totals come from the top-level usage record. Archivedobjectivefields contain task instructions but not complete system prompts, message histories or tool outputs. 9.8 Developmental lineage and complete results Run totals, archived episodes, records in the reconstructed parent–child tree, Git history, repository line counts and test results refer to different sets of records, so they are reported separately. d1 d2 d3 d4 d5 I I Initialization EarlierLater Optimization EarlierLater Retained No change Not integrated Git object unavailable Supplementary Fig. S5. DeepSeek compiler-development tree. The radial tree shows the two root sessions and all 1,015 records used in the reconstructed parent–child tree after four records with missing parents were excluded. Radial distance shows delegation depth. Blue and coral show initialization and optimization; shade shows completion order within each phase. Symbols mark retained, no-change, not-integrated and Git-object-unavailable outcomes. 17 EvoX GenesisPreprint Table S2. Compiler archive and integration counts. QuantityValue Raw archived records1,019 Top-level agent count field1,065 Direct missing-parent records4 Excluded descendants0 Records in reconstructed tree1,015 Initialization records312 Optimization records703 Retained929 No change78 Not integrated5 Git object unavailable3 First-parent commits327 Maximum observed delegation depth5 Peak active episodes29 Retention means that a contribution remains in the Git history leading to the final repository; it does not mean that the contribution was independently correct. The configured maximum delegation depth was 8, and the deepest archived record was at depth 5. 9.8.1 Resource use and repository size The run lasted 123.402 h. Summed episode durations were 666.385 agent-hours because episodes overlapped. Cached input accounted for 97.382% of input tokens. Table S3. Compiler-formation resource use. MetricObserved value Elapsed wall time123.402 h Raw agent-hours666.385 h Median episode duration12.76 min Input tokens4,134,593,954 Cached input tokens4,026,336,896 Uncached input tokens108,257,058 Cached input/input97.382% Output tokens64,092,688 Total tokens4,198,686,642 Logged costUS$44.3760 Table S4. Compiler-formation resource use by phase. PhaseRecords Wall time (h) Agent-hoursTotal tokens Cost (US$) Initialization31223.905163.925 1,052,907,91213.5715 Optimization70799.497502.460 3,145,778,73030.8045 Total1,019123.402666.385 4,198,686,64244.3760 Phase totals come from the two non-overlapping root usage records. Per-episode usage records are not summed for billing because parent records include usage from their descendants. Physical-line counts include blank lines and comments in every tracked text file. The final repository contains 248,989 physical lines across 750 text files and no tracked binary files; 219,676 lines are in 354 Rust source files. The remaining lines include documentation, tests and validation material. The 248,989 total is therefore a repository-size measure, not a count of compiler implementation lines or a measure of software quality. 18 EvoX GenesisPreprint a 020,00040,00060,00080,000 Supporting code28,200 Front end73,842 IR & optimization70,926 Back end76,021 Physical repository lines b 1101001k10k100k1M Rust219,676 / 354 files Markdown17,005 / 77 files C source5,036 / 130 files Python3,265 / 14 files C header3,163 / 49 files Expected output271 / 106 files Shell195 / 3 files Cargo.toml132 / 9 files Makefile101 / 1 files Cargo.lock66 / 1 files TOML42 / 2 files YAML25 / 1 files .gitignore10 / 2 files Info2 / 1 files Physical lines (log scale) Supplementary Fig. S6. Final DeepSeek compiler repository. The final tracked repository contains 248,989 physical lines in 750 text files, including 219,676 Rust lines in 354 .rs files. a, Lines grouped by functional category. b, Line and file counts by tracked file type on a logarithmic scale. Counts include comments and blank lines and describe the whole repository, not compiler implementation alone. Table S5. Final compiler repository lines by tracked text-file type. File typeFiles Physical linesShare Rust354219,67688.23% Markdown7717,0056.83% C source1305,0362.02% Python143,2651.31% C header493,1631.27% Expected output1062710.11% Shell31950.08% Cargo.toml91320.05% Makefile11010.04% Cargo.lock1660.03% TOML2420.02% YAML1250.01% .gitignore2100.00% Info120.00% Total750248,989 100.00% Table S6. Final compiler test results and limits. TestMeasureResultRate Notes LLVM test suitePassing cases32/3688.9% Four reported cases did not pass c-testsuitePassing tests220/220100.0% Complete reported c-testsuite set CsmithExecuted random programs 93/93100.0%Seven of 100 seeds skipped; zero executed failures LZ4Essential checks8/8100.0% All reported essential checks passed SQLiteTest stages2/2100.0%Compile/link and deterministic SQL checks; not the upstream suite Rust unit testsWorkspace count2,904 passed—One intentional ignore; no fixed external denominator Internal corpusCompiler cases106/106100.0% 86 compile-run and 20 compile- fail cases The test sets contain different numbers and kinds of cases. SQLite used deterministic shell queries rather than the full upstream suite; Csmith reports 93 executed seeds, with seven skipped. These 19 EvoX GenesisPreprint results show that the run produced a working C compiler under the stated task specification. They do not establish full C11 conformance, production readiness or a run-to-run success rate. Table S7. Compiler task and run settings. ItemSetting Run setup Genesis; two sequential root sessions; per-agent Git worktrees ModelDeepSeek V4 Flash Archived model identifier deepseek:deepseek-v4-flash; model id=deepseek flash Reasoning effort xhigh Context-compression threshold150,000 tokens Initial codebase .gitignore and genesis.toml; no compiler implementation Root-task inputs Phase-I compiler blueprint; Phase-I continuation with handoff summary Turn limits2,048 root turns; 128 turns per non-root episode Delegation and retry limitsMaximum depth 8; maximum retries 15 External test sourcesc-testsuite, LLVM test suite, LZ4 and SQLite Generated-program testsCsmith through the committed harness Rust toolchain Rust stable; edition 2024; minimum Rust version 1.85; rustfmt and clippy Compiler targetC11 primary and C23 stretch; x86 and x86-64 mandatory; AArch64 optional Table S8. Machine and software environment for the compiler experiments. ItemRecorded value CPUAMD Ryzen 7 PRO 6850HS with Radeon Graphics CPU layoutx86-64; one socket; 8 physical cores; 2 threads per core; 16 online logical CPUs Memory64 GB CPU frequency403.7300–4787.0820 MHz; frequency boost enabled Cache256 KiB L1d, 256 KiB L1i, 4 MiB L2 and 16 MiB L3 in aggregate NUMAOne node containing CPUs 0–15 Container and hostArchLinux container; NixOS-built Linux 6.18.39 host kernel FilesystemZFS with copy-on-write worktrees Tool isolation systemd-run and cgroups for every agent tool call Missing reproduction fields Container digest, package lock, per-tool cgroup limits, exact Rust/linker revisions and host-load traces The compiler-formation and continuation runs used the same dedicated machine. This removes machine identity as a difference between the two continuation paths, but concurrency, CPU frequency, agent counts and token use still differed. 9.9 Archive completeness The archive status iscompleted. Four records with missing parent IDs remain in the raw count but are excluded from the parent–child tree. Some provider, message and environment details are missing, so an exact replay is not possible from this package alone. These missing fields do not change the reported final repository and test measurements. 10 Continuity: Development Across Foundation-Model Replacement 10.1 Shared starting world This experiment uses a different compiler history from the DeepSeek formation run in Section 9. It has three stages: initial development with GLM 5.2, continuation with GLM 5.2 and continuation from the same completed compiler with DeepSeek V4 Flash. Both continuation runs start from commit 37216cfa254a. No result from the DeepSeek formation run is used as a continuation baseline. Both continuation runs received the same completed GLM repository, saved project context, user instruction, test families and recorded controller limits. The instruction was: “Continue and finish all remaining work, achieve 100% pass rate, excluding csmith as it is not installed.” Agent count, concurrency, token use, wall time and code growth were not fixed in advance. 20 EvoX GenesisPreprint 10.2 Evaluation protocol Both continuations used Rust workspace tests, LLVM SingleSource, c-testsuite, LZ4 and SQLite at -O0. The saved LLVM case lists differ between snapshots, so the reported fractions are not results on one fixed test set. 10.3 Run settings, lineage and results There was one completed run for each continuation path, so the results describe these runs rather than a repeatable model effect. Both continuations used the same recorded limits for depth, retries, turns and context compression, and both ran on the machine in Table S8. Table S9. Compiler-continuation starting points and run settings. SettingInitial developmentGLM continuationDeepSeek continuation Model pathNew project→ GLM 5.2GLMcompiler→ GLM 5.2 Same GLM compiler→ DeepSeek V4 Flash Starting stateEmpty tracked projectCompleted compiler at 37216cfa254a Same completed compiler at 37216cfa254a TaskBuild new compilerContinue existing com- piler Continue existing com- piler Root roleNot recordedManagerManager Depth and retry limits8; 158; 158; 15 Turn limits 2,048 root; 128 delegated 2,048 root; 128 delegated 2,048 root; 128 delegated Compression threshold150,000 tokens150,000 tokens150,000 tokens Test familiesRust, LLVM, c-testsuite, LZ4, SQLite Same familiesSame families CsmithRequested; unavailableExcludedExcluded Runs111 Shared fixed budgetNot specifiedNot specifiedNot specified Table S10. Run summary for compiler continuation. MetricInitial GLM GLM continuation DeepSeek continuation Elapsed time (h)136.5621.9917.10 Spawned Agents56298178 Archived records50497168 Archive coverage89.7%99.0%94.4% First-parent commits6198831 Maximum observed depth548 Peak active Agents21919 Mean active Agents2.862.945.70 Summed Agent-hours390.5764.6597.57 Median duration (min)14.416.117.0 90th-percentile duration (min)83.259.870.2 Code-changing records47990160 No-change records2578 DeepSeek finished earlier, but it also used more agents, more concurrent episodes, more archived agent-hours and more tokens. The wall-time difference is therefore not a speed comparison under equal resources. 21 EvoX GenesisPreprint Table S11. Archive coverage for compiler continuation. StageSpawned Archived Coverage Missing-parent issue Initial development56250489.7%Six absent parent IDs refer- enced by 15 records GLM continuation989799.0%Two records reference absent parent 562 DeepSeek continuation17816894.4%No missing-parent reference among archived records Missing archived records can make reconstructed depth, duration, parent links and concurrency incomplete. The parent–child and organization statistics in this section therefore describe the archived records, not every spawned agent. Initial GLM GLM 5.2 cont. DS V4 cont. 504 archived records | 2 root segments | depth d5 97 archived records | depth d4168 archived records | depth d8 Continuation roles:executormanagerinvestigatortask scheduler Initial-development circles: role unavailable Lighter to darker: earlier to later completion Supplementary Fig. S7. Delegation trees for compiler continuation. The upper tree shows the 504 archived records from initial GLM development, including two root segments and depth to d5; agent roles were not recorded for this stage. The lower trees show the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash continuation records. Distance from the centre shows delegation depth, node shape shows the recorded role where available and colour shade shows completion order. 22 EvoX GenesisPreprint a b Initial dev. (depth only)GLM 5.2 cont.DeepSeek V4 Flash cont. 0 25 50 75 100 54 97 Executor 21 49 Manager 21 22 Codebase investigator 1 0 Task scheduler Archived agent records 0 100 200 2 1 1 d0 122 31 26 d1 256 53 57 d2 91 8 55 d3 31 4 12 d4 2 8 d5 3 d6 1 d7 5 d8 Archived agent records Delegation depth Supplementary Fig. S8. Agent roles and delegation depth in compiler continuation. a, Role counts for the 97 archived GLM 5.2 continuation records and 168 archived DeepSeek V4 Flash records; roles were not recorded for initial development. b, Delegation-depth counts for initial development and both continuations. These counts describe archived records, not all spawned agents. 10.3.1 Resources, repository growth and validation Prompt-cache reuse was high in both continuation runs, but DeepSeek used substantially more total tokens than GLM. The two runs therefore cannot be compared as equal-budget efficiency tests. Table S12. Token use and cost in compiler continuation. MetricInitial GLMGLM continuationDeepSeek continuation Input tokens2,245,871,926543,563,883902,775,744 Cached input tokens2,163,779,584534,150,656884,375,552 Fresh input tokens82,092,3429,413,22718,400,192 Cached input/input96.34%98.27%97.96% Output tokens19,334,8863,702,6978,704,733 Total tokens2,265,206,812547,266,580911,480,477 Input cost (US$)677.511916152.0576885.052314 Output cost (US$)85.07365916.2918672.437395 Total cost (US$)762.585575168.3495557.489709 The GLM-continuation archive stores zero in its cost fields; we treat those entries as missing. The US$168.349555 GLM continuation cost is reconstructed from the rate schedule that reproduces the recorded initial-development GLM bill. The initial-development and DeepSeek costs are recorded in the archive. We therefore do not compare cost efficiency between the two models. Table S13. Tests reported at the end of compiler continuation. Test targetInitial developmentGLM continuationDeepSeek continuation Rust unit tests1,1361,226 (+90)1,350 (+214) LLVM SingleSource1,558/1,870 (83.3%)1,445/1,448 (99.79%)1,820/1,820 (100%) c-testsuite220/220220/220220/220 LZ44/4 files4/4 files4/4 files SQLite at -O0Basic run passedCompiled Compiled, linked and ran CsmithUnavailableExcludedExcluded The LLVM case lists differ among snapshots, so each fraction applies only to its own saved list. No cause is assigned to the three non-passing GLM-continuation cases because per-case diagnostics are unavailable. The c-testsuite, LZ4 and SQLite values come from saved completion records and were not rerun while preparing this Supplementary Information. 23 EvoX GenesisPreprint Table S14. Physical line counts for the compiler-continuation snapshots. Included file typeTask 1 GLM 5.2 DeepSeek V4 Flash Rust94,253104,264117,409 Cargo.toml202202202 Markdown10,32511,87614,718 Shell640649825 Total105,420116,991133,154 The initial-development total in Table S14 belongs to the separate GLM compiler history and counts only tracked Rust,Cargo.toml, Markdown and shell files. The 248,989-line total in Section 9 comes from a different repository and counts all tracked text files. The two numbers are therefore not directly comparable. 1001k10k100k Initial dev. (GLM 5.2)GLM 5.2 cont.DeepSeek V4 Flash cont. Rust (.rs) 94,253 104,264 117,409 Cargo.toml 202 202 202 Markdown (.md) 10,325 11,876 14,718 Shell (.sh) 640 649 825 Physical lines (log scale) Supplementary Fig. S9. Physical line counts during compiler continuation. Tracked Rust, Cargo.toml, Markdown and shell lines are shown for the initial GLM compiler and the two continuation results. The horizontal axis is logarithmic so that small project-control files remain visible. Counts include blank lines. Both GLM 5.2 and DeepSeek V4 Flash extended the same completed GLM compiler world. This shows continuation after agent turnover and after model replacement in the observed runs. It does not show why continuity was possible, whether the non-code records were necessary, or which model is better. 24 EvoX GenesisPreprint 11 Redevelopment: MESA from Fortran to Rust 11.1 Starting system and run settings The experiment used a lightly modified MESA fork (upstream:https://github.com/MESAHub/m esa ) at commit461dcba94f33a0d991db129d406a877fcc9dfdcas a read-only reference. The Rust output is archived at commit2ad071e658f8d4de21a9f0e906592c364e10023. The run used DeepSeek V4 Flash withxhighreasoning effort and a 150,000-token context-compression threshold. This was one run. A second root-level objective began at 31.720 h after a handoff from the first. Resource totals use the top-level archive record because parent records include usage from their descendants. The root objective requested a broad Rust rewrite with API compatibility, testing and performance optimization. The results reported here cover only the 13 mapped foundation and physics modules and the workloads below. They do not establish a complete Rust replacement for MESA. Table S15. MESA-to-Rust run and timing settings. QuantityValue ModelDeepSeek V4 Flash Model settings xhigh reasoning; 150,000-token compression threshold Recorded agent rolesCodebase lead, manager, executor and codebase investigator Controller limitsMaximum depth 8; retries 15; 2,048 root turns and 128 child turns Source baselineModified MESA fork, commit 461dcba94f33 Timing host Shared Intel Xeon Platinum 8336C system; 64 physical cores / 128 hardware threads; benchmark processes pinned to CPUs 0–3 Timing runs25 direct-binary runs per workload after warm-up; separate 40-run burn-proxy check Fortran build gfortran12.2.0;-O3 -march=native -ffp-contract=fast -std=f2008 Rust build opt-level=3; fat LTO; codegen-units=1; panic=abort Table S16. MESA-to-Rust resource use and archive coverage. QuantityRecorded value Experiment interval3–5 August 2026 (UTC) Elapsed wall time33.219 h Root-agent handoff31.720 h Spawned agents272 Archived agent records260 Archive coverage95.6% Input tokens771,755,551 Cached input tokens744,102,016 Cached input share96.4168% Output tokens16,721,326 Total tokens788,476,877 Recorded model-token costUS$10.636892 Archive coverage is the number of archived records divided by the top-level spawned-agent count. Any record-level statistics below therefore describe the available archive, not all spawned agents. 11.2 Migration scope and module mapping The comparison maps 13 MESA module directories one-to-one to 13mesa-rscrates. These MESA directories contain 139,414 physical Fortran lines, including each module’s localtest/programs. The matching Rust crates contain 67,373 library lines and 19,955 crate-local test lines, or 87,328 mapped Rust lines in total. A separate count of all.rsfiles in the workspace gives 89,946 lines. 25 EvoX GenesisPreprint Summing the archived root-level components gives 89,945, one line fewer; we keep this one-line discrepancy visible. It does not affect the mapped total of 87,328 lines. All counts include comments and blank lines and measure source size, not feature equivalence. These ratios compare physical line counts only: 139,414 Fortran lines versus 67,373 Rust library lines gives 2.07×, and versus 87,328 mapped Rust lines including crate-local tests gives 1.60×. The modules vary widely. In particular, the Rusteosandkapcrates cover narrower functionality than the full MESA modules, so their smaller line counts should not be read as a Rust-versus-Fortran compression result. Table S17. Module-level source line counts for MESA and mesa-rs. LayerModuleFortran LOCRust libRust testsRust totalFortran/Rust Foundationconst308836909260.33 Foundationutils3,5691,3843701,7542.03 Foundationmath1,0201,4748072,2810.45 Foundationmtx5,2068,2441,7289,9720.52 Foundationinterp1d5,8512,0029372,9391.99 Foundationinterp 2d16,1765,5921,3006,8922.35 Foundationnum18,35710,2253,07813,3031.38 Physicschem4,4243,7539004,6530.95 Physicsrates18,54712,3044,97517,2791.07 Physicsneu2,2632,2229953,2170.70 Physicsnet17,79916,3322,42918,7610.95 Physicseos25,8171,4261,5142,9408.78 Physicskap20,0771,5798322,4118.33 AllTotal139,41467,37319,95587,3281.60 The final column compares physical line counts; it is not a language-efficiency score. The 1,030 static#[test]annotations, 19,955 crate-local test source lines and 1,052 passing workspace tests are different measures and should not be interchanged. The migration does not cover several higher-level or broader parts of MESA, including thestar, astero,binary,adipls,stellaandgyreengines, the full seven-source EOS blend, the complete REACLIB dataset, single-precisionsgvariants andautodiff. The result is a migration of a core numerical and physics module chain, not a complete Rust replacement of MESA. 26 EvoX GenesisPreprint 10 3 10 4 Source lines (log scale) eos rates interp_2d net kap num interp_1d mtx chem utils neu math const a beforeafter Supplementary Fig. S10. Module-level source line counts for MESA and Rust. For each of the 13 mapped modules, physical Fortran lines in the module directory, including local test programs, are compared with Rust library lines and Rust library-plus-crate-test lines. The logarithmic axis shows both larger and smaller ports. Counts include comments and blank lines and do not imply feature equivalence. 11.3 Run timeline and concurrency The archived run lasted 33.22 h, with the root-level handoff at 31.72 h. Reconstructing episode times at one-minute resolution gives a maximum of 22 overlapping archived episodes. This is a count of active assignments, not CPU use. 08162433.22 Elapsed time (hours) const utils math mtx num interp_1d interp_2d chem eos rates neu net kap b handoff Supplementary Fig. S11. Accepted Rust source changes over time. First-parent Git activity is shown for the 13 migrated crates during the 33.22-h run. Colour intensity represents log(1+ added+ deleted) lines. The dashed line marks the root-level handoff at 31.72 h. Blank intervals mean that no first-parent source change was accepted at the plotted resolution; analysis or testing may still have been active. 27 EvoX GenesisPreprint 08162433.22 Elapsed time (hours) 0 5 10 15 20 Active Agent episodes c handoff peak 22 leadmanagerexecutorinvestigator Supplementary Fig. S12. Concurrent agent episodes during migration. Active archived episodes are reconstructed at one-minute resolution and stacked by recorded role. The maximum overlap was 22 episodes. The plot uses archived start and finish times and does not show CPU use. 11.4 Numerical validation and runtime The six-workload comparison uses the median of 25 runs per implementation after warm-up. These workloads are selected numerical kernels or pipelines, not a complete MESA run. In particular, the “end-to-end burn” case is a single-zone, constant-density burn proxy. Its timing covers burn integration but not table loading or composition setup; it is not a full MESA star evolution run. The Fortran and Rust timers were not identical. Fornetandkap, Fortran usessystemclockand Rust usesInstant; for interpolation, Newton, ROS2 and EOS, Fortran usescputimeand Rust uses Instant. The workloads are reported as single-threaded and CPU-bound, and the two languages use different build toolchains. The runtime ratios therefore describe these particular binaries on this host and benchmark setup; they are not a general Rust-versus-Fortran speed comparison. Across the 25-run batch, the Rust median was lower for all six workloads, with Fortran/Rust ratios from 1.55×to 6.87×. EOS lookup and Newton solve were bit-exact under the recorded checks; the other relative checksum differences ranged from 5.1× 10 −15 to 3.1× 10 −9 . Table S18. Numerical agreement and runtime performance for six migrated workloads. WorkloadFortran (s) Rust (s) Speedup Checksum difference End-to-end burn0.4460.2871.55×3.1× 10 −9 EOS lookup1.7861.1151.60×Bit-exact Opacity lookup0.5320.2691.98×1.3× 10 −13 2D interpolation0.1590.1011.58×4.9× 10 −12 ROS2 integration0.7220.1365.30×5.1× 10 −15 Newton solve0.0840.0126.87×Bit-exact A separate timing check repeated the burn proxy 40 times per implementation after three warm-up runs, again pinned to CPUs 0–3. The median was 0.2996 s for Fortran and 0.2427 s for Rust, a 1.23× ratio. Thirty of the 40 Rust timings were below the Fortran median; this is not a 30/40 paired win rate because the paired run vectors are unavailable. Both implementations reported the same integrator counts: 8,889 function evaluations, 199 Jacobian evaluations, 199 steps, 198 accepted steps and one rejected step. The abundance-checksum relative difference was 3.1× 10 −9 . 28 EvoX GenesisPreprint Table S19. Separate 40-run timing check for the burn proxy. StatisticFortran (s) Rust (s) Fortran/Rust Minimum0.28970.23721.22× P100.29220.23851.22× P250.29270.23921.22× Median0.29960.24271.23× Mean0.34470.27351.26× P750.44160.36091.22× P900.44580.37291.20× Maximum0.44900.38151.18× The 1.55×burn ratio in the six-workload table and the 1.23×ratio in the separate 40-run check come from different batches and should not be pooled. The package contains summary statistics for the 40-run check but not the 80 individual timings, so we cannot reconstruct a confidence interval or paired test. Timing was also sensitive to host load: one noisy interleaved run gave a ratio of 0.82×, while a quieter rerun gave about 1.22×. We therefore use the 1.23×40-run median as the more conservative burn result and do not claim a general speed advantage. 11.5 Dependency structure and recursive context The mapped dependency graphs contain 142 MESA provider-to-dependent edges and 41mesa-rs crate edges. Forty edges appear in both graphs, 102 appear only in the MESA graph and one appears only in Rust. A MESA-only edge means only that no matching direct Rust crate edge was found; it does not by itself show missing or removed functionality. Table S20. Mapped dependency counts for MESA and mesa-rs. CategoryEdges Interpretation MESA142 Provider-to-dependent edges parsed from INTERNALDEPENDSON mesa-rs41 Mapped crate dependencies parsed from Cargo.toml Retained40 Edges present in both mapped graphs MESA-only102 No matching direct Rust crate dependency in the mapped graph Rust-only1 Dependency introduced in mesa-rs Archived assignments contain 34 observed context paths; adding parent paths needed to connect the hierarchy gives 37 nodes. Twenty-six observed paths containCONTEXT.md. Git history records 26 file creations and 62 later accepted updates affecting 19 files. This shows that shared context changed during the run, but the archive does not show which agent read which file or whether the updates improved performance. 29 EvoX GenesisPreprint 01234 Recursive depth a ./ n=12 benches n=4 src n=2 crates mesa-chem n=15 mesa-const n=4 mesa-eos n=5 mesa-interp1d n=7 mesa-interp2d n=10 mesa-kap n=3 mesa-math n=10 mesa-mtx n=21 mesa-net n=38 tests n=4 mesa-neu n=3 src n=5 tests n=3 mesa-num n=27 mesa-rates n=29 src analytic n=7 mesa-utils n=4 net private n=2 public n=1 test n=1 CONTEXT.md present No CONTEXT.md Implicit parent Supplementary Fig. S13. Recursive context paths. The hierarchy shows context paths found in archived assignments, with parent paths added where needed to connect the tree. Markers show whether aCONTEXT.md file was present. These paths record task context, not directory traversal or file access. 00.250.500.751.001.25 Elapsed time (days) mesa-utils (1) mesa-num (1) mesa-neu (1) mesa-mtx (1) mesa-interp2d (1) mesa-interp1d (1) data (1) tests (2) scripts (2) mesa-math (2) mesa-eos (2) mesa-const (2) bench-fortran (2) benches (4) ./ (6) mesa-chem (7) mesa-net (8) mesa-kap (8) mesa-rates (10) CONTEXT.md location b Created Updated Supplementary Fig. S14. Changes to shared context files. First-parent Git creation and update events are shown for CONTEXT.md files during migration. The timeline shows when shared context changed; it does not show which agents read each file or whether an update improved performance. The run produced 13 Rust crates for the reported MESA core-module scope. The final workspace passed 1,052 tests, and the tested numerical workloads showed the agreement reported above. 30 EvoX GenesisPreprint 12 Evidence Boundaries and Audit Notes 12.1 What each experiment establishes Table S21 states what each experiment supports and what remains unresolved. Detailed measurements are in Sections 9–11. Table S21. What each experiment supports and what remains unresolved. ExperimentWhat else could explain the result Evidence in this studyWhat the result sup- ports Compiler forma- tion The task specification and model knowledge may ex- plain part of the resulting organization Repository with no compiler implementation, a 1,015-record reconstructed parent–child tree, repository counts and seven test families One observed run formed and broadly tested a working compiler; no re- peated mechanism test Compiler contin- uation Model differences, un- equal resource use or the source code alone may ex- plain the observed contin- uation Same saved GLM starting world and instruction, but one run per path, different resource use, dif- ferent LLVM case lists and no code-only or fresh-agent control The same com- pletedcompiler wascontinued withGLM5.2 and DeepSeek V4 Flash MESAmigra- tion Limited module and work- load coverage and the tim- ing setup may explain part of the result Thirteen mapped module direc- tories, 13 Rust crates, six 25-run workload summaries and a sepa- rate 40-run burn-proxy summary Numerical agree- ment on the tested workloadsand lowermeasured runtimes under the reported setup 12.2 Observed failures and missing records Table S22 lists observed failures and missing records. We do not assign a cause when the available evidence does not show one. Table S22. Observed failures, missing records and how they are handled. ExperimentObserved issueHow it is handled Compiler formationFour direct missing-parent records; four of 36 reported LLVM cases did not pass; seven of 100 Csmith seeds were skipped Rows with missing parents are excluded only from the parent–child tree; non- passing and skipped test cases remain in the reported denominators Compiler continuationGLM 5.2 passed 1,445/1,448 on its retained LLVM manifest The exact count is reported. No cause is claimed for the three non-passing cases be- cause per-case diagnostics are unavailable Continuation archivesArchive coverage is 89.7% for ini- tial GLM development, 99.0% for GLM continuation and 94.4% for DeepSeek continuation Parent–child, role, depth and concurrency summaries use only the archived records available for each stage MESAnumerical checks Four of six tested workloads have small non-zero checksum differ- ences; the module and workload coverage is incomplete The numerical differences and coverage limits are reported directly; no claim of complete MESA equivalence is made MESA timing checksOne noisy interleaved end-to-end timing run favoured Fortran (0.82× Rust/Fortran speed ratio), whereas the dedicated 40-run summary favoured Rust at 1.23× median Both observations are reported; runtime claims are limited to the reported host and timing setup and are not generalized to Rust versus Fortran 31 EvoX GenesisPreprint ExperimentObserved issueHow it is handled MESA line countsIndependent workspace counting paths differ by one physical Rust line (89,946 versus 89,945) The discrepancy is reported and is not used in the main comparison; the mapped 13- crate total of 87,328 lines is the comparison value 12.3 Causal tests not performed in this study The present experiments establish observed capabilities under the reported settings, but they do not isolate the causal contribution of every persistent record or recursive mechanism. One direct test would hold executable code fixed while changing accepted non-code development records. Here,Dev(푣)means the accepted non-code records stored with version푣that can affect later work. It is a way to separate those records from executable code for an experiment; it is not a new object in the model. To show that these non-code records matter beyond the executable code, one would need two accepted versions푣 퐴 and푣 퐵 with identical executable code but different accepted non-code records, and then give both the same future task 푢: Code(푣 퐴 ) = Code(푣 퐵 ),Dev(푣 퐴 ) ≠ Dev(푣 퐵 ), 푃 푌 | (푣 퐴 , 푝),푢, 퐵 ≠ 푃 푌 | (푣 퐵 , 푝),푢, 퐵 , (9) with the same path, model, tools, evaluator and resource budget퐵. We did not run this experiment in the present study. 32

Instant research discovery