코딩 에이전트의 다음 병목은
더 오래 실행하는 것이 아니라,
더 오래 제대로 개선하는 것이다

사람이 loop 밖으로 빠질 때 개발의 성격이 달라진다

기존 coding agent는 함수 완성에서 repository-level issue 해결까지 확장됐지만, 실제 개발에서는 여전히 사람이 task를 정하고, 중간 판단을 안내하고, 생성된 변경을 검토하고, 실패 시 개입하는 경우가 많다. 논문이 목표로 삼는 autonomous development는 다르다. 사람은 고수준 요구사항만 주고, 이후 에이전트가 빈 workspace에서 시작해 완전한 소프트웨어를 계획·구현·검증한다.

페이지 3의 비교 도식이 강조하듯 human-in-the-loop는 인간이 지속적으로 관찰하고 수정하지만, HoH의 autonomous mode는 Project Planner → Developer → QA Tester를 자동 재호출해 Concept → Prototype → Product의 진화를 이어간다.

궤적이 길어지면 코드보다 개발 상태가 먼저 무너진다

• 초기 requirement와 design decision이 이후 변경과 분리된다.
• 한 곳의 local fix가 다른 component의 constraint를 깨뜨린다.
• 실패한 시도와 suboptimal decision이 누적된다.
• 새 test evidence가 이전 assumption을 무효화한다.
• inspection–repair가 반복되고 이미 완료한 기능을 중복 검증한다.
• 기능 누락이 남아 있는데도 agent가 completion을 선언할 수 있다.

Harness를 최적화하는 연구가 아니라, harness의 장기 참여방식을 구조화한다

관련 연구에서 harness는 LLM이 어떤 정보를 받고, 어떤 action을 실행하며, 결과가 다음 의사결정에 어떻게 들어가는지를 정하는 operational layer다. Prompt/context engineering, external memory, ReAct, multi-agent orchestration이 이 층을 구성해 왔다. AutoHarness, Meta-Harness, Self-Harness는 harness 자체를 synthesis·search·self-modification의 대상으로 삼는다.

HoH의 선택은 다르다. 모델과 base harness를 run 동안 고정한 채, evolving software project에 대한 planning–implementation–independent evaluation을 반복한다. 즉 self-improving harness가 아니라, harness를 이용해 project를 continual-improve하는 상위 orchestration이다.

장기 개발을 어렵게 만드는 세 가지 구조적 문제

고정된 model–harness가 specification을 artifact로 변환한다

여기서 \(S\)는 software specification, \(M\)은 language model, \(H\)는 coding harness, \(A\)는 최종 software artifact다. run 안에서 model, harness, role definition, runtime policy는 고정되지만 development document, software artifact, execution evidence는 iteration마다 진화한다.

Planner, Developer, QA Tester는 같은 모델을 쓰지만 같은 권한을 갖지 않는다

세 역할은 서로 다른 모델이 아니라 같은 harness–model configuration의 독립 invocation이다. 역할별 prompt는 무엇을 읽고·변경하고·반환할지를 정하며, deterministic Runtime이 실제 permission과 output schema를 강제한다.

한 loop는 작지만 국소적으로 완결된 observable behavior를 만든다

Planner는 많은 요구 중 하나의 coherent objective를 선택한다. 단순히 파일 수를 적게 바꾸는 것이 아니다. 관련 component를 함께 수정해야 하나의 사용자 관찰 가능한 기능이 완성된다면 여러 파일을 건드려도 된다. 대신 unrelated refactoring과 opportunistic feature expansion은 loop 밖에 둔다.

boundedness는 failure localization을 쉽게 하고, local completeness는 결과를 실제로 testable하게 만든다. Supplement prompt에서는 blocker와 regression을 product extension보다 먼저 처리하고, 최대 세 개의 달성 가능한 priority를 observable validation requirement로 바꾸도록 한다.

Warm-start, single-writer, shift-left testing

Developer는 \(A_{t-1}\)에서 시작해 \(D_t\)를 구현한다. Planner와 QA는 artifact를 읽을 수 있지만 production code를 바꾸지 못한다. 따라서 \(A_{t-1}\rightarrow A_t\)의 책임과 lineage가 모호해지지 않는다.

