코딩 모드를 걷어낸 이유: 도구는 모델이 직접 고르게 하라
예전의 Agent!는 사용자가 코딩을 원하는지 자동화를 원하는지 추측해 그에 맞춰 도구를 숨겼습니다. 망가진 Photo Booth 작업 하나가 왜 하네스가 모델의 판단을 넘겨짚지 말아야 하는지 보여주었습니다.
초기 버전의 Agent!에는 코딩, 자동화, 표준이라는 세 가지 모드 가 있었습니다. 아이디어 자체는 그럴듯해 보였습니다. 코딩 작업에는 Accessibility 도구가 필요 없고, "이 버튼을 클릭해" 같은 작업에는 Xcode가 필요 없습니다. 관련 없는 도구를 숨기면 모델은 더 짧은 도구 목록을 보게 되고, 토큰을 덜 쓰며, 잘못된 선택도 줄어듭니다.
2026년 4월 7일, 커밋 7ea44c0d가 이 시스템 전체를 삭제했습니다. 그 계기가 된 버그와, 그 이후에 남은 원칙을 소개합니다.
모드는 어떻게 동작했나
작업의 두 번째 턴에서 하네스는 사용자의 요청을 살펴보고 두 개의 키워드 목록과 대조했습니다. build, compile, edit, fix, refactor 같은 단어는 코딩을 의미했습니다. click, button, window, photo, accessibility 같은 단어는 자동화를 의미했습니다. 그런 다음 codingModeEnabled 또는 automationModeEnabled 플래그를 켜고, 모델이 볼 수 있는 도구를 해당 모드의 그룹으로 좁혔습니다. 모델도 mode 도구를 통해 직접 모드를 전환할 수 있었습니다.
버그: 코딩 모드에 빠진 Photo Booth
버그 리포트는 단순히 "accessibility가 고장 났다"였습니다. 원인은 커밋 메시지의 표현을 그대로 빌리면 이렇습니다. 자동 전환 로직이 open -a Photo Booth를 알 수 없는 신호로 판단하고 기본값인 코딩 모드로 전환 했습니다. 코딩 모드는 Auto 그룹을 제외했는데, accessibility 도구가 바로 그 Auto 그룹에 속해 있었습니다.
결국 모델은 사진을 찍으라는 요청을 받았는데, 셔터 버튼을 누르기 위해 만들어진 단 하나의 도구가 작업 도중에 사라져 버린 것입니다. 모델은 유능한 모델이라면 남은 도구로 할 법한 일을 했습니다. 셸을 통해 osascript로 우회했고, 이는 "Can't get toolbar 1 of window 1." 오류와 함께 계속 실패했습니다.
모델에도, accessibility 도구에도 아무런 문제가 없었습니다. 하네스가 의도를 잘못 추측하고 정답을 조용히 빼앗아 간 것입니다.
수정이 아니었던 수정
뻔한 패치는 open -a를 자동화 키워드에 추가하는 것이었습니다. 커밋 메시지는 이를 정면으로 지적합니다. 그것은 "길게 이어진 반창고 목록에 하나를 더 붙이는 일"이 되었을 것이라고요. 키워드 기반 의도 감지는 이길 수 없는 게임입니다. 새로운 앱, 새로운 표현, 새로운 언어가 나올 때마다 구멍이 하나씩 늘어나고, 놓칠 때마다 가장 혼란스러운 방식으로 실패합니다. 한 턴 전까지 할 수 있던 일을 모델이 갑자기 못 하게 되는 식으로 말이죠.
무엇으로 대체했나: 아무것도
모드 시스템 전체를 들어냈습니다. 13개 파일에서 141줄을 삭제하고 39줄을 추가했습니다. 여기에는 다음이 포함됩니다.
codingModeEnabled및automationModeEnabled플래그와 각각의 도구 그룹 목록- 메인 작업 루프와 탭 작업 양쪽의 두 번째 턴 자동 전환
- 프롬프트로부터 도구 그룹을 추측하던 함수
predictToolGroups() - Claude 및 OpenAI 호환 서비스에서 로컬 엔드포인트용 도구 목록을 좁히던 로직
- 서브 에이전트용
coding및automation별칭(대신 실제 그룹 이름을 전달합니다)
이제 도구는 설정(ToolPreferencesService)에 있는 사용자 자신의 토글로만 필터링됩니다. 사용자가 활성화한 모든 도구는 매 턴마다 사용할 수 있고, 필요한 도구는 모델이 직접 고릅니다.
이런 삭제 작업에 얼마나 신경을 썼는지 보여주는 작은 디테일이 두 가지 있습니다. mode 도구는 완전히 제거되지 않았습니다. 대신 "mode switching has been removed" 라고 응답하는 no-op이 되었습니다. 컨텍스트에 예전 대화가 남아 있는 모델이 여전히 이 도구를 호출할 수 있고, 알 수 없는 도구 오류보다는 명확한 답변이 낫기 때문입니다. 또한 시스템 프롬프트 리비전이 71에서 72로 올라가, 디스크에 저장된 프롬프트 중 모드를 언급하는 것은 모두 다시 동기화됩니다.
결과
더 이상 "Coding mode auto-enabled" 로그 스팸이 없습니다. 작업 도중 도구가 사라지는 일도 없습니다. 턴마다 도구 목록이 오락가락하는 일도 없습니다.
원칙
이 결정은 이후의 많은 부분을 결정지었기 때문에, 분명하게 적어 둘 가치가 있습니다.
하네스는 안전 을 강제해야 하며, 의도 를 추측해서는 안 된다.
Agent!는 엄격함이 객관적인 영역에서는 엄격합니다. 치명적인 셸 명령, 모델이 읽지 않은 파일에 대한 편집, 근거 없는 "done"을 거부합니다. 이것들은 확인 가능한 사실입니다. 반면 작업에 어떤 도구가 필요한지는 판단의 문제이고, 그 판단은 키워드 목록보다 모델이 더 잘합니다. 하네스가 판단의 문제에서 모델을 무시하면, 조용하고 혼란스럽게 실패합니다. 확인 가능한 규칙을 강제하면, 요란하게 그리고 이유와 함께 실패합니다.
에이전트를 만들고 있다면 선택지를 줄여서 모델을 "도와주고" 싶은 유혹이 들 것입니다. 먼저 측정하세요. 도구 목록이 조금 길어지면 토큰 몇 개가 더 들 뿐입니다. 도구 하나가 빠지면 작업 전체를 잃을 수 있습니다.
