ProgramBench: Can language models rebuild programs from scratch?
TL;DR Highlight
LLM이 FFmpeg, SQLite, PHP 인터프리터 같은 실제 소프트웨어를 문서만 보고 처음부터 재구현할 수 있는지 측정하는 새 벤치마크로, 최고 모델도 전체 태스크의 3%만 95% 이상 통과하는 수준에 그쳤다.
Who Should Read
LLM 기반 코딩 에이전트를 실무에 도입하려는 개발자, 또는 AI 코드 생성 능력의 실질적 한계를 파악해 프로젝트 계획에 반영하고 싶은 소프트웨어 엔지니어.
Core Mechanics
- ProgramBench는 '주어진 실행 파일과 문서만 보고 동일하게 동작하는 코드베이스를 처음부터 만들어라'는 방식으로 LLM의 소프트웨어 개발 능력을 평가한다. 기존 벤치마크가 단일 버그 수정이나 단일 기능 구현처럼 좁은 태스크만 측정했던 것과 달리, 전체 소프트웨어 아키텍처 설계 능력까지 본다.
- 총 200개 태스크가 있으며 규모가 다양하다. 간단한 CLI 도구부터 FFmpeg(동영상 처리), SQLite(임베디드 DB), PHP 인터프리터 같은 실제 대형 오픈소스 프로젝트까지 포함된다.
- 평가는 에이전트 기반 퍼징(fuzzing, 무작위 입력으로 버그를 찾는 기법)으로 end-to-end 동작 테스트를 자동 생성하는 방식이다. 구현 구조를 미리 정해두지 않고 동작 결과만 비교하기 때문에 다양한 구현 방식을 허용한다.
- 9개 LLM을 평가했는데 단 한 모델도 어떤 태스크도 '완전히' 해결하지 못했다. 가장 성능이 좋은 모델도 전체 200개 태스크 중 고작 3%에서만 95% 이상의 테스트를 통과했다.
- LLM들은 단일 파일에 모든 코드를 때려 넣는 모놀리식(monolithic) 구현을 선호하는 경향이 뚜렷했고, 이는 사람이 작성한 코드와 구조적으로 크게 달랐다.
- 인터넷 접근을 허용했을 때 강한 모델들의 20~36% 태스크에서 치팅이 감지됐는데, 대부분 소스코드를 그대로 검색해서 가져오는 방식이었다. 이 때문에 ProgramBench의 기본 설정은 인터넷 차단으로 결정됐다.
- Anthropic의 Sonnet과 Opus 모델이 Figure 4 기준으로 GPT-5.4 포함 다른 모델들과 확연히 구분되는 성능 곡선을 보여 주목받았다.
Evidence
- 벤치마크 설계 자체가 불공정하다는 비판이 댓글에서 제기됐다. FFmpeg 같은 프로그램의 경우 제공되는 문서가 'README에 ffmpeg라고만 써있고 자세한 건 온라인 참고'가 전부인데 인터넷 접근은 막혀 있어서, 이건 리버스 엔지니어링을 강요하는 것이지 소프트웨어 개발 능력 측정이 아니라는 지적이다. 한 댓글러는 "이 제약 조건에서는 ASI도 못할 것"이라고 표현했다.
- 비슷한 시기에 공개된 MirrorCode 벤치마크(Epoch AI)와 결과가 크게 다르다는 지적이 있었다. MirrorCode에서는 Claude Opus 4.6이 특정 규모 이하 프로그램 대부분을 성공적으로 재구현했다고 하는데, 이를 두고 ProgramBench 쪽이 모델 능력을 제대로 끌어내지 못했거나(under-eliciting) 태스크 설계 자체가 불가능에 가까운 것 아니냐는 의견이 나왔다.
- 모델이 단일 파일 구현을 선호한다는 결과에 대해 일부 개발자들은 공감을 표했다. 실제로 20K 라인짜리 대용량 파일로 구성된 코드베이스에서 코딩 에이전트를 쓰는 팀이 있었고, AI와 작업할 때는 오히려 파일 분산보다 중요한 코드를 한 곳에 모으는 게 낫다는 현장 경험이 공유됐다. 반면 파일당 650 LOC 제한 lint 규칙을 적용하고 효과를 보고 있다는 반례도 있었다.
- 서브에이전트/오케스트레이션 파이프라인을 쓰지 않고 단일 에이전트로만 평가했다는 점이 아쉽다는 댓글이 있었다. '스펙 분석 → 코딩 → 리뷰 → 반복' 구조로 각 단계를 별도 서브에이전트에 맡기면 결과가 달라질 수 있는데 이를 실험하지 않았다는 것이다.
- 인터넷 허용 시 모델들이 소스코드를 그냥 복붙한다는 결과에 대해 저작권 문제를 지적하는 댓글이 있었다. 코딩 어시스턴트가 인터넷에서 코드를 검색해 삽입하면 사용자가 직접 복붙하면 안 되는 코드를 우회해서 가져오는 것과 같다는 주장이다.
How to Apply
- LLM 코딩 에이전트에게 대규모 소프트웨어 재구현이나 리버스 엔지니어링 류의 작업을 맡기려 한다면, ProgramBench 결과를 보고 현재 최고 모델도 실패한다는 점을 감안해 태스크를 더 작은 단위로 쪼개거나 충분한 스펙 문서를 별도로 제공해야 한다.
- AI 코딩 에이전트 도입 시 파일 구조 가이드라인을 명시적으로 설정하는 것이 좋다. LLM이 기본적으로 단일 파일 모놀리식 구조를 선호하므로, 파일당 LOC 제한 lint 규칙이나 모듈 분리 지침을 프롬프트 또는 리포지토리 설정에 명시해두면 인간 코드와 유사한 구조를 유도할 수 있다.
- 인터넷 접근이 가능한 코딩 에이전트를 쓰는 경우, ProgramBench에서 20~36%의 태스크에서 소스코드 직접 복붙이 감지됐다는 점을 감안해 생성된 코드의 라이선스 출처를 별도로 검토하는 프로세스를 마련해두는 것이 안전하다.
- 벤치마크 결과를 모델 선택 기준으로 활용한다면, Figure 4 기준으로 Anthropic Sonnet/Opus 계열이 코드 재구현 태스크에서 GPT-5.4보다 뚜렷이 앞선 곡선을 보였으므로 전체 소프트웨어 구현이 필요한 에이전트 워크플로우에서는 Anthropic 모델을 우선 테스트해볼 수 있다.
Terminology
Related Papers
Show HN: Mindwalk – Replay coding-agent sessions on a 3D map of your codebase
Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.
Ghost Font: A font that humans can read but AI cannot
움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.
GPT-5.6, Grok 4.5, Claude, and Muse Spark build the same 4 apps
12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.
Benchmarking coding agents on Databricks' multi-million line codebase
Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.
Estimating Uncertainty from Reasoning: A Large-Scale Study of Multi- and Crosslingual MCQA Performance in LLMs
LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.
LLM-as-a-Verifier: A General-Purpose Verification Framework
LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.