개발 중에는 baseline–change–retest를 반복한다. 수정 직후 관련 실행경로와 adjacent regression surface를 검사해 실패 원인을 가까운 곳에서 드러낸다. 그러나 Developer self-test는 candidate를 제출할 준비가 됐는가를 판단할 뿐, product requirement를 만족했다는 최종 acceptance가 아니다.

Implementation claim과 acceptance decision을 분리한다

QA Tester는 updated artifact를 frozen read-only candidate로 받는다. build/execution의 deterministic check와 함께 black-box test로 사용자 관찰 동작·state transition·end-to-end flow를 확인하고, white-box test로 source·configuration·resource binding·runtime state·log를 보강한다.

후보를 freeze하면 evidence가 서로 다른 artifact version을 섞지 않는다. read-only QA는 검증 중 candidate를 몰래 고치는 것도 막는다. 완료 여부는 구현자의 설명이 아니라 candidate-bound observable evidence가 결정한다.

HoH의 최소 실행 알고리즘

iteration budget \(T\)만큼 반복한 뒤 \(A_T\)를 반환한다. 중요한 것은 같은 loop를 반복하는 것이 아니라, 다음 loop의 의사결정이 이전 artifact와 이전 evidence를 동시에 상속한다는 점이다.

Artifact \(A_t\)와 Evidence \(E_t\)는 서로 대체할 수 없다

코드만 넘기면 다음 agent는 왜 이 구조가 선택됐는지, 어떤 failure가 이미 알려졌는지, 무엇을 regression 없이 보존해야 하는지를 다시 추론해야 한다. Artifact continuity가 development를 incremental하게 만들고, evidence-conditioned objective selection이 development를 iterative하게 만든다.

검증은 claim–record–status의 구조화된 tuple로 남는다

Evidence는 단순한 테스트 통과/실패 로그가 아니다. 어떤 claim을 어떤 public execution record로 검증했고, 상태가 verified인지 gap인지 남긴다. source code가 존재한다는 사실만으로 behavioral verification으로 인정하지 않는다.

verified record는 다음 Planner의 preservation constraint가 되고, gap record는 update target과 follow-up validation requirement가 된다.

player control은 검증됨, result state는 gap이라는 기록이 다음 plan을 바꾼다

Supplement의 normalized report 예시는 player input이 avatar motion을 바꾼다는 claim을 replay와 runtime trace로 verified 처리한다. 이 결과는 verified player movement를 보존하라는 preservation constraint로 바뀐다. 반면 objective 완료 후 result screen이 보이지 않는 screenshot은 gap으로 기록되고 visible completion state를 추가하고 replay하라는 다음 update target이 된다.

Dedicated memory module 대신 파일시스템에 materialized history를 둔다

HoH는 긴 interaction history를 그대로 prompt에 싣지 않는다. plan, report, history, artifact를 filesystem에 유지하고 concise categorized index만 먼저 보여준 뒤, 필요한 세부내용을 on demand로 불러온다. MCP server, expert model, domain algorithm 등 tool은 role별로 조직하고, lightweight Markdown skill로 사용법을 제공한다.

또한 표준 capability를 매번 새로 구현하지 말고 기존 resource를 재사용하도록 유도한다. agent role과 iteration 수준의 versioned history를 유지해 큰 regression이 생기면 이전 verified state로 돌아가고, 유사 실패가 재발하면 이전 evidence를 diagnosis에 재사용한다.

자유로운 reasoning과 엄격한 operational boundary를 동시에 둔다

HoH는 agent가 어떤 reasoning chain이나 tool sequence를 써야 하는지 처방하지 않는다. 대신 Runtime이 input visibility, tool/write permission, output schema를 강제한다. schema를 어기는 output은 retry 대상이다.

workflow를 규정하지 않고 verifiable output을 규정한다는 것이 이 설계의 중요한 특징이다. autonomy는 내부 전략에 남겨두되, role별 책임과 evidence integrity는 deterministic contract가 잡는다.

Benchmark score가 development loop로 새지 않는다

Hidden test, benchmark score, private rubric, evaluation formula, evaluator rationale는 role prompt나 evidence bundle에 포함하지 않고 다음 iteration에 반환하지 않는다. Planner와 QA는 public task specification과 observable execution만 사용한다.

