Sol Low이 Opus Medium을 관리할 때 - “이건 게시 안 할 거야”

적대적 검토를 할 때, 어떻게 하느냐에 따라 다르겠지만, 모델은 항상 뭔가를 찾아내게 되어 있음. 그게 모델이 하는 일이니까. 가끔은 진짜 문제일 때도 있지만, 아닐 때도 있음.

하네스(harness)랑 위임(delegation)은 어떻게 구성함?

아직 작업 중인 단계임. 내 워크플로우가 좀 독특해서, CI에 통합할 절차적인 부분들은 전부 파이썬으로 밑바닥부터 직접 짰음. 하향식으로 구축하기보다는 점진적으로 연결하는 방식을 쓰고 있는데, 이게 Claude에서 Codex로 넘어갈 때 특히 잘 먹혔음. 하위 레벨은 Opus랑 Codex가 만족할 만한 프롬프트로 다듬는 거 빼고는 바뀐 게 하나도 없거든.

우리도 두 모델을 같이 쓰는 환경임: 서로의 작업을 검토하는 Claude와 Codex. 실제로 유용했던 건 두 번째 모델이 아니라, 루프에서 빠지지 않으려는 인간의 노력이었음. 우리 페어링 과정을 지켜본 사람이 내린 규칙은 '너희 둘이 같이 작업하면 오류가 복합적으로 발생하니까, 한 번에 한 명씩만 검토하겠다'였음. 기준점(ground truth) 없이 두 확률적 검토자가 있으면, 같은 실수를 더 자신 있게 저지르더라고. Sol의 '이건 배포 안 해'라는 말은 훌륭하지만, 그게 힘을 발휘하는 건 결국 상위 단계에서 누군가가…

초기에 이걸 만들면서 깨달은 건데, 두 에이전트가 수렴해야 할 명세(specification)가 있을 때 합의를 끌어내는 게 훨씬 효과적임. 어떻게 코딩해야 하는지 상세하게 지시하고 불변성(invariant)을 잔뜩 주는 건 현재 모델들로는 잘 안 됨. 달성하고자 하는 결과와 그 주변의 불변 클래스를 아주 구체적으로 명시하고, 에이전트들에게 그에 맞춰 뭔가를 만들라고 하면…