AI 코딩 에이전트들은 점점 더 '하네스(harness)' 내부에서 작동하고 있습니다. 이 하네스는 AGENTS.md와 같은 규칙 파일, 온디맨드 스킬(on-demand skills), 런타임 후크(runtime hooks), 자동화된 검사 등을 포함합니다. 대부분의 하네스 연구는 단일 시점이나 짧은 벤치마크 실행에 초점을 맞춥니다.
저는 개인적인 기록 시스템인 여섯 주간의 사례 연구를 보고합니다. 이 시스템은 공유된 규칙 세트 아래에서 세 개의 AI 에이전트 도구가 매일 편집하는 일반 마크다운(plain-markdown) 저장소였습니다. 저는 118개의 에이전트 실패 사례, 그 수정 내용, 그리고 재발 여부를 기록한 원장을 만들었습니다. 또한 이 시스템의 월별 LLM 문서 감사 기능을 사용하여 알려진 47개의 오래된 진술(stale statements)과 의도적으로 심은 20개의 오류를 테스트했습니다. 마지막으로, 저는 과거 발생했던 다섯 가지 실패 사례를 격리된 git 클론에서 수정 여부 유무에 따라 재현해 보았습니다. 모든 결과는 하나의 저장소에서 각 조건별로 세 번의 실행을 통해 얻었으므로, 탐색적인(exploratory) 보고서로 제시합니다.
가장 큰 실패 유형은 오래된 문서화(drift)였으며 (118개 중 48개), 이 중 35개는 단 하루의 감사에서 발견되었습니다. 단 한 번의 감사 실행만으로 알려진 드리프트의 약 절반(Claude Sonnet 5.5 평균: 50%)을 찾아냈고, 그 발견된 내용 중 최소 93%가 정확했습니다. Sonnet 5.5 모델에서는 에이전트가 재현한 다섯 가지 작업 중 네 가지를 완료했습니다. 이 네 가지 중 세 가지는 수정 여부와 관계없이 실패하지 않았습니다. 오직 오래된 카운트(stale-count) 실패만 검사 없이 재발했으며, 해당 검사가 모든 실행에서 이를 막았습니다.
오래된 모델에서는 에이전트가 em-dash를 한 번 작성했을 때 em-dash 린트(lint) 검사가 활성화되어 있었고, 이 검사에 의해 거부되었습니다. 런타임 추정치에 대한 서면 규칙은 Sonnet 4.5의 과대평가를 바꾸지 못했습니다.
이러한 결과들은 하네스에서 얻은 교훈들이 그것을 수정하기 위해 작성된 실패들보다 오래 지속될 수 있음을 시사하는 동시에, 드리프트는 여전히 존재하며 기계적인 검사가 필요함을 보여줍니다. 하네스를 발전시키는 도구들은 이를 폐기하는 것보다 더 빠르게 교훈들을 추가하므로, 주기적으로 규칙을 재테스트하고 구식화된 규칙은 폐기해야 합니다.