ProgramBench - Can Language Models Rebuild Programs From Scratch

John Yang, Kilian Lieret, Parth Thakkar, Dmitrii Pedchenko, Sten Sootla, Emily McMilin, Pengcheng Yin, Rui Hou, Gabriel Synnaeve, Diyi Yang, Ofir Press. "ProgramBench: Can Language Models Rebuild Programs From Scratch?", arXiv 2605.03546, 2026.

AI에게 EXE 파일과 매뉴얼만 주고 "이 프로그램의 소스를 다시 짜봐"라고 했을 때, 지금 가장 비싼 모델조차 0%를 받습니다. 정확히는 200개 과제 중 모든 테스트를 통과한 건 0건, 그나마 Claude Opus 4.7이 95% 이상의 테스트를 통과한 비율이 3%입니다. 나머지는 사실상 전부 부분 점수입니다.

ProgramBench는 그 결과를 만들기 위해 설계된 벤치입니다. SWE-bench가 "이 레포에서 이 한 줄 버그를 고쳐줘"였다면, ProgramBench는 "이 바이너리의 행동을 그대로 재현하는 프로그램을 처음부터 만들어줘"입니다. 빈칸 채우기에서 백지 답안으로 한 단계 올라간 셈입니다. 그리고 결과는 정직합니다 — 아직 모두 0%입니다.

저자

저자 명단은 Meta FAIR, Meta TBD, Stanford, Harvard 네 곳이 섞여 있습니다. 1저자는 John Yang(공동 1저자 Kilian Lieret), 시니어는 Ofir Press입니다.

John Yang은 Stanford CS PhD로 SWE-bench·SWE-agent·mini-SWE-agent의 메인 저자입니다. 그가 만든 SWE-bench는 지금까지 200만 회 넘게 다운로드되며 사실상 코드 에이전트 평가의 표준이 됐습니다. Kilian Lieret도 같은 라인의 공저자로, mini-SWE-agent의 핵심 기여자입니다. ProgramBench의 데이터 수집 파이프라인이 전부 mini-SWE-agent + Claude Sonnet 4.5로 도는 건 자연스러운 흐름입니다.

시니어 저자 Ofir Press는 Princeton 출신으로 현재 FAIR NYC의 research scientist입니다. ALiBi, SWE-bench, SWE-agent 라인의 핵심 인물이고, 평가 벤치마크의 인플레이션과 포화를 가장 일찍 비판해 온 연구자 중 한 명입니다.

Meta FAIR 쪽에서는 Gabriel Synnaeve가 합류했습니다. Code Llama 리드, Code World Model(CWM) 시니어 코어 컨트리뷰터로, 코드 생성·실행 피드백 RL 라인의 책임자입니다. Stanford 쪽에서는 SALT 랩의 Diyi Yang이 이름을 올렸습니다. NSF CAREER·Forbes 30 Under 30·IEEE AI 10 to Watch 수상자입니다.

요약하면 SWE-bench 라인이 FAIR 합류 후 만든 첫 번째 후속 벤치 — 라고 읽으면 됩니다.

배경

SWE-bench가 풀고자 했던 문제는 "GitHub 이슈 받아서 진짜 PR을 만들 수 있나"였습니다. 입력은 이미 존재하는 레포 + 이슈 + 일부 코드, 출력은 작은 patch. 평가는 hidden test가 통과하는지로 합니다. 좋은 벤치였지만 본질은 빈칸 채우기에 가깝습니다. 아키텍처는 사람이 이미 잡아 둔 상태로 모델에게 던져집니다.

ProgramBench는 그걸 정면으로 뒤집습니다. 입력은 바이너리 + 문서, 출력은 그 바이너리의 동작을 재현하는 소스 코드 전체와 빌드 스크립트입니다. 언어 선택, 모듈 분할, 자료구조 설계, 에러 처리 — 모든 결정이 모델 몫입니다.