이는 benchmark를 reward feedback source로 사용하는 것이 아니라, public evidence로 프로젝트를 개선하고 private evaluator는 마지막 외부 측정에만 사용하는 분리다.

Underlying agent를 바꿔도 protocol의 방향이 유지되는가

Vanilla와 HoH는 같은 initial state, 같은 model, 같은 native harness setting, 같은 public task material과 benchmark tool을 사용하고, HoH protocol의 적용 여부만 다르게 한다. main experiment의 HoH는 \(T=3\)이다.

재현성 해석에서 놓치면 안 되는 실험 경계

각 task–condition score는 한 번의 valid run에서 얻는다. infrastructure나 model-provider transport error로 실패한 attempt는 replicate로 세지 않고 대체한다. 따라서 aggregate는 여러 generation의 평균이 아니라 task들의 평균이다.

선택한 client들은 공통 reproducible generation seed를 제공하지 않았고 temperature/top-p도 override하지 않았다. 즉 benchmark 범위의 평균 개선은 강하지만, 동일 task에서의 stochastic generation variance를 반복실험으로 직접 추정한 결과는 아니다.

Artifact quality, dominance, behavioral reconstruction, token efficiency

GameCraft-Bench의 \(M,D,V,A\)는 Core Mechanics, Content Depth, Functional Visuals, Art and Presentation이다. compile/run에 실패하면 \(B=0\)으로 전체 score가 0이 된다. component 분석의 95% CI는 20,000회 task bootstrap, seed 20260729로 구한다.

FrontierSWE는 task-specific official reward를 사용하고, 12개 harness–condition configuration 중 나머지 11개와 같은 task에서 pairwise 비교한 expected score를 domain별로 평균한 뒤 Implementation·Performance·Research를 동일 가중 macro-average한 Dominance를 함께 보고한다. ProgramBench는 hidden behavioral test의 평균 pass rate다.

Token accounting은 provider-reported coding-harness input+output이고 benchmark evaluation은 제외한다. cache accounting이 provider마다 달라 cross-provider cost 비교가 아니라 configuration 내부 비교에만 사용한다.

실행 환경과 공개 범위를 명시한다

GameCraft는 Ubuntu 24.04.3, Intel Core i7-14700, 64GB RAM, Python 3.12.3, Godot 4.6.2, Xvfb-backed display capture 환경이다. FrontierSWE는 official task container를 run-local Docker daemon에서 실행하고 task가 요구할 때 NVIDIA H200을 passthrough한다.

Anonymous reproducibility package에는 core HoH implementation, role prompt template, GameCraft adapter, evaluated harness–model wrapper가 포함되지만 benchmark repository/task data, raw run artifact, analysis record, environment file, credential, provider secret, hidden evaluator content는 포함하지 않는다.

Multi-day FPS는 단일 재미 점수로 뭉개지 않는다

Supplement는 source-blinded Fusepoint playtest에 full Player Experience Inventory(PXI)를 사용한다. 10개 construct 각각 3문항, 공식 7점 척도(-3~+3)를 사용하고 Enjoyment는 별도 3문항 outcome으로 계산한다. 논문은 validation 결과에 따라 10개를 합친 global PXI total을 만들지 않는다. 5개 Functional, 5개 Psychosocial의 descriptive average는 compact summary일 뿐 validated higher-order scale로 취급하지 않는다.

GameCraft 향상은 mechanics 하나가 아니라 content·visual·presentation까지 걸친다

HoH@3는 세 configuration 모두에서 GameCraft의 네 aggregate quality component를 개선한다. gain 범위는 Codex 20.00–25.56, OpenCode 19.25–34.63, Pi 11.32–25.38 points다. Codex의 Functional Visuals는 48.67→74.23, Art and Presentation은 45.28→65.28이다.

FrontierSWE의 Codex 설정은 3회 이후에도 향상이 이어진다

같은 15 FrontierSWE task에서 Codex + GPT-5.5를 HoH@10까지 확장하면 Dominance는 HoH@3의 39.33%에서 HoH@10의 72.67%로 상승하고, HoH@9에서 76.00%로 최고점을 찍는다. 이 분석에서 Vanilla는 27.33%다.

즉 장기 loop의 potential을 보여주지만, 이 10-loop extension은 모든 model/harness/benchmark에 수행된 것은 아니다.

