추가(Add)는 기계의 영역, 삭제(Delete)는 인간의 영역: LLM 코드 편집에서의 삭제 회피 현상 측정 및 완화

To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing

대규모 언어 모델은 점점 더 많은 생산 코드를 작성하고 수정하는 데 사용되고 있지만, 이러한 모델이 생성하는 테스트 통과 패치가 코드베이스 유지 관리를 어렵게 만든다는 증거가 늘어나고 있습니다. 우리는 '삭제 회피'라는 구체적인 원인을 확인했습니다. 삭제 회피는 의도된 편집 과정에서 제거해야 할 코드를 유지하려는 체계적인 경향을 의미합니다. 공식 SWE-bench Verified 순위의 상위 5개 모델을 분석한 결과, 개발자가 제공한 패치에 대한 삭제 정확도는 심지어 모든 모델이 해결할 수 있는 작업에서도 최대 71.7%에 불과했습니다. 모델은 필요한 삭제 작업 중 92% 이상의 경우 올바른 파일을 선택하지만, 정확히 해당 라인을 수정하는 경우는 52% 미만입니다. 대신, 29.0%의 패치는 대상 코드를 가드(guard) 또는 백업(fallback)으로 감싸는 패턴인 '가드-앤-고(Guard-and-Go)'를 사용합니다. 이러한 패치가 통과되는 이유는 원래 테스트에서 제거 여부를 거의 확인하지 않기 때문입니다. 우리는 34개의 Verified 작업을 수정하여 대상 코드가 남아 있을 경우 실패하는 테스트를 추가했습니다. 그 결과, 폐쇄형 및 공개 모델을 포함한 최첨단 모델의 성공률은 63.2%에서 41.9%로 감소했습니다. 실제 코드 수정 작업은 삭제와 추가를 함께 수행하기 때문에, 우리는 'CanItDelete'라는 벤치마크를 구축했습니다. 이 벤치마크는 실제 커밋에서 추출한 200개의 작업으로 구성되며, 필요한 모든 수정 사항이 삭제만을 포함합니다. 추가 작업이 없어도 최상의 모델은 여전히 5개의 작업 중 1개를 실패하며, 작은 공개 모델의 경우 실패율은 18.0%에 달합니다. 우리는 GPT-5.6 Sol 모델을 대상으로 네 가지 누적 프롬프트를 사용하여 실험했습니다. 성공률은 정확한 라인 정보를 제공하기 전까지는 거의 변하지 않지만, 해당 정보를 제공하면 불완전한 삭제가 거의 제거되지만, 성공률은 80.5%로만 상승합니다. 그 이유는 모델이 지정된 범위 이상을 삭제하거나 코드를 추가하기 때문입니다. 마지막으로, 예비 연구를 통해 잠재적인 해결책을 제시합니다. 즉, 사전 학습 후 삭제 기능을 교육하면 삭제 회피가 줄어들고 전반적인 코드 편집 성능이 향상됩니다. 이는 현재 이러한 기능이 충분히 훈련되지 않았기 때문일 가능성을 시사합니다.

Large language models increasingly write and repair production code, yet evidence is mounting that their test-passing patches leave codebases harder to maintain. We identify one concrete source: deletion avoidance, the systematic tendency to retain code that an intended edit requires removing. Across the five leading models on the official SWE-bench Verified leaderboard, deletion recall against the developer patch reaches at most 71.7% even on tasks all five solve, and models reach the right file for over 92% of required deletions but cut the exact line in under 52% of cases. Instead, 29.0% of passing patches wrap the targeted code in a guard or fallback, a pattern we call Guard-and-Go. Such patches pass because the original tests rarely check removal: when we retrofit 34 Verified tasks with tests that fail if the targeted code remains, four frontier models spanning closed and open weights fall from 63.2% to 41.9%. Because real repairs mix removal with addition, we curate CanItDelete, a benchmark of 200 tasks mined from real commits whose entire required edit is deletion. Even with the addition work gone, the best model still fails one task in five, and smaller open models fall to 18.0%. We then ablate GPT-5.6 Sol under four cumulative prompts; success moves little until we supply the exact lines, which nearly eliminate incomplete deletion yet raise success only to 80.5% because the model then deletes beyond the spans or adds code instead. Finally, through a pilot study we show one potential fix: teaching deletion during post-training reduces deletion avoidance and improves broader code-editing performance, suggesting the behavior is undertrained rather than beyond reach.