모델은 자신의 실행체계를 직접 만들고 진화시킬 수 있는가

가중치가 같아도 harness가 바뀌면 성능이 달라진다

논문은 GPT-5가 Terminal-Bench 2.1에서 Terminus 2 harness를 사용할 때 35.2%, Codex CLI 안에서는 49.6%를 해결한다는 사례로 시작한다. 모델 weights는 같지만 execution loop, tool protocol, context, recovery, verification이 달라지면 14.4 percentage-point 차이가 생긴다. 이 예시는 harness가 단순 glue code가 아니라 모델의 잠재 능력을 행동으로 변환하는 실행 아키텍처임을 보여준다.

현실 배포에서 인간 엔지니어가 해오던 일을 benchmark가 숨긴다

대부분의 benchmark는 task, reward/judge, scaffold가 이미 준비된 뒤에 시작한다. 그러나 실제 deployment에서는 informal requirement를 success criterion으로 바꾸고, feedback signal을 만들어 내고, tools/context/state/lifecycle/verification을 포함한 실행체계를 구축하는 일이 먼저 필요하다. 논문은 이 현실의 대표 역할로 Forward-Deployed Engineer(FDE)를 든다.

FDE의 성공 기준은 demo가 아니라 시스템이 고객 환경에서 실제로 쓰이고, 계속 작동하며, 요구사항 변화에 따라 개선되는가이다. HarnessDev는 이 중 세 번째 층, 즉 실행체계를 만들고 유지하는 능력을 분리해 평가한다.

기존 benchmark는 harness를 ‘설정’으로 취급했다

SWE-bench, GAIA, WebArena, τ-bench, AgentBench 같은 대표 benchmark는 선택된 harness 아래에서 task success를 측정한다. 최근 연구는 harness representation, automated agent design, self-improving agents로 이동했지만, 하나의 모델이 runnable persistent harness를 처음 만들고 이후 계속 개선하는 전체 lifecycle은 충분히 측정되지 않았다.

특히 자기 harness를 수정하는 것은 일반 코드 편집과 다르다. 수정 대상이 다음 task에서 자신이 관찰하고 계획하고 복구하는 방식 자체이기 때문이다. 따라서 harness evolution은 failure trace로 자기 행동의 한계를 읽고, structural bottleneck을 진단하고, one-off patch가 아니라 재사용 가능한 capability gain으로 바꾸는 메타 수준의 engineering 문제이다.

Creator는 H를 만들고, Executor는 H 안에서 task를 푼다

\(L_C\)는 creator LLM, \(D\)는 development environment, \(H\)는 생성된 harness, \(L_E\)는 downstream executor LLM, \(x\)는 task, \(J\)는 evaluator이다. 핵심은 \(H\)가 완성된 뒤 freeze된다는 점이다. Creator가 개발 중 보았던 환경과 실제 downstream execution을 분리함으로써 harness 자체의 재사용 가능성을 측정한다.

여섯 책임이 실제 실행 경로에 있어야 한다

논문은 이 여섯 글자를 파일 구조로 강제하지 않는다. 중요한 것은 책임이 선언되어 있는가가 아니라 실제 main execution path에 참여하는가이다. 이후 architecture analysis에서 dead code와 unreachable mechanism을 따로 조사하는 이유도 여기에 있다.

runnable하지만 정책은 없다

Creation의 시작점 \(H_{seed}\)는 stable CLI, model configuration parsing, result/trajectory/log writer, low-level passive primitives만 제공한다. Paths, files, search, process, LLM gateway, artifact I/O는 사용할 수 있지만 orchestrate되지 않는다.

unmodified seed는 task를 시도하지 않고 partial artifact를 남기며 다섯 downstream benchmark에서 모두 0점을 받는다. 따라서 nonzero Creation score는 creator가 추가한 execution logic에서 나와야 한다.

여섯 frontier LLM이 같은 약한 seed를 서로 다르게 개발한다

Creator는 Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro, Qwen 3.7 Max, Seed 2.0 Pro이다. GPT-5.5는 Codex 0.144.3을 development environment로 쓰고, 나머지는 Claude Code 2.1.177을 사용한다. provider default에 따라 sampling 설정은 일부 다르며, 모두 high reasoning effort와 streaming을 사용한다.

“나에게 잘 맞는 harness”와 “다른 모델에도 좋은 harness”를 분리한다