그냥 세 번 더 코딩했기 때문이라는 설명만으로는 충분하지 않다

같은 pass 수에서 HoH의 이득은 +10.13, +9.85, +13.28 points다. 더 흥미로운 비교는 HoH@2가 5.67M tokens로 64.84를 얻어, 6.33M tokens를 쓴 3-pass Vanilla Continuation 58.24보다 높다는 점이다. 세 번째 pass 기준 additional million tokens당 quality gain은 Vanilla Continuation 2.32, HoH 3.77로 보고된다.

계획 갱신, evidence feedback, warm-start는 각각 실제 기여한다

Plan update를 없애면 첫 \(D_1\)을 계속 재사용하고, evidence feedback을 없애면 QA는 하되 결과가 다음 plan으로 가지 않으며, warm-start를 없애면 매 iteration마다 빈 \(A_0\)에서 다시 만든다. 특히 warm-start 제거 시 token이 8.41M→11.12M으로 증가한다. 장기 성능은 더 많은 pass보다 상태의 올바른 전달 구조에 의존한다는 직접적인 ablation evidence다.

점수 차이가 실제 playable behavior의 차이로 나타난다

Supplement의 Figures 12–16은 15개 family에서 대표 game 하나씩을 Vanilla→HoH@1→@2→@3로 비교한다. 전체 방향은 개선이지만 intermediate iteration과 개별 dimension은 항상 monotonic하지 않다.

Aggregate victory와 모든 task의 승리는 같은 문장이 아니다

논문 본문은 모든 reported aggregate task category에서 HoH@3가 Vanilla를 앞선다고 보고하지만 supplementary per-task table에는 negative delta도 존재한다. 예를 들어 OpenCode의 Autobattler는 −12.12, Pi의 Spire Descent는 −15.65, Pipe Crisis는 −15.61, Border Check는 −10.10, Space Colony는 −4.39다.

따라서 HoH는 어떤 task에서도 회귀하지 않는 방식이 아니라, 전체 분포와 aggregate quality를 강하게 개선하면서도 개별 task regression은 여전히 남는 방식으로 읽는 것이 정확하다.

비용은 줄곧 같은 방향으로 움직이지 않는다

FrontierSWE aggregate resource table에서 Codex는 Vanilla 103.43M tokens/18.65h에서 HoH@3 71.71M/10.28h, OpenCode는 384.84M/32.00h에서 229.77M/16.16h로 줄지만, Pi는 541.73M/40.19h에서 @1 1117.11M/49.05h, @2 988.00M/21.53h, @3 717.69M/37.15h로 복잡하게 움직인다. provider별 cache accounting이 달라 cross-provider token 비교는 적절하지 않다.

빈 workspace와 PRD만 주고 5분짜리 narrative FPS를 만든다

Fusepoint는 single-player bomb-defusal mission이다. product contract는 두 control point의 순차 점령, final objective의 three-stage defusal, 세 encounter region에 3·5·10으로 배치된 총 18 enemies, success와 detonation의 distinct branch를 요구한다. 3D environment·external asset·mission logic·combat·narrative progression·interface feedback·runtime reliability가 함께 동작해야 한다.

PRD는 player-observable acceptance criterion은 제공하지만 engineering decomposition, implementation order, validation plan은 열어 둔다. HoH가 이를 executable Godot project의 increment sequence로 바꾼다.

70 loop의 계획·구현·디버깅·테스트·acceptance는 사람이 하지 않는다

case study는 Codex CLI + GPT-5.6-Sol, high reasoning으로 수행됐고 analysis cutoff에서 70 development loops를 완료했다. 사람의 개입은 network/API availability 복구에 제한됐으며 planning, implementation, debugging, testing, acceptance에는 개입하지 않았다.

초록과 Figure 1 설명은 multi-day deployment를 more than 70 iterations로 표현하고, case 분석 본문은 cutoff 시점 70 loops를 상세 분석한다. 이 글은 두 표현의 source nuance를 그대로 보존한다.

코드 편집만으로는 game development가 끝나지 않는다

