오케스트레이터가 서브 에이전트를 생성할 때의 노력 수준(effort level) 설정

그게 올바른 축이지. 내가 보기엔 뻔한 방식은 아님. 작업이 얼마나 어려워 보이느냐가 아니라, 작업이 무엇을 건드리느냐에 따라 라우팅하는 거니까.

근데 그 세 가지 방법의 공통적인 빈틈을 하나 지적해야겠음. 전부 '범위'에 관한 거임. 얼마나 많은 영역을 다루는지, 어떤 종류인지, 범위가 얼마나 큰지. 자세히 보면, 그중 어떤 것도 '실수가 발생했을 때 되돌리기 쉬운가'를 묻지 않음. 그래서 되돌릴 수 있는 넓은 리팩토링과 인증 관련 한 줄 수정이 같은 곳에 떨어지게 됨.

그리고 '꽤 안정적'이라고 했는데, 그게 매트릭스를 잘 따르는 게 안정적인 건지, 아니면...

내가 말한 대로 --> Fable 쓰지 마, max 쓰지 마 등의 규칙을 잘 따르고 안정적임.

> 그래서 되돌릴 수 있는 넓은 리팩토링과 인증 관련 한 줄 수정이 같은 곳에 떨어지게 됨.

정말 그렇게 생각함? 새로운 기능을 만들거나 리팩토링을 할 때, 나는 에이전트와 함께 다단계 프로세스를 거치는 경향이 있음.

기본적으로 나는

• 범위 정의
• 사양 작성
• 기술적 구상 작성
• 실행 계획 작성 (어떤 순서로 무엇을 구현할지, 구상 단계에서 각 작업을 작성함)...

맞는 말임. 그리고 아니, 지금은 확신이 좀 줄었네. 이미 검증된 계획 내에서 라우팅하는 건 맹목적인 라우팅이 아닌데, 내가 그걸 맹목적인 것처럼 취급했네.

여전히 그 축이 빠져 있다고 생각하지만, 스택의 더 아래쪽에 있는 문제인 것 같음.

당신의 게이트는 계획이 올바른지 묻고, 매트릭스는 작업에 얼마나 많은 마력이 필요한지 묻지.

둘 다 이 작업이 잘못되었을 때 비용이 얼마인지 묻지는 않음.

내가 보기엔, 인증 관련 한 줄 수정은 여전히 좁은 범위, 단일 영역, 명확한 사양으로 읽히고 Sonnet에 떨어짐.

그리고 '내가 스스로 확인한다'는 건...

> 내가 보기엔, 인증 관련 한 줄 수정은 여전히 좁은 범위, 단일 영역, 명확한 사양으로 읽히고 Sonnet에 떨어짐.

맞음, 근데 그게 문제라고 생각하지 않음. 설령 그 한 줄이 실패했을 때 정말 치명적일 수 있는 중요한 도메인/모듈에 있더라도, 사양과 테스트가 그런 문제를 방지해주니까. 내 프로세스에서는 더 뛰어난 다른 에이전트가 전체 그림을 확인하는 작업을 수행함. 그리고 나는 이 작업의 대부분을 Opus/Fable로 처리함.

부분적으로는 맞음. 그리고 내가 라우팅 호출을 유일한 방어선인 것처럼 취급했다는 당신 말이 맞음. 그건 아님.

사양과 전체 그림 확인에 Opus를 배치하는 건 이미 '폭발 반경 라우팅'을 수행하는 거임. 작업별 라우팅보다 더 빠르고 거친 방식이긴 하지만.

내 생각에 살아남는 건 작은 것들임. 테스트는 당신이 얼마나 자주 틀리는지를 바꾸지, 틀렸을 때의 비용을 바꾸지는 않음.

그 점은 여전히 고수하고 싶음.

솔직히 말해서, 당신 방식은 대부분의 사람들보다 훨씬 잘 방어되어 있음.

> 테스트는 당신이 얼마나 자주 틀리는지를 바꾸지, 틀렸을 때의 비용을 바꾸지는 않음.

맞는 말임. 내가 틀렸다는 걸 깨닫고 답변을 수정했음.

하지만 내 철학은 어차피 AI는 비결정적이라는 거임. 그래서 Sonnet이든 Opus든 100% 실행을 신뢰할 수는 없음.

그래서 나는 실행자들을 위해 모든 사양과 테스트가 준비되었는지 확인하면서, 계획 단계에 시간과 비용을 투자할 거임.

만약 기능이 작거나 중요하지 않다면, 그냥 대충 코딩하고 수동으로 테스트함.