Unified-Eval도 완전한 causal isolation은 아니다. harness–model interaction 자체가 복잡하기 때문이다. 그러나 같은 harness가 executor를 바꿨을 때 어떻게 무너지는지 보여주는 강력한 probe가 된다.

비싼 harness가 좋은 harness라는 보장은 없다

각 frozen harness는 native task score와 executor-model token consumption을 함께 보고한다. Creator가 harness를 개발하는 데 사용한 token은 execution cost에서 제외한다. 논문은 cost-adjusted composite score로 합치지 않고 capability와 cost를 두 축으로 직접 보여준다.

Search와 Code는 장기 control flow를 요구한다

저자들은 Search/Research가 long-horizon information seeking을 요구해 가장 큰 격차가 생긴다고 분석한다. Code 역시 repository inspection, editing, verification을 다수 turn에 걸쳐 조율해야 한다. 반면 short-form writing은 context와 output contract가 상대적으로 단순하고, MLE experimentation에서는 generated harness가 선택된 reference를 넘어서는 경우도 있다.

Data 실패의 77.8%가 harness defect로 attribution되었다는 결과는 executor model capability만 개선해도 해결되지 않는 병목이 존재함을 보여준다.

좋은 harness는 누구에게 좋은가

executor를 Gemini로 고정하면 순위가 크게 바뀐다. Qwen과 DeepSeek의 일부 Data/Search harness는 더 강한 executor 덕분에 좋아지지만, Opus는 반대 현상을 보인다. Opus SWE-Pro는 Self-Eval 69.3에서 fixed Gemini 33.0으로 떨어지고, Writing도 84.6에서 74.2로 감소한다.

Opus Search harness의 duplicate-query rate는 executor 변경 뒤 10.1%에서 88.2%로 급증한다. deduplication, review, termination rule이 원래 runtime의 행동 패턴에 맞춰져 있었기 때문이다. runnable portability와 capability portability는 다른 문제이다.

token을 많이 쓰면 점수가 올라간다는 단순 법칙은 없다

MLE-bench execution token은 creator 사이에서 약 19배 차이가 난다. Appendix Figure 9의 대표 비교에서 GPT-5.5는 medal 19.1을 29.3M tokens로 얻고, DeepSeek V4는 거의 같은 19.6을 208.4M tokens로 얻는다. 비슷한 품질에 거의 한 order의 cost 차이가 발생한다.

GPT-5.5는 feedback-driven monolith, Opus는 up-front modular architecture를 택했다

10번의 full pair budget과 5-task probes로 version search를 수행한다

Evolution은 creator 자신의 frozen RQ1 Code harness \(H_0\)에서 시작한다. feedback pair는 SWE-Pro 100 tasks와 Terminal-Bench 89 tasks의 동일 commit 평가이며, 둘 다 완료되어야 official version이 된다. post-\(H_0\) full-evaluation pair budget은 10회이다.

두 charged pair 사이에는 동일한 first-five-task subset을 사용하는 probe를 최대 2회 쓸 수 있다. 한 task가 20 points를 움직이므로 aggregate probe score는 매우 noisy하며, 공식 score는 full evaluation에서만 나온다. local execution은 unlimited/free signal이다.

모든 trajectory가 끝난 뒤 official version 각각을 630개 SWE-Pro held-out tasks에 다시 실행한다. 이 score는 creator에게 절대 보이지 않아 edit, stopping, final selection에 사용할 수 없다.

64번의 version switch 중 ‘명확한 개선’은 드물다

그 밖에 cross-benchmark trade-off 3회, no measurable change 7회, executable code change가 없는 switch 1회가 있다. 같은 commit도 pair score가 약 ±4.75 points 변할 수 있어 작은 delta만 보고 code effect를 attribution하기 어렵다.

feedback와 held-out score가 같은 방향으로 움직인 것은 comparable 64 switches 중 34회, 53.1%이다. creator가 선언한 9개 final version 중 held-out optimum과 일치한 것은 2개뿐이다. visible score 최적화는 local search signal은 되지만 final model selection signal로는 불안정하다.

control flow는 많이 바꾸지만 state와 standalone verifier는 거의 건드리지 않는다

declared version의 median change는 8 files, +476/-38 lines이다. 64 official switches 중 58은 execution/control flow, 37은 tools, 17은 lifecycle recovery, 16은 context를 바꾸고 state는 4회뿐이다. standalone verifier를 수정한 switch는 없다.

