코딩 에이전트는 일회용으로 쓰고, 소프트웨어 프로젝트 자체를 영구히 살아있게 만들어 컴파일러를 처음부터 만들게 한 실험
EvoX Genesis는 오래 사는 에이전트나 거대한 메모리를 두는 대신, '승인된 버전+경로'로 정의된 소프트웨어 세계를 영속시키고 그 안에 짧게 살다 사라지는 에이전트를 반복해서 투입하는 방식을 제안한다. DeepSeek V4 Flash로 컴파일러 구현이 전혀 없던 저장소에서 약 25만 줄 규모의 러스트 기반 C 컴파일러를 120시간 넘게 걸려 만들었고 모델 토큰 비용은 44달러였다. 같은 방식으로 GLM 5.2가 만든 컴파일러를 에이전트와 모델을 바꿔가며 이어서 개발했고, MESA 항성진화 코드 13개 모듈을 포트란에서 러스트로 다시 만들어 성능을 높이면서도 수치 결과를 그대로 유지했다.
METAL MEDIA 해설 도표
영속적 재귀 세계의 작동 구조
증거 상태측정 결과가 보고됨
승인된 버전 v + 경로 p프로젝트의 승인된 전체 상태와 역사(v)와, 에이전트가 시작하는 위치·책임 범위(p)를 함께 나타내는 로컬 소프트웨어 세계
짧게 사는 에이전트하나의 목표를 받아 후보 변경을 만들고 임무가 끝나면 사라지는 에이전트. 개인의 대화나 상태는 다음 에이전트로 이어지지 않는다
재귀적 위임상위 에이전트가 같은 버전 안에서 다른 경로에 하위 에이전트를 생성해 작업을 넘기는 과정. 버전을 즉시 바꾸지 않는다
승인 게이트상위 에이전트가 테스트·제약·통합 증거를 보고 변경을 수락, 거부, 재작업 요청 중 하나로 판단하는 단계
누적된 프로젝트 역사수락된 변경만 다음 버전으로 기록되어, 이후 투입되는 새 에이전트들이 상속받는 유일한 상태가 된다
METAL MEDIA이 원문을 바탕으로 재구성한 해설 도표이며, 논문 저자의 원문 figure가 아닙니다.
무엇을 했나
문제의식: 소프트웨어 시스템은 한 명의 코딩 에이전트가 살아있는 시간보다 훨씬 오래 개발이 이어지는데, 기존 방식은 긴 컨텍스트, 메모리, 관리자 에이전트처럼 에이전트 쪽 상태를 늘려서 연속성을 유지했다.
방법: Genesis는 '승인된 버전 v + 경로 p'로 정의되는 로컬 소프트웨어 세계를 만들고, 짧게 사는 에이전트가 이 세계에 들어와 변경을 제안하면 상위 에이전트가 테스트와 통합 증거로 수락, 거부, 재작업을 판단한다. 위임된 하위 작업(재귀적 위임)은 버전을 바꾸지 않고 경로만 옮기며, 오직 수락된 변경만 프로젝트 역사에 기록된다.
형성 실험: 컴파일러 구현이 전혀 없는 저장소에서 DeepSeek V4 Flash로 123.4시간 동안 1,019개 에이전트 에피소드를 거쳐 24만8,989줄짜리 러스트 C 컴파일러(jcc)를 만들었고, 모델 토큰 비용은 44.38달러였다.
지속 실험: GLM 5.2가 만든 완성된 컴파일러 저장소를 그대로 넘겨받아 한쪽은 GLM 5.2로, 다른 쪽은 DeepSeek V4 Flash로 이어서 개발했더니 두 갈래 모두 에이전트 교체와 모델 교체 후에도 개발이 계속됐다.
재개발 실험: MESA 항성진화 소프트웨어의 13개 모듈(포트란 약 13만9,414줄)을 DeepSeek V4 Flash로 러스트 워크스페이스(약 8만9,946줄)로 다시 작성했고, 6개 수치 작업에서 러스트 쪽이 더 빠르면서도(1.55배~6.87배) 수치는 거의 동일했다.
Figure 1: Persistent recursive worlds. a, An accepted software version can be viewed from different repository-relative paths, defining local worlds w=(v,p). The version v fixes the accepted project state and history, while the path p sets where an agent starts and what it is responsible for. Recursive delegation (v,p)↝(v,q) starts a child agent at path q without changing the accepted version v. 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 (v,p)→(v′,p′) 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.
Table S1: Repository commits used in the three experiments.
Repository
Version
Commit ID (SHA-1)
jcc
DeepSeek generated jcc
a8c116ec7ed3d59479ad3be8fed3e63384f50a87
jcc
GLM generated jcc
37216cfa254a40e40af48cd528743fd7f2d6737c
jcc
GLM generated jcc continued with DeepSeek
10077f65686102deef2c228e8a49b0569218ec48
jcc
GLM generated jcc continued with GLM
ab58a91460adb24e9349a554e02d4522d3ae2db4
mesa-rs
DeepSeek ported mesa
2ad071e658f8d4de21aa9f0e906592c364e10023
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.
Table S2: Compiler archive and integration counts.
Quantity
Value
Raw archived records
1,019
Top-level agent_count field
1,065
Direct missing-parent records
4
Excluded descendants
0
Records in reconstructed tree
1,015
Initialization records
312
Optimization records
703
Retained
929
No change
78
Not integrated
5
Git object unavailable
3
First-parent commits
327
Maximum observed delegation depth
5
Peak active episodes
29
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.
Table S3: Compiler-formation resource use.
Metric
Observed value
Elapsed wall time
123.402 h
Raw agent-hours
666.385 h
Median episode duration
12.76 min
Input tokens
4,134,593,954
Cached input tokens
4,026,336,896
Uncached input tokens
108,257,058
Cached input/input
97.382%
Output tokens
64,092,688
Total tokens
4,198,686,642
Logged cost
US$44.3760
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.
Table S4: Compiler-formation resource use by phase.
Phase
Records
Wall time (h)
Agent-hours
Total tokens
Cost (US$)
Initialization
312
23.905
163.925
1,052,907,912
13.5715
Optimization
707
99.497
502.460
3,145,778,730
30.8045
Total
1,019
123.402
666.385
4,198,686,642
44.3760
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.
Table S5: Final compiler repository lines by tracked text-file type.
File type
Files
Physical lines
Share
Rust
354
219,676
88.23%
Markdown
77
17,005
6.83%
C source
130
5,036
2.02%
Python
14
3,265
1.31%
C header
49
3,163
1.27%
Expected output
106
271
0.11%
Shell
3
195
0.08%
Cargo.toml
9
132
0.05%
Makefile
1
101
0.04%
Cargo.lock
1
66
0.03%
TOML
2
42
0.02%
YAML
1
25
0.01%
.gitignore
2
10
0.00%
Info
1
2
0.00%
Total
750
248,989
100.00%
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 S6: Final compiler test results and limits.
Test
Measure
Result
Rate
Notes
LLVM test suite
Passing cases
32/36
88.9%
Four reported cases did not pass
c-testsuite
Passing tests
220/220
100.0%
Complete reported c-testsuite set
Csmith
Executed random programs
93/93
100.0%
Seven of 100 seeds skipped; zero executed failures
LZ4
Essential checks
8/8
100.0%
All reported essential checks passed
SQLite
Test stages
2/2
100.0%
Compile/link and deterministic SQL checks; not the upstream suite
Rust unit tests
Workspace count
2,904 passed
—
One intentional ignore; no fixed external denominator
Internal corpus
Compiler cases
106/106
100.0%
86 compile-run and 20 compile-fail cases
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.
Table S7: Compiler task and run settings.
Item
Setting
Run setup
Genesis; two sequential root sessions; per-agent Git worktrees
.gitignore and genesis.toml; no compiler implementation
Root-task inputs
Phase-I compiler blueprint; Phase-II continuation with handoff summary
Turn limits
2,048 root turns; 128 turns per non-root episode
Delegation and retry limits
Maximum depth 8; maximum retries 15
External test sources
c-testsuite, LLVM test suite, LZ4 and SQLite
Generated-program tests
Csmith through the committed harness
Rust toolchain
Rust stable; edition 2024; minimum Rust version 1.85; rustfmt and clippy
Compiler target
C11 primary and C23 stretch; x86 and x86-64 mandatory; AArch64 optional
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.
Table S8: Machine and software environment for the compiler experiments.
Item
Recorded value
CPU
AMD Ryzen 7 PRO 6850HS with Radeon Graphics
CPU layout
x86-64; one socket; 8 physical cores; 2 threads per core; 16 online logical CPUs
Memory
64 GB
CPU frequency
403.7300–4787.0820 MHz; frequency boost enabled
Cache
256 KiB L1d, 256 KiB L1i, 4 MiB L2 and 16 MiB L3 in aggregate
NUMA
One node containing CPUs 0–15
Container and host
ArchLinux container; NixOS-built Linux 6.18.39 host kernel
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.
Table S9: Compiler-continuation starting points and run settings.
Setting
Initial development
GLM continuation
DeepSeek continuation
Model path
New project → GLM 5.2
GLM compiler → GLM 5.2
Same GLM compiler → DeepSeek V4 Flash
Starting state
Empty tracked project
Completed compiler at 37216cfa254a
Same completed compiler at 37216cfa254a
Task
Build new compiler
Continue existing compiler
Continue existing compiler
Root role
Not recorded
Manager
Manager
Depth and retry limits
8; 15
8; 15
8; 15
Turn limits
2,048 root; 128 delegated
2,048 root; 128 delegated
2,048 root; 128 delegated
Compression threshold
150,000 tokens
150,000 tokens
150,000 tokens
Test families
Rust, LLVM, c-testsuite, LZ4, SQLite
Same families
Same families
Csmith
Requested; unavailable
Excluded
Excluded
Runs
1
1
1
Shared fixed budget
Not specified
Not specified
Not specified
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.
Table S10: Run summary for compiler continuation.
Metric
Initial GLM
GLM continuation
DeepSeek continuation
Elapsed time (h)
136.56
21.99
17.10
Spawned Agents
562
98
178
Archived records
504
97
168
Archive coverage
89.7%
99.0%
94.4%
First-parent commits
619
88
31
Maximum observed depth
5
4
8
Peak active Agents
21
9
19
Mean active Agents
2.86
2.94
5.70
Summed Agent-hours
390.57
64.65
97.57
Median duration (min)
14.4
16.1
17.0
90th-percentile duration (min)
83.2
59.8
70.2
Code-changing records
479
90
160
No-change records
25
7
8
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.
Table S11: Archive coverage for compiler continuation.
Stage
Spawned
Archived
Coverage
Missing-parent issue
Initial development
562
504
89.7%
Six absent parent IDs referenced by 15 records
GLM continuation
98
97
99.0%
Two records reference absent parent 562
DeepSeek continuation
178
168
94.4%
No missing-parent reference among archived records
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.
Table S12: Token use and cost in compiler continuation.
Metric
Initial GLM
GLM continuation
DeepSeek continuation
Input tokens
2,245,871,926
543,563,883
902,775,744
Cached input tokens
2,163,779,584
534,150,656
884,375,552
Fresh input tokens
82,092,342
9,413,227
18,400,192
Cached input/input
96.34%
98.27%
97.96%
Output tokens
19,334,886
3,702,697
8,704,733
Total tokens
2,265,206,812
547,266,580
911,480,477
Input cost (US$)
677.511916
152.057688
5.052314
Output cost (US$)
85.073659
16.291867
2.437395
Total cost (US$)
762.585575
168.349555
7.489709
Table S13: Tests reported at the end of compiler continuation.
Test target
Initial development
GLM continuation
DeepSeek continuation
Rust unit tests
1,136
1,226 (+90)
1,350 (+214)
LLVM SingleSource
1,558/1,870 (83.3%)
1,445/1,448 (99.79%)
1,820/1,820 (100%)
c-testsuite
220/220
220/220
220/220
LZ4
4/4 files
4/4 files
4/4 files
SQLite at -O0
Basic run passed
Compiled
Compiled, linked and ran
Csmith
Unavailable
Excluded
Excluded
Table S14: Physical line counts for the compiler-continuation snapshots.
Table S16: MESA-to-Rust resource use and archive coverage.
Quantity
Recorded value
Experiment interval
3–5 August 2026 (UTC)
Elapsed wall time
33.219 h
Root-agent handoff
31.720 h
Spawned agents
272
Archived agent records
260
Archive coverage
95.6%
Input tokens
771,755,551
Cached input tokens
744,102,016
Cached input share
96.4168%
Output tokens
16,721,326
Total tokens
788,476,877
Recorded model-token cost
US$10.636892
Table S17: Module-level source line counts for MESA and mesa-rs.
Layer
Module
Fortran LOC
Rust lib
Rust tests
Rust total
Fortran/Rust
Foundation
const
308
836
90
926
0.33
Foundation
utils
3,569
1,384
370
1,754
2.03
Foundation
math
1,020
1,474
807
2,281
0.45
Foundation
mtx
5,206
8,244
1,728
9,972
0.52
Foundation
interp_1d
5,851
2,002
937
2,939
1.99
Foundation
interp_2d
16,176
5,592
1,300
6,892
2.35
Foundation
num
18,357
10,225
3,078
13,303
1.38
Physics
chem
4,424
3,753
900
4,653
0.95
Physics
rates
18,547
12,304
4,975
17,279
1.07
Physics
neu
2,263
2,222
995
3,217
0.70
Physics
net
17,799
16,332
2,429
18,761
0.95
Physics
eos
25,817
1,426
1,514
2,940
8.78
Physics
kap
20,077
1,579
832
2,411
8.33
All
Total
139,414
67,373
19,955
87,328
1.60
Table S18: Numerical agreement and runtime performance for six migrated workloads.
Workload
Fortran (s)
Rust (s)
Speedup
Checksum difference
End-to-end burn
0.446
0.287
1.55×
3.1×10−9
EOS lookup
1.786
1.115
1.60×
Bit-exact
Opacity lookup
0.532
0.269
1.98×
1.3×10−13
2D interpolation
0.159
0.101
1.58×
4.9×10−12
ROS2 integration
0.722
0.136
5.30×
5.1×10−15
Newton solve
0.084
0.012
6.87×
Bit-exact
Table S19: Separate 40-run timing check for the burn proxy.
Statistic
Fortran (s)
Rust (s)
Fortran/Rust
Minimum
0.2897
0.2372
1.22×
P10
0.2922
0.2385
1.22×
P25
0.2927
0.2392
1.22×
Median
0.2996
0.2427
1.23×
Mean
0.3447
0.2735
1.26×
P75
0.4416
0.3609
1.22×
P90
0.4458
0.3729
1.20×
Maximum
0.4490
0.3815
1.18×
Table S20: Mapped dependency counts for MESA and mesa-rs.
Category
Edges
Interpretation
MESA
142
Provider-to-dependent edges parsed from INTERNAL_DEPENDS_ON
mesa-rs
41
Mapped crate dependencies parsed from Cargo.toml
Retained
40
Edges present in both mapped graphs
MESA-only
102
No matching direct Rust crate dependency in the mapped graph
Rust-only
1
Dependency introduced in mesa-rs
Table S21: What each experiment supports and what remains unresolved.
Experiment
What else could explain the result
Evidence in this study
What the result supports
Compiler formation
The task specification and model knowledge may explain 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 repeated mechanism test
Compiler continuation
Model differences, unequal resource use or the source code alone may explain the observed continuation
Same saved GLM starting world and instruction, but one run per path, different resource use, different LLVM case lists and no code-only or fresh-agent control
The same completed compiler was continued with GLM 5.2 and DeepSeek V4 Flash
MESA migration
Limited module and workload coverage and the timing setup may explain part of the result
Thirteen mapped module directories, 13 Rust crates, six 25-run workload summaries and a separate 40-run burn-proxy summary
Numerical agreement on the tested workloads and lower measured runtimes under the reported setup
Table S22: Observed failures, missing records and how they are handled.
Experiment
Observed issue
How it is handled
Compiler formation
Four 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 continuation
GLM 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 because per-case diagnostics are unavailable
Continuation archives
Archive coverage is 89.7% for initial 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
MESA numerical checks
Four of six tested workloads have small non-zero checksum differences; 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 checks
One 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
MESA line counts
Independent 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
실제로 확인된 결과
컴파일러 형성: 123.4시간, 1,019개 에이전트 에피소드, 24만8,989줄 저장소, 모델 토큰 비용 44.38달러, c-testsuite 220/220, LLVM 32/36, Csmith 93/93, 러스트 워크스페이스 테스트 2,904개 통과.
컴파일러 지속: 같은 GLM 5.2 컴파일러 저장소에서 GLM 5.2 계속 개발은 자체 LLVM 테스트셋 1,445/1,448 통과, DeepSeek V4 Flash로 교체한 계속 개발은 1,820/1,820 통과. 단 두 테스트셋이 서로 다르고 자원 사용도 다르므로 직접 비교는 아니다.
MESA 재개발: 33.22시간, 272개 에이전트, 러스트 워크스페이스 8만9,946줄, 1,052개 테스트 통과(무실패, 18개 무시), 모델 토큰 비용 10.64달러.
6개 수치 작업 중 EOS 조회와 뉴턴 해법은 비트 단위로 완전히 일치했고, 나머지 4개는 상대 체크섬 차이가 5.1×10⁻¹⁵~3.1×10⁻⁹ 수준으로 매우 작았으며, 러스트가 모든 작업에서 더 빨랐다(1.55배~6.87배).
40회 반복한 별도 연소(burn) 검증에서는 포트란 0.2996초, 러스트 0.2427초로 1.23배 차이였고, 두 구현의 적분 스텝 수 등 핵심 지표는 동일했다.
어디에 쓸 수 있나
오랜 기간 여러 사람·모델이 교대로 참여해야 하는 대규모 저장소 개발에 프로젝트 중심 지속성 모델을 적용해볼 수 있다.
레거시 과학 소프트웨어(포트란 등)를 다른 언어로 이전하면서 기존 수치 검증 결과를 유지해야 하는 작업에 참고할 수 있다.
특정 파운데이션 모델에 종속되지 않고 모델을 교체하면서도 기존 코드베이스 개발을 이어가야 하는 상황에 시사점을 준다.
한계와 남은 검증
보고된 실험은 각각 1회 실행(컴파일러 형성 1회, 지속 2갈래, MESA 1회)으로, 반복 실행 시 성공률이나 재현성은 추정되지 않았다.
지속 실험의 두 갈래(GLM 5.2, DeepSeek V4 Flash)는 테스트셋과 자원 사용이 서로 달라 모델 간 성능 비교로 해석할 수 없다.
MESA 재개발은 star, astero, binary 등 상위 엔진과 전체 EOS 블렌드, REACLIB 데이터셋 전체를 포함하지 않은 13개 핵심 모듈에 한정된다.
포트란과 러스트의 타이머 구현이 서로 다르고(system_clock/cpu_time vs Instant) 호스트 부하에 민감해, 속도 비교는 이 특정 빌드·환경에 한정된 결과다.
재귀적 위임이나 승인 절차 같은 구성 요소가 실제로 결과에 필수적인지 가르는 인과 실험(코드는 고정하고 비코드 기록만 바꾸는 실험 등)은 아직 수행되지 않았다.
왜 중요한가
이 결과는 에이전트 하나를 오래 살리는 대신 '프로젝트 자체'를 영속시키는 조직화 방식으로도 사람이 개입하기 어려운 장기 소프트웨어 개발을 이어갈 수 있음을 보여준다. 대규모 코드베이스를 다루는 개발자나 연구자에게는, 에이전트 교체나 모델 교체가 곧 개발 중단으로 이어지지 않게 만드는 새로운 설계 축을 제시한다는 점에서 의미가 있다.
이 논문의 용어
EvoX Genesis · 논문이 제안하는 시스템 이름. 소프트웨어 프로젝트를 '영속적 재귀 세계'로 표현해 에이전트가 짧게 살아도 개발이 이어지게 한다
영속적 재귀 세계 (persistent recursive world) · 승인된 버전과 저장소 경로 쌍으로 정의되는 로컬 작업 공간. 버전은 유지되고 경로를 통해 새 에이전트가 반복 투입된다
재귀적 위임 · 상위 에이전트가 같은 버전 안에서 다른 경로에 하위 에이전트를 만들어 작업을 넘기는 것. 이 과정 자체는 프로젝트 버전을 바꾸지 않는다
MESA · 별의 진화를 1차원으로 계산하는 오픈소스 천체물리 소프트웨어 모음(Modules for Experiments in Stellar Astrophysics)
c-testsuite / Csmith · C 컴파일러의 정확성을 검증하는 데 쓰이는 외부 테스트 모음 및 무작위 C 프로그램 생성기