multi-day case에서는 Godot 4.7을 개발/runtime environment로 사용하고 Godot MCP로 engine-level development·execution·debugging을 수행한다. asset-generation skill은 image/3D/video의 target visual style·dimension·format을 안내하고, UI/UX skill은 시각적 일관성을, testing skill은 scenario-specific test와 debugging을 지원한다. 외부 asset은 CC0/CC BY 등 재사용 가능한 license와 attribution을 보존한다.

Tester는 screenshot/smoke test뿐 아니라 live keyboard input에 대한 game response, audio behavior, 3D asset integration도 검사한다.

건설 → 확장 → 안정화로 backlog의 의미가 바뀐다

닫힌 issue도 다시 열릴 수 있어야 장기 개발이 정직해진다

Reopened issue는 실패한 behavior뿐 아니라 과거 verification history도 연결한다. 따라서 regression repair가 최신 source만 보고 재발견해야 하는 문제가 아니라 다음 Planner가 바로 다룰 explicit work item이 된다.

장기 autonomy에서 중요한 것은 issue 수를 단조 감소시키는 것이 아니라, capability growth가 새 failure를 드러낼 때 이를 기록하고 다시 우선순위화할 수 있는 능력이다.

Versioned workspace + issue history + evidence packet이 두 종류의 continuity를 만든다

GitHub commit/issue history와 각 loop의 development document, versioned workspace, issue table, evidence packet을 유지한다. workspace continuity는 구현을 누적하고, evidence/issue continuity는 unfinished work·verified behavior·regression을 다음 planning에 공급한다.

논문이 직접 지지하는 결론

• 세 benchmark × 세 harness–model configuration에서 HoH@3가 corresponding Vanilla aggregate를 앞선다.
• 같은 pass 수를 통제한 GameCraft comparison에서도 HoH가 repeated Vanilla development보다 높다.
• Plan update, evidence feedback, artifact warm-start를 하나씩 제거하면 성능이 떨어진다.
• Codex FrontierSWE에서 10 loop까지 추가 improvement가 관찰된다.
• 한 FPS project에서 70 loop 동안 capability growth, issue discovery, repair, regression reopening, stabilization이 versioned evidence와 함께 지속된다.

과도하게 일반화하면 안 되는 지점

• 각 task–condition은 한 번의 valid run이므로 model stochasticity에 대한 repeated-run confidence는 제공하지 않는다.
• 10-loop 장기 benchmark 결과는 Codex+FrontierSWE에 한정된다.
• multi-day 사례는 하나의 game project이며, 일반 enterprise software 전체의 다일 autonomous development를 직접 입증하지 않는다.
• 일부 individual task는 HoH@3에서도 Vanilla보다 낮아진다.
• network/API availability 복구에는 사람이 개입했으므로 infrastructure까지 완전 무인인 조건은 아니다.
• multi-day case는 game-specific tool과 skill을 사용한다. 다른 domain으로의 transfer는 future work다.
• provider별 token accounting 차이 때문에 cross-provider cost ranking을 만들 수 없다.

Harness Engineering의 다음 단위는 한 agent보다 개발 상태 전이에 가깝다

이 글의 해석으로 보면 HoH는 agent capability를 prompt trick이나 memory 크기로만 설명하지 않는다. 핵심 계산 단위는 한 번의 LLM call이 아니라, 검증된 artifact–evidence pair가 다음 bounded objective로 이동하는 state transition이다.

이는 harness engineering을 모델 주변 도구를 잘 붙이는 일에서 장기 autonomy의 state machine과 evidence contract를 설계하는 일로 넓혀 볼 근거를 제공한다. 다만 이것은 논문의 결과를 바탕으로 한 시스템적 해석이며, 논문이 일반 AGI architecture를 직접 주장한 것은 아니다.

게임 밖의 real-world software로 확장하는 것이 다음 검증이다

저자들은 더 다양한 game과 다른 software system으로 HoH를 확장해 autonomous software development의 일반 framework로 발전시키는 것을 future work로 제시한다. 다음 연구에서는 multi-day multi-repository systems, infrastructure change, security-sensitive workflows, stochastic replication, cost-aware stopping, cross-project skill transfer 같은 조건에서 artifact/evidence continuity가 얼마나 유지되는지를 검증할 필요가 있다. 앞의 첫 문장은 source fact이며, 뒤의 구체적 예시는 이 글의 연구 확장 제안이다.

Golden Circle로 다시 읽은 Harness-of-Harness