To Add Is Machine, To Delete Is Human: Measuring and Mitigating Deletion Avoidance in LLM Code Editing
AI 코딩 모델은 코드를 지우라는 지시를 받아도 옛 코드를 몰래 남겨둔다
SWE-bench Verified에서 상위권 모델 5개를 분석했더니, 테스트를 통과한 패치조차 개발자가 지운 코드의 상당 부분을 남겨두고 있었다. 삭제만 요구하는 새 벤치마크 CanItDelete로 확인해도 최고 모델조차 5개 중 1개 과제를 실패했다. 삭제 예시를 소폭 추가해 재학습시키자 이 문제와 함께 다른 코드 편집 성능도 함께 개선됐다.
METAL LAB 해설 도표
삭제 회피가 드러나는 세 단계 실험 구조
증거 상태측정 결과가 보고됨
1. 실제 저장소 패치 비교SWE-bench Verified 5개 모델의 통과 패치를 개발자 패치와 대조해, 지워야 할 코드의 65~72%만 실제로 지워졌고 29%는 Guard-and-Go로 남겨졌음을 확인
2. 테스트의 사각지대 검증34개 과제에 삭제 여부를 직접 검사하는 테스트를 추가하자 통과율이 63.2%에서 41.9%로 하락, 기존 테스트가 삭제 누락을 못 잡아낸다는 것을 입증
3. 삭제만 요구하는 벤치마크CanItDelete 200개 과제로 추가·국지화 요인을 제거하고 순수 삭제 능력만 측정, 최고 모델도 79.0%에 그치고 정확 범위를 줘도 19.5% 실패
4. 진단 사다리삭제 지시, 위치 힌트, 정확한 삭제 범위를 단계적으로 제공해 실패 원인이 의도 부족이 아니라 경계 지식 부족임을 밝힘
5. 삭제 중심 재학습7B 모델 학습 데이터의 0.7%만 삭제 예시로 채워도 CanItDelete와 SWE-bench Verified, CanItEdit 성능이 함께 향상
METAL LAB이 원문을 바탕으로 재구성한 해설 도표이며, 논문 저자의 원문 figure가 아닙니다.
무엇을 했나
SWE-bench Verified 공식 리더보드의 GLM-4.6, GPT-5, Kimi-K2, Opus-4.5, Salesforce SAGE 다섯 모델의 패치를 개발자 패치와 비교해, 다섯 모델 모두 통과한 197개 과제에서 삭제 재현율(모델이 개발자가 지운 코드를 실제로 지운 비율)이 65.2~71.7%에 그친다는 것을 확인했다.
모델들은 삭제가 필요한 파일은 92% 이상 정확히 찾아가지만, 정확한 줄까지 지우는 비율은 44.6~51.6%에 불과해, 문제는 코드를 못 찾아서가 아니라 찾고도 지우지 않는 데 있음을 보였다.
LLM 분류기로 패치 전략을 분류한 결과, 통과한 패치의 29.0%가 지워야 할 로직을 그대로 두고 그 주위에 조건문(if/else)이나 우회 경로를 덧붙이는 'Guard-and-Go' 패턴이었다.
삭제 여부를 실제로 검사하는 테스트를 34개 과제에 추가하자, 4개 최신 모델의 통과율이 63.2%에서 41.9%로 떨어져, 기존 테스트가 삭제 누락을 거의 걸러내지 못했음을 확인했다.
삭제만 요구하는 200개 과제로 구성된 CanItDelete 벤치마크에서 최고 모델(Claude Opus 4.8)조차 79.0%만 성공했고, 정확히 지울 줄을 알려줘도 GPT-5.6 Sol 같은 모델은 목표 밖까지 지우거나 코드를 추가하는 식으로 여전히 19.5%를 실패했다. 삭제 예시 12.8k개(전체 학습 토큰의 0.7%)를 추가해 7B 모델을 재학습시키자 CanItDelete 성능이 13.9%p 개선되고, SWE-bench Verified도 5.3점, CanItEdit도 1.4점 함께 올랐다.
Figure 1: An example of deletion avoidance in a solved SWE-bench Verified task. The developer patch removes a statement, while the model retains it under an ‘else’ guard.
Table 1: Mean deletion recall on 197 tasks all five models solve and 57 all five fail. δ denotes effect size.
Model
Failed (n=57)
Solved (n=197)
δ
GLM-4.6
24.0%
67.5%
0.532
GPT-5
29.9%
68.5%
0.485
Kimi-K2
19.8%
65.2%
0.543
Opus-4.5
30.4%
71.7%
0.504
Salesforce SAGE
27.5%
68.0%
0.501
Figure 2: Overview of CanItDelete benchmark construction, cumulative diagnostic modes, and the structural outcome taxonomy.
Table 2: Patch strategies among 2,358 classifier-labeled pairs. Share is overall frequency; pass rate is SWE-bench Verified resolution within each strategy. Table 12 (Appendix B) lists the ten Guard-and-Go forms.
Strategy
n
Share
Pass rate
Delete-and-Replace
1,197
50.8%
85.2%
Guard-and-Go
684
29.0%
72.2%
Non-reference alternative
477
20.2%
39.6%
Figure 3: Vanilla-mode success and failure composition across 12 models. Success is measured over 200 tasks; failure mechanisms are measured over each model’s failed tasks.
Table 3: Attempts passing the original suite and, among them, the deletion-sensitive check on 34 tasks per model. Drop is in percentage points (pp); each task is about 2.9 pp.
Passing attempts
Model
Tasks
Original suite
Original
suite
With deletion check
With deletion
check
Drop (pp)
Drop
(pp)
Original
suite
With deletion
check
Drop
(pp)
GPT-5.6 Sol
34
21 (61.8%)
15 (44.1%)
17.6
Opus 4.8
34
21 (61.8%)
14 (41.2%)
20.6
GLM-5.2
34
26 (76.5%)
18 (52.9%)
23.5
DeepSeek-V4-Pro
34
18 (52.9%)
10 (29.4%)
23.5
Overall
136
86 (63.2%)
57 (41.9%)
21.3
Figure 4: Diagnostic-ladder outcomes under increasingly precise deletion guidance. Four models use 200 tasks; Claude Opus 4.8 uses 173.
Table 4: 7B-model performance before and after deletion-augmented post-training. Values are three-run means (%); Δ is absolute percentage-point change. Over-deletion is a subset of complete-but-invalid edits.
CanItDelete outcome
Benchmark success
Succ.
Incomp.
Complete invalid
Over- deletion
SWE-b. Verified
EditBench
CanItEdit
Base
6.5
80.4
13.1
10.6
25.40
39.26
44.30
+Deletion
13.7
66.5
19.8
16.8
30.70
39.07
45.70
Δ
+7.2
−13.9
+6.7
+6.2
+5.30
-0.19
+1.40
Figure 5: File-, scope-, and exact-line overlap across all required deletions in the 197 tasks solved by all five models
Table 5: Model submissions selected from the official SWE-bench Verified repository. For each model family, we retained the latest submission using the OpenHands scaffold. The submission date is extracted from the leading YYYYMMDD component of the repository directory name.
Family
Selected model
Submission directory
Submission date
GLM
GLM-4.6
20250930_zai_ glm-4.6
September 30, 2025
GPT
GPT-5
20250807_ openhands_gpt5
August 7, 2025
Kimi
Kimi K2
20250716_ openhands_kimi_k2
July 16, 2025
Claude
Claude Opus 4.5
20251127_ openhands_ claude-opus-4-5
November 27, 2025
SAGE
Salesforce SAGE
20251103_ SalesforceAIResearch_ SAGE_OpenHands
November 3, 2025
Figure 6: Structural distributions across the 200 CanItDelete tasks.
Table 6: Mean per-task deletion precision and recall. A match requires the model-generated patch to delete the same base-commit source location as the official human patch.
Failed by all five (n=57)
Failed by all five
(n=57)
Solved by all five (n=197)
Solved by all five
(n=197)
Failed by all five
(n=57)
Solved by all five
(n=197)
Model
Precision
Recall
Precision
Recall
GLM-4.6
34.6%
24.0%
70.7%
67.5%
GPT-5
35.6%
29.9%
69.3%
68.5%
Kimi-K2
35.0%
19.8%
70.6%
65.2%
Opus-4.5
47.0%
30.4%
74.3%
71.7%
Salesforce SAGE
36.7%
27.5%
66.2%
68.0%
Table 7: Comparison of deletion recall between all-passed (n=197) and all-failed (n=57) eligible tasks for each evaluated model. Panel A reports the median and interquartile range (IQR). Panel B reports the Mann–Whitney U test with Holm-adjusted p-values and Cliff’s δ effect size.
All-passed
All-failed
Model
Median
IQR
Median
IQR
Salesforce SAGE
1.00
0.75
0.07
0.50
GLM-4.6
1.00
0.75
0.00
0.33
GPT-5
1.00
0.71
0.00
0.50
Kimi-K2
1.00
0.80
0.00
0.25
Opus-4.5
1.00
0.61
0.17
0.50
Table 8: Comparison of deletion precision between all-passed (n=197) and all-failed (n=57) eligible tasks for each evaluated model. Panel A reports the median and interquartile range (IQR). Panel B reports the Mann–Whitney U test with Holm-adjusted p-values and Cliff’s δ effect size.
All-passed
All-failed
Model
Median
IQR
Median
IQR
Salesforce SAGE
1.000
0.684
0.038
0.929
GLM-4.6
1.000
0.667
0.000
1.000
GPT-5
1.000
0.684
0.000
1.000
Kimi-K2
1.000
0.667
0.000
1.000
Opus-4.5
1.000
0.500
0.400
1.000
Table 9: Model-generated patch size relative to the corresponding developer patch for passing Guard-and-Go pairs. LOC is measured as the sum of added and deleted lines.
Model
Pairs
Model larger
Model
larger
Equal LOC
Equal
LOC
Model smaller
Model
smaller
Model
larger
Equal
LOC
Model
smaller
GLM-4.6
91
89 (97.80%)
0 (0.00%)
2 (2.20%)
GPT-5
120
58 (48.33%)
10 (8.33%)
52 (43.33%)
Kimi-K2
92
75 (81.52%)
3 (3.26%)
14 (15.22%)
Opus-4.5
91
30 (32.97%)
20 (21.98%)
41 (45.05%)
Salesforce SAGE
100
50 (50.00%)
14 (14.00%)
36 (36.00%)
Overall
494
302 (61.13%)
47 (9.51%)
145 (29.35%)
Table 10: Categories in the running taxonomy after each axial round. Each round covers five new pairs.
Round
Pairs coded
Added
Revised
Total
1
5
12
0
12
2
10
4
0
16
3
15
4
0
20
4
20
3
0
23
5
25
0
0
23
6
30
0
0
23
Table 11: Guard-and-Go structural subtypes identified in model-generated patches.
Subtype
Definition
Retained Path as Live Fallback
Guards the reported case but leaves logic deleted by the official patch as the default path, allowing non-matching inputs to continue executing the retained logic.
Special-Case Carve-Out Bypass
Adds a branch or relaxes a precondition for one input category while leaving the general resolution mechanism unchanged.
Missing-Element Existence Bypass
Checks for a required runtime element and returns a default value when it is absent instead of evaluating the retained logic.
Failure-Site Symptom Patch
Suppresses or compensates for the symptom at the failure site while leaving the producing control flow unchanged.
Exception Capture Bypass
Catches exceptions raised by retained logic and returns a default value instead of removing the underlying cause.
Post-Hoc Output Correction
Corrects an incorrect result after the buggy computation has already completed.
Missing-Functionality Injection
Introduces new logic or parameters to handle the reported case instead of adopting the restructuring performed by the official patch.
Upstream Reroute Around Retained Branch
Redirects problematic inputs away from a retained branch, leaving the obsolete branch as unreachable legacy logic.
Parallel Duplicate-Path Retention
Retains logic that the official patch consolidates while introducing an additional execution path that can also satisfy the behavior.
Value-Compatibility Shim
Conditionally restores a legacy constant or decoding behavior for a specific input.
Table 12: Distribution of the ten Guard-and-Go structural forms. Of the 684 Guard-and-Go pairs, the closed-source classifier assigned a subtype to 550 and abstained on the remaining 134. Share is computed over the 550 typed pairs, and pass rate is the proportion of pairs that SWE-bench Verified records as resolved.
Structural form
n
Share
Pass rate
Retained Path as Live Fallback
221
40.2%
68.3%
Special-Case Carve-Out Bypass
95
17.3%
52.6%
Missing-Element Existence Bypass
60
10.9%
81.7%
Failure-Site Symptom Patch
51
9.3%
66.7%
Exception Capture Bypass
43
7.8%
53.5%
Missing-Functionality Injection
35
6.4%
74.3%
Post-Hoc Output Correction
20
3.6%
80.0%
Upstream Reroute Around Retained Branch
10
1.8%
90.0%
Parallel Duplicate-Path Retention
8
1.5%
87.5%
Value-Compatibility Shim
7
1.3%
71.4%
All typed pairs
550
100.0%
67.3%
Table 13: Heuristic used to prioritize behaviorally important deletion units.
Signal
Score
Deleted lines are not reintroduced elsewhere
+3.0
Complete control block is removed
+3.0
Condition guarding existing code is changed or removed
+3.0
Control-flow statement is removed
+3.0
Complete function or class is removed
+2.5
Decorator is removed
+2.0
Comparison or Boolean logic is removed
+1.5
Function or class signature is changed
+1.5
Assignment is removed
+1.0
Function or method call is removed
+1.0
Deleted code contains problem-statement terms
+2.0
Larger multi-line deletion unit
+1.5
Import and its dependent code are removed
+0.5
Standalone import is removed
−4.0
Table 14: Task counts across the deletion-focused F2P construction process.
Selection stage
Count
Tasks with at least 25% deletion
69
Tasks included in deletion-unit analysis
65
Tasks with a meaningful code deletion
63
Tasks without a meaningful code deletion
2
Deletion units identified
166
Targets covered by a listed visible test
24
Targets not covered by a listed visible test
39
Host-validated deletion-focused F2P tasks
34
Table 15: The four cumulative CanItDelete diagnostic modes.
Mode
Cumulative signal
Diagnostic question
Vanilla
No signal beyond the developer-style request
Can the model infer and execute the complete deletion end to end?
Explicit deletion
Requires complete removal and forbids guards, comments, disabled branches, fallbacks, replacement code, and other workarounds
Is failure caused by not choosing a genuinely subtractive edit?
Region pointer
Identifies relevant functions, methods, or regions without revealing deletion boundaries
Is finding every required region the principal obstacle?
Exact lines
Supplies occurrence-specific spans and requires all unmarked text to be preserved
Can the model execute a precise deletion once intent, location, and boundaries are known?
Table 16: Complete five-model diagnostic-ladder results. Four models use 200 tasks per mode; Claude Opus 4.8 uses 173. Cells report count (percentage).
Mode
Success
Incomplete deletion
Complete deletion, invalid edit
GLM-5.2
Vanilla
133 (66.5)
30 (15.0)
37 (18.5)
Explicit deletion
128 (64.0)
36 (18.0)
36 (18.0)
Region pointer
147 (73.5)
29 (14.5)
24 (12.0)
Exact lines
175 (87.5)
6 (3.0)
19 (9.5)
GPT-5.6 Sol
Vanilla
148 (74.0)
20 (10.0)
32 (16.0)
Explicit deletion
144 (72.0)
21 (10.5)
35 (17.5)
Region pointer
148 (74.0)
19 (9.5)
33 (16.5)
Exact lines
161 (80.5)
6 (3.0)
33 (16.5)
MiniMax-M3
Vanilla
134 (67.0)
36 (18.0)
30 (15.0)
Explicit deletion
134 (67.0)
32 (16.0)
34 (17.0)
Region pointer
137 (68.5)
33 (16.5)
30 (15.0)
Exact lines
170 (85.0)
6 (3.0)
24 (12.0)
Claude Opus 4.8
Vanilla
136 (78.6)
25 (14.5)
12 (6.9)
Explicit deletion
138 (79.8)
27 (15.6)
8 (4.6)
Region pointer
143 (82.7)
19 (11.0)
11 (6.4)
Exact lines
169 (97.7)
1 (0.6)
3 (1.7)
Qwen3-235B-A22B
Vanilla
50 (25.0)
109 (54.5)
41 (20.5)
Explicit deletion
55 (27.5)
105 (52.5)
40 (20.0)
Region pointer
54 (27.0)
99 (49.5)
47 (23.5)
Exact lines
113 (56.5)
35 (17.5)
52 (26.0)
실제로 확인된 결과
다섯 개 상위 모델 모두 통과한 197개 과제에서 평균 삭제 재현율은 65.2%(Kimi-K2)~71.7%(Opus-4.5)에 그쳤고, 다섯 모델 모두 실패한 57개 과제에서는 19.8~30.4%로 더 낮아졌다.
통과한 패치의 29.0%(1,703건 중 494건)가 Guard-and-Go 전략을 썼으며, 이 전략의 SWE-bench 통과율은 72.2%로 Delete-and-Replace(85.2%)보다 낮지만 비참조 대안(39.6%)보다는 높았다.
34개 과제에 삭제 민감 검사를 추가하자 4개 최신 모델의 통과율이 63.2%에서 41.9%로 21.3%p 떨어졌고, 원래 통과했던 86건 중 29건이 목표 코드를 그대로 남긴 것으로 드러났다.
CanItDelete 200개 과제에서 12개 모델의 성공률은 79.0%(Claude Opus 4.8, 최고)부터 18.0%(소형 오픈모델)까지 분포했고, 정확한 삭제 범위를 알려주는 최종 단계에서도 Opus 4.8은 97.7%였지만 Qwen3-235B는 여전히 17.5%에서 목표 코드를 남겼다.
7B 모델에 삭제 예시 12,821개(전체 토큰의 0.7%)를 추가해 재학습하자 CanItDelete 성공률이 6.5%에서 13.7%로, SWE-bench Verified가 5.3%p, CanItEdit가 1.4점 개선됐고, EditBench는 거의 변화가 없었다.
어디에 쓸 수 있나
AI 코딩 에이전트가 생성한 풀 리퀘스트를 병합하기 전, 테스트 통과 여부와 별도로 개발자가 지우려던 코드가 실제로 삭제됐는지 점검하는 리뷰 체크리스트로 활용
자동 패치 평가 파이프라인에 삭제 민감 검사(FAIL_TO_PASS용 삭제 확인 테스트)를 추가해 Guard-and-Go 같은 우회 패턴을 걸러내는 용도
코드 편집 모델의 사후 학습(post-training) 데이터셋에 삭제 중심 예시를 소량 섞어 넣어 삭제 회피를 줄이는 학습 전략 설계
레거시 코드 정리, 리팩터링, 데드코드 제거 작업에 LLM을 투입하기 전 삭제 능력을 별도로 검증하는 용도
한계와 남은 검증
분석 대상은 SWE-bench Verified의 특정 다섯 모델(2025년 시점 최신 제출물)과 OpenHands 스캐폴드로 한정되어, 다른 스캐폴드나 이후 모델 세대에는 그대로 적용되지 않을 수 있다.
삭제 민감 검사는 개발자 패치가 지운 대상을 유일한 정답으로 가정하지만, 그 대상을 남겨두고도 원래 동작 명세를 만족하는 대안적 수정이 존재할 수 있어 삭제만이 유효한 해법이라고 단정할 수 없다.
34개 삭제 민감 검사 과제와 CanItDelete 200개 과제는 각각 삭제 비중이 높거나 삭제만 요구하도록 구조적으로 선별된 것이라 SWE-bench Verified 전체나 일반 저장소 작업을 대표하지 않는다.
삭제 중심 사후 학습 실험은 7B 규모 단일 모델, 단일 학습 레시피로 수행된 개념 증명(proof of concept)이며, 더 큰 규모나 다른 아키텍처에서도 같은 효과가 나타나는지는 향후 연구로 남아 있다.
삭제 예시를 추가한 재학습은 삭제 누락은 줄였지만 과잉 삭제(경계를 넘어서는 삭제)를 오히려 늘려, 삭제 완성도와 경계 통제는 별개로 학습되어야 할 목표임이 드러났다.
왜 중요한가
AI가 작성한 코드 패치가 테스트를 통과해도 실제로는 지워야 할 낡은 코드를 남겨두어 유지보수를 더 어렵게 만들 수 있다는 구체적 증거를 제시한다. 코드 리뷰어나 AI 코딩 도구 도입 담당자는 '테스트 통과'만으로 패치 품질을 판단해서는 안 되며, 삭제 여부를 별도로 점검할 필요가 있음을 시사한다.
이 논문의 용어
삭제 회피(Deletion Avoidance) · 의도된 편집이 요구하는 코드 삭제를 모델이 체계적으로 피하고 코드를 남겨두는 경향
Guard-and-Go · 지워야 할 로직을 그대로 둔 채 조건문이나 우회 경로로 감싸 실행을 피해가게 만드는 패치 패턴
삭제 재현율(Deletion Recall) · 개발자가 실제로 지운 코드 중 모델도 똑같이 지운 비율
CanItDelete · 실제 커밋에서 뽑은, 오직 삭제만 요구되는 200개 과제로 구성된 새 벤치마크
삭제 민감 검사(Deletion-Sensitive Check) · 목표 코드가 그대로 남아 있으면 실패하도록 새로 추가한 테스트
