수정은 하되, 검증은 필수: 지시 기반 코드 수정 벤치마크에 대한 실증적 분석

Edit, But Verify: An Empirical Audit of Instructed Code-Editing Benchmarks

지시 기반 코드 수정은 LLM이 자연어 지시에 따라 기존 코드를 수정하는 방식으로, 실제 코딩 지원 상호작용의 약 19%를 차지합니다. 하지만 이 기능을 직접적으로 평가하는 벤치마크는 매우 드뭅니다. 150개 이상의 코드 관련 벤치마크를 조사한 결과, CanItEdit과 EDIT-Bench 두 가지 벤치마크만이 인간이 작성한 지시사항을 사용하고 테스트 기반 평가를 통해 지시 기반 코드 수정을 평가합니다. 본 연구에서는 이 두 벤치마크의 프로그래밍 언어, 수정 의도, 적용 분야를 실제 사용 현황(Copilot Arena, AIDev, GitHub Octoverse)에서 관찰되는 분포와 비교하고, 213개의 문제에 대한 테스트 개수, 문장 커버리지, 테스트 범위를 측정하여 분석합니다. 두 벤치마크 모두 평가의 90% 이상을 Python으로 진행하며, GitHub에서 가장 많이 사용되는 TypeScript는 전혀 포함되어 있지 않습니다. 실제 코드 수정 활동의 46%를 차지하는 백엔드 및 프론트엔드 개발은 대부분 누락되어 있으며, 문서 작성, 테스트, 유지 보수 수정은 실제 개발자의 Pull Request(PR)에서 31.4%를 차지하지만, 이와 관련된 내용은 전혀 포함되어 있지 않습니다. 두 벤치마크 모두 테스트 개수가 상대적으로 적습니다(CanItEdit의 중앙값 13개, EDIT-Bench의 중앙값 4개). 하지만 CanItEdit은 거의 완벽한 전체 파일 커버리지와 수정 영역 이전의 실패/수정 영역 이후의 성공 유효성 검증을 제공합니다. EDIT-Bench의 낮은 커버리지를 가진 테스트 세트의 59%는 수정 영역 외부의 수정 사항을 감지하지 못합니다. EDIT-Bench에는 40개의 LLM 중 어느 것도 해결하지 못하는 15개의 문제가 있으며, 이 문제들 중 11개는 모델의 한계라기보다는 벤치마크 자체의 문제로 인해 발생합니다. 또한, EDIT-Bench 문제의 29%와 CanItEdit 문제의 6%는 벤치마크 내의 다른 문제와 동일한 코드를 공유합니다. 요약하자면, 이러한 벤치마크는 실제 배포 결정에 필요한 것보다 좁은 범위를 측정합니다. 따라서 본 연구에서는 실증적인 근거를 바탕으로 한 6가지 필수 요소를 제안하고, 모든 분석 자료를 공개하여 커뮤니티가 실제 코드 수정 능력을 신뢰성 있게 반영하는 지시 기반 코드 수정 벤치마크를 개발할 수 있도록 지원합니다.

Instructed code editing, where an LLM modifies existing code based on a natural language instruction, accounts for roughly 19% of real-world coding assistant interactions. Yet very few benchmarks directly evaluate this capability. From a survey of over 150 code-related benchmarks, we find that only two, CanItEdit and EDIT-Bench, target instructed code editing with human-authored instructions and test-based evaluation. We audit both by comparing their programming languages, edit intents, and application domains against distributions observed in the wild (Copilot Arena, AIDev, GitHub Octoverse), and by measuring test counts, statement coverage, and test scope across all 213 problems. Both benchmarks concentrate over 90\% of evaluation on Python while TypeScript, GitHub's most-used language, is absent. Backend and frontend development, which together constitute 46% of real-world editing activity, are largely missing, and documentation, testing, and maintenance edits (31.4% of human PRs) have zero representation. Both benchmarks have modest test counts (CanItEdit median 13, EDIT-Bench median 4), though CanItEdit compensates with near-complete whole-file coverage and fail-before/pass-after validation. 59\% of EDIT-Bench's low-coverage suites would not detect modifications outside the edit region. EDIT-Bench has 15 problems that are not solved by any of 40 LLMs and 11 of these problems trace failures to poor benchmark artifacts rather than model limitations. Further, 29% of EDIT-Bench problems and 6% of CanItEdit problems share a codebase with at least one other problem within the benchmark. In summary, these benchmarks measure a narrower construct than deployment decisions require. We therefore propose six empirically grounded desiderata and release all audit artifacts so the community can build instructed code-editing benchmarks whose scores reliably reflect real-world editing capability.