평가 방식도 다릅니다. 소스 레벨 일치를 보지 않고, 같은 입력에 대해 같은 관찰 가능한 동작(표준 출력, 종료 코드, 파일 시스템 변화)을 내는지만 봅니다. 저자들은 이걸 implementation-agnostic 평가라고 부릅니다. Church-Turing 명제의 직관과 잘 맞습니다 — 같은 함수를 계산하는 프로그램은 무수히 많고, 어느 구현을 골라도 외부에서 보면 같아야 합니다. 모델이 Rust 원본을 Python으로 다시 써도 동작만 같으면 통과입니다. 이건 단순한 "다른 언어로 다시 쓰기"가 아니라, 모델이 사전학습 코퍼스에서 같은 함수의 같은 구현을 토씨 그대로 토해낼 가능성을 차단하는 장치이기도 합니다.

어떻게 만들었나

데이터 수집 파이프라인은 자동입니다. 사람이 라벨링하지 않고, mini-SWE-agent가 Claude Sonnet 4.5를 백본으로 ubuntu 22.04 Docker 안에서 네 단계를 돕니다.

1. 레포 후보 식별. 컴파일 언어(C/C++, Go, Rust, Java)로 작성된 standalone 실행파일이 나오는 오픈소스 레포만 거릅니다.
2. 빌드 재현. 에이전트가 직접 빌드하면서 성공한 명령 시퀀스를 build.sh 하나로 기록합니다.
3. 행동 테스트 생성. 에이전트가 프로그램·소스·기존 테스트·문서를 탐색하면서 외부 관찰 가능한 동작(stdout/stderr 문자열, 생성 파일 등)에 대한 assertion을 만듭니다. 라인 커버리지를 보면서 누락된 경로에 대한 테스트를 반복 추가합니다. 레포 자체에 e2e 테스트가 있으면 그것도 harvesting 합니다.
4. 구현 디테일 제거. 빌드된 바이너리만 남기고 소스·테스트·빌드 캐시를 모두 떼어냅니다. 바이너리는 execute-only 권한으로 설정해 Ghidra 같은 도구로 리버스 엔지니어링하는 걸 차단했습니다.

품질 보증은 "assertion quality linter"가 맡습니다. 너무 약한 패턴(종료 코드만 보거나, 너무 짧은 substring match만 하거나) 을 잡아내고 에이전트에게 다시 쓰게 시킵니다. 이 린터를 끄면 dummy 프로그램이 통과하는 비율(dummy pass rate)이 18.5%에 달했는데, 켜면 3.7%까지 떨어집니다 — 약 5배 개선입니다.

태스크 worker는 인터넷 없는 Docker에서 돕니다. 컨테이너 자체에 네트워크가 차단됐고, 어떤 언어로 풀어도 자유입니다.

무엇으로 구성돼 있나

총 200개 태스크입니다. 참조 언어는 Rust 107, Go 46, C/C++ 45, 기타 2(Java, Haskell). 작은 CLI 유틸리티부터 거대 시스템까지 폭이 큽니다.

• 압축·인코딩: zstd, xz
• 미디어: FFmpeg
• DB: DuckDB, SQLite
• 언어 인터프리터: PHP, Lua, tinycc
• 검색·텍스트 처리: ripgrep, fzf, jq, gron, ast-grep
• 시각화·문서: typst, doxygen
• 작은 CLI: nnn, hs, bd, melody, cpp-check

규모는 폭이 큽니다. 코드 라인 중앙값 8,635 줄(최대 270만 줄), 코드 파일 중앙값 50개(최대 5,342개), 런타임 의존성 중앙값 10개, 디렉토리 최대 깊이 중앙값 3입니다. 레포 평균 GitHub 별 2,124개, 기여자 22명, 커밋 646개, 평균 나이 7.9년 — 즉 장난감이 아니라 진짜로 사람들이 쓰는 소프트웨어입니다.

생성된 테스트 스위트는 200개 태스크 합쳐 248,853개 함수, 태스크당 중앙값 770개입니다. 자동 생성치고 어마어마한 양입니다.

결과

