글쓴이는 설계만 직접 하고 코드 약 1만 1천 줄은 모두 클로드에게 맡겼는데, 지시 없이 맡긴 첫 5시간은 거의 버렸고, 단단히 지시한 25시간에 쓸 만한 시제품이 나왔고, 다듬은 30시간은 고친 만큼 다시 망가졌다고 적었어요. 처음에 준 지시를 50시간 뒤에 새로 알아낸 듯 말하고, macOS 가 10년 전부터 무시하는 설정을 거듭 권하고, 10번 돌린 결과로 p90 을 낸다며 두 번째로 느린 값을 쓰고, 같은 조건을 검사하는 코드 두 곳 중 한 곳만 고친 사례가 실렸어요. 하위 에이전트끼리 위임만 주고받다 약 12만 토큰을 조사 없이 쓴 일도 있었고, 그래도 퍼저는 옵시디언 1.12·1.13.7 에서 재현되는 데이터 유실 순서를 찾아 MIT 저장소로 공개됐어요.
용어 풀이
- 퍼저
- 무작위·변형 입력을 대량으로 넣어 버그를 찾는 시험 도구(fuzzer)
- p90
- 측정값 중 90%가 그보다 작은 값, 90번째 백분위
- MIT
- 복제·수정·상업 이용을 넓게 허용하는 오픈소스 라이선스
- README
- 저장소의 소개·사용법을 적는 첫 문서
운영자 인사이트
글쓴이가 권하는 대응은 세션을 최대한 짧게 끊고 압축보다 새 세션을 열기, 클로드가 벤치마크 결과를 말하면 반복 횟수와 통계를 담은 스크립트로 다시 재게 하기, README 같은 파일은 직접 고치지 말고 변경 제안 목록만 내게 한 뒤 git 으로 지켰는지 확인하기예요. 긴 작업을 클로드 코드에 맡기는 팀이라면 이 세 가지를 작업 규칙에 먼저 넣어 볼 만해요.
여러 관점으로 보기
- 1편: 쓴 모델과 도움이 된 부분 9월 20일에 나온 1편은 6월부터 오푸스 4.8·소넷 5·오푸스 5·오푸스 5.5 를 차례로 월 20달러 Pro 요금제로 썼고, 대량 리팩터링과 시제품 속도에서는 도움을 받았다고 적었어요. hmijail (Substack)
- 결과물 저장소 ObsSyncBugHunt 는 MIT 라이선스 타입스크립트 저장소로, README 에 데이터가 충돌 파일 없이 사라지는 재현 순서를 적어 두었고 설계는 사람, 코드는 전부 클로드가 썼다고 밝혀요. GitHub