새 code가 실행되는 것도 보장되지 않는다. 169 new functions/classes 중 113은 entry point에서 reachable, 31은 dead code를 통해서만 reachable, 25는 caller가 없다. 즉 self-improvement가 code accumulation으로 보일 때 behavioral reachability를 따로 측정해야 한다.

feedback은 많지만 failure를 깊게 읽지 않는다

9 lineages 중 8개는 results를 읽고 edit하고 re-evaluate하고 version을 선택하는 full loop를 적어도 한 번 수행한다. 그러나 dedicated trajectory interface 호출은 전체에서 두 번뿐이며, explicitly inspected cases는 lineage에 따라 189 feedback tasks의 0.5%–40.2%에 그친다. 많은 creator가 custom script와 small probe에 의존한다.

probe가 full distribution을 대표하지 않는 사례도 선명하다. 한 GPT-5.5 candidate는 Terminal first-five probe를 모두 통과하지만 full set에서는 0.584 score에 그친다. evolution의 병목은 edit 능력보다 diagnosis와 evidence selection일 수 있다.

좋은 update는 ‘실패 → 구체적 원인 → 검증 가능한 구조 변경’에서 나온다

benchmark는 단순 “코드를 고쳐라”가 아니라 실험 운영 자체를 요구한다

Appendix E.2의 RQ2 prompt는 evaluation을 asynchronous full-pair submission으로 정의하고, per-benchmark 2 full lanes + 2 probe lanes, 10-pair fixed budget, round당 2 probes, immutable commit snapshot, append-only feedback stream, declare-final 규칙을 명시한다. controller는 best-version selection이나 rollback을 대신하지 않는다.

즉 HarnessDev의 Evolution은 agent에게 software engineering뿐 아니라 experiment management와 noisy evidence under budget를 요구한다.

“Can LLMs create and evolve their own harness?”에 대한 증거 기반 답

model-external learning을 별도 축으로 본다

논문의 결론은 흥미로운 관점을 제시한다. intelligence가 축적되는 장소를 model parameters 하나로 제한하지 않는다. harness는 failure와 feedback을 통해 바뀌고, source code와 git history에 남으며, inspectable하고 testable하고 reusable하다.

그렇다고 논문이 heuristic learning이 parameter training을 대체한다고 주장하지는 않는다. parameter learning과 model-external harness learning을 서로 다른 축으로 측정해야 한다는 것이 더 정확한 해석이다.

harness quality는 독립적인 software property만이 아니다

Self-Eval과 Unified-Eval 차이는 harness가 runtime model의 말투, tool-call habits, step distribution, stopping behavior와 co-adapt할 수 있음을 보여준다. Opus harness의 120-step limit이나 Search dedupe rule처럼, 특정 model에서는 잘 맞지만 다른 model에서는 성능을 붕괴시키는 parameter가 생긴다.

논문에서 반복해서 살아남는 engineering 패턴

• 실패를 먼저 분류한다. Opus Evolution의 가장 좋은 update는 189 cases를 읽고 hidden-grader interface failure를 별도 bucket으로 만든 뒤 나왔다.
• finish 전에 real verification을 강제한다. GPT-5.5의 가장 큰 positive jump도 premature completion을 막는 final-review gate에서 발생했다.
• 현재 artifact를 다시 보여 준다. git diff나 non-git file state를 모델 memory에 맡기지 않고 explicit review context로 공급한다.
• rollback과 version selection을 설계한다. latest version이 best가 아니며, noisy feedback를 계속 추적하면 lucky run에 과적합할 수 있다.
• state를 선언하는 것과 persistence를 실제로 쓰는 것을 구분한다. source code feature count보다 execution evidence가 중요하다.
• cost를 함께 본다. 더 많은 token이 더 높은 score를 보장하지 않는다.

generated harness는 untrusted code로 다뤄야 한다

benchmark는 public suite와 open-source harness를 사용하고 human-generated content를 새로 수집하지 않는다. prohibited behavior와 post-hoc audit를 두었고 이 연구에서 violation은 관찰되지 않았다.

그러나 automated harness construction은 insecure tool use를 증폭할 수 있다. 논문의 container boundary는 reproducibility를 위한 것이지 공격 방어용 containment가 아니다. 생성된 harness를 재사용할 때는 논문보다 더 강한 isolation을 적용해야 한다는 것이 authors의 명시적 권고이다.

HarnessDev 이후의 여덟 가지 연구 질문

HarnessDev를 여섯 문장으로 압축하면

논문의 부록이 추가로 고정하는 재현성 경계