이 글이 HN에서 먹힌 이유는 단순하다. 개발자들이 이미 매일 겪는 문제를 정확한 이름으로 불렀기 때문이다. 오프바이원 하나 고치라고 했는데 함수 절반이 갈아엎어지고, 새 helper가 생기고, 검증 로직이 늘어나고, 리뷰해야 할 diff만 커지는 장면이다.

원문 Coding Models Are Doing Too Much는 이 현상을 over-editing이라 부른다. 문제 해결에 꼭 필요한 범위를 넘어서 코드를 바꾸는 행동이다. 글쓴이는 BigCodeBench 400개 문제를 의도적으로 망가뜨린 뒤, 모델이 내놓은 수정과 "정답인 최소 수정"을 비교했다. 기준은 token-level Levenshtein distance와 추가 cognitive complexity다. 테스트를 통과했는지만 보지 않고, 얼마나 덜 건드렸는지까지 본 셈이다.

HN이 특히 주목한 대목은 결과표다. 글에 따르면 GPT-5.4는 큰 diff를 자주 만들었고, Claude Opus 4.6은 더 작은 수정으로 높은 정답률을 냈다. 동시에 "원래 코드를 최대한 보존하라"는 단순한 지시만 붙여도 대부분 모델의 수정 폭이 줄고, 일부는 정답률도 올라갔다. 이 지점이 중요하다. 과한 수정은 능력 부족만이 아니라 기본 작업 습관의 문제라는 뜻이기 때문이다.

댓글 반응도 선명했다. 한쪽은 프로젝트 규칙을 저장하고 패치 범위를 좁히면 통제할 수 있다고 봤다. 다른 쪽은 혼자 일할수록 비용이 더 크다고 말했다. 모델이 5줄 대신 50줄을 건드리는 순간, 개발자 한 명이 구현자와 리뷰어를 동시에 떠안게 되기 때문이다. 반대로 "기존 코드를 너무 존중해서 더 나은 구조 변경을 못 하는 경우도 있다"는 반론도 나왔다.

결국 HN이 이 글에서 본 것은 단순한 모델 순위표가 아니다. 코딩 에이전트 시대의 좋은 편집이 무엇인지에 대한 기준이다. brownfield 코드베이스에서 가치 있는 수정은 화려한 재작성보다 작은 diff에 있다. 작게 고치면 더 빨리 읽히고, 더 빨리 믿을 수 있고, 쓸데없는 아이디어가 숨어들 자리도 줄어든다.

#minimal-editing

코드 버그는 1줄인데 diff는 왜 폭주할까, HN이 "과한 수정"에 꽂힌 이유