평가 모델은 9개입니다. Claude Opus 4.7, Opus 4.6, Sonnet 4.6, Haiku 4.5, Gemini 3.1 Pro, Gemini 3 Flash, GPT 5.4, GPT 5.4 mini, GPT 5 mini. 에이전트 스캐폴드는 mini-SWE-agent, 컨테이너는 20 CPU + 60GB RAM, 최대 1,000 step, 최대 6시간입니다.

주요 지표 두 개입니다. % Resolved — 모든 테스트가 통과한 태스크 비율. % Almost Resolved — 95% 이상의 테스트가 통과한 태스크 비율. 후자는 어쨌든 "이 모델이 부분적으로라도 길을 찾았다"는 신호입니다.

Table 2의 메인 결과입니다.

9개 모델 × 200 태스크 = 1,800 런 가운데 모든 테스트를 통과한 케이스는 0건입니다. % Almost 기준으로도 Opus 4.7의 3%가 정점입니다. Sonnet 4.6은 태스크당 27달러를 쓰면서도 Opus 4.7의 절반에 그쳤습니다.

태스크 난이도는 모델 선택과 독립적입니다. nnn, fzf, gron 같은 작은 CLI는 거의 모든 모델이 어느 정도 점수를 받지만, FFmpeg, php-src, typst, ast-grep 같은 대형 시스템은 전 모델이 사실상 0에 수렴합니다. 즉 ProgramBench는 모델의 우열뿐 아니라 태스크의 본질적 난이도도 잡아냅니다.

Ablation — 언어를 바꾸라고 강제하면

저자들은 모델에게 참조 언어와 다른 언어로 풀어라고 강제해 봤습니다. 표절성 회상을 차단하려는 의도입니다. 결과는 직관과 어긋납니다. Opus 4.7과 4.6은 평균 % Tests Passed가 각각 -3.5%p, -8.0%p 떨어졌지만, GPT 5.4·5.4 mini·5 mini는 오히려 +4.2%p 올랐습니다. 이 설정에서 Python으로 푸는 비율이 36% → 51%로 뛰는데, 모델이 Python에서 더 편하게 푼다는 뜻이기도 합니다. 결론: 모델이 어떤 언어로 가장 잘 푸는지 본인도 잘 모릅니다.

Ablation — 인터넷을 열어주면 부정행위

한 가족당 한 모델씩 인터넷을 열어주고, 9명의 LM-as-a-judge가 부정행위(소스 코드 검색·바이너리 래핑)를 판정하게 했습니다.

원본 소스 검색이 부정행위의 79~95%를 차지합니다. 게다가 9개 judge끼리 40~57%의 태스크에서 의견이 갈렸습니다. 결국 ProgramBench가 인터넷을 차단하는 기본값은 합리적입니다.

모델 코드베이스의 구조 — monolithic 편향

여기가 핵심입니다. 75% 이상 테스트를 통과한 207개 솔루션을 골라 원본과 비교하면, 모델이 짠 코드는 사람이 짠 코드와 구조적으로 다릅니다.

• 분량: 모델 평균 1,173 라인 vs 원본 3,068 라인. 솔루션의 85%가 원본보다 짧습니다.
• 파일 수: 모델 중앙값 3개 vs 원본 15개. 60%의 솔루션이 1~3개 파일에 모든 걸 몰아넣습니다.
• 디렉토리 깊이: 모델의 67%가 원본보다 얕습니다(중앙값 1 vs 2). 더 깊은 건 2%에 불과합니다.
• 함수 수와 길이 (≥75% 통과 솔루션):

함수는 훨씬 적게, 함수당 길이는 훨씬 길게. 모듈 분해를 거의 하지 않는다는 뜻입니다. 사람이 utils/parser/cli 식으로 나눠 둔 걸 모델은 main.* 하나에 다 쏟습니다.

언어 선택 매트릭스

참조가 Rust일 때 모델은 Rust 44%, Python 41%로 답합니다. 참조가 C/C++일 때는 C/C++ 46%, Python 40%. 참조가 Go일 때만 Go 70%로 같은 언어를 따라갑니다. 즉 모델은 Go 빼고는 어지간하면 Python으로 도망갑니다. 사전학습 코퍼스의 분포가 그대로 나옵니다.

에이전트 행동 패턴

행동 분류 결과도 흥미롭습니다.

• 턴 수 중앙값: Sonnet 4.6 868회(최장 1,978회), Opus 4.7 157회, Gemini 3.1 Pro 92회, GPT 5.4 17회.
• 행동 분포: 모든 모델이 write(코드 작성)에 가장 많이(38.7~48.7%) 쓰고, probe(레퍼런스 바이너리 호출)이 두 번째(22.6~34.1%). read는 13~16%.
• GPT 5.4는 코드의 96%를 한 번의 turn에 다 작성합니다. Opus 4.7은 67%, Sonnet 4.6은 44%, Gemini 3.1 Pro는 53%. 즉 GPT 5.4는 거의 single-shot 생성기처럼 작동하고, Claude 계열은 점진적으로 빌드합니다.
• 파일 mutation 평균: Gemini 3.1 Pro가 압도적으로 많습니다(생성 61.2, 수정 10.1, 삭제 9.4 — Opus 4.7의 8배 가까이).

요약하면 같은 mini-SWE-agent 스캐폴드 위에서도 모델마다 작업 스타일이 극단적으로 다릅니다. 이건 ProgramBench가 모델 capability뿐 아니라 작업 습관까지 드러낸다는 신호이기도 합니다.

회고

저자들이 짚는 한계는 두 갈래입니다.

첫째, 생성된 테스트 스위트는 라인 커버리지 평균 79.7%, 중앙값 86.2%로 사람이 쓴 native 스위트(평균 56.8%, 중앙값 64.3%)보다 오히려 높습니다. 그러나 어떤 finite test suite도 실행파일의 모든 동작을 포착할 순 없습니다. 12개 dedicated behavioral test suite 비교에서도 6개에서 native를 넘고 12개 중 10개에서 10%p 이내였습니다 — 합리적이지만 완벽하지는 않습니다.

둘째, 평가는 인터넷 차단·바이너리 execute-only를 강제했지만, 부정행위 감지는 LM-as-a-judge 9명도 40~57% 불일치를 보일 만큼 어렵습니다. 그래서 기본값은 차단입니다.

벤치 자체의 한계도 있습니다. 200개 태스크는 컴파일 언어 위주이고, 동적 언어·GUI 앱·OS 커널·임베디드는 빠져 있습니다. 그리고 6시간 + 1,000 step 한도는 사실상 거의 닿지 않습니다 — 모든 모델이 평균 98.1% 트라젝토리에서 자발적으로 종료합니다. 즉 시간이 부족해서 0%가 나온 게 아니라, 시간을 더 줘도 모델이 그 이상은 못 갑니다.

정리

• ProgramBench는 포화되지 않은 코딩 벤치입니다. 9개 모델 × 200 태스크에서 완전 해결 0건, 95% 이상 통과 최대 3%. 향후 1~2년치 진척을 그대로 측정할 헤드룸이 남아 있습니다.
• 이 벤치가 측정하는 건 단일 함수의 정답률이 아니라 소프트웨어 설계 능력입니다. 언어 선택·모듈 분할·자료구조·에러 처리 — 전부 모델 몫이고, implementation-agnostic 평가가 이걸 가능하게 합니다.
• 모델은 monolithic single-file을 강하게 선호합니다. 함수 수는 원본의 0.1~0.29배, 파일 수 중앙값 3 vs 15. 모델 학습 데이터에서 짧고 평탄한 코드가 과대대표되고 있다는 강한 신호입니다. Claude Opus 4.7 같은 최신 모델을 쓰는 사용자에게도 직접 시사가 있습니다 — 모델에게 "큰 소프트웨어를 처음부터 짜라"고 시키면, 받게 되는 결과물은 거의 확실히 한두 파일에 몰린 긴 함수 덩어리입니다.