여기에서는 업데이트 후 모델이 "멍청해지거나" "게으르다"고 주장하는 게시물이 많이 보입니다. 워크플로를 변경하기 전까지 동일한 문제가 발생했습니다.

나는 그것을 **콜롬보 방법**이라고 부릅니다. 네, 1970년대 TV쇼 탐정이었죠.

철학은 간단합니다. 코드베이스를 무슨 일이 일어났는지 모르는 범죄 현장처럼 다루십시오. 당신은 혼란스러운 탐정의 역할을 맡습니다. 먼저 에이전트가 "그들의 이야기를 잠그도록" 하고 그들이 진실을 알고 있다고 확신할 때만 "함정을 설정"합니다(적용 누르기).

토큰을 저장하고, 환각을 중지하고, 복잡한 버그를 수정하는 데 사용하는 정확한 작업 흐름은 다음과 같습니다.

### 1. 조사(질문 모드)

상담원에게 문제를 해결하라고 지시하는 것부터 시작하지 마세요. 혼란스러운 동료처럼 행동하는 것부터 시작해 보세요. 저는 항상 `묻기` 모드를 먼저 사용합니다.

**메시지:** *"앱에 로그인했는데 이 버튼을 클릭하면 그렇게 됩니다. 이렇게 해야 합니다. 이것이 어떻게 작동하는지 정확히 검토하고 잠재적인 문제를 찾을 수 있습니까?"*

이로 인해 **검색**이 강제됩니다. 파일을 검사하여 질문에 답하고 문제를 해결하기 전에 창에 올바른 컨텍스트를 효과적으로 로드합니다.

### 2. "한 가지만 더..."(수사적 질문)

상담원이 일반적인 답변을 제공하는 경우 아직 빌드하지 마세요. 내면의 Columbo를 전달하고 극단적인 경우에 대한 수사학적 질문을 해보세요. 단순히 추측만 하는 것이 아니라 실제로 논리를 이해하고 있는지 확인하는 것입니다.

**프롬프트:** *"현재 구현에서 사용자가 X를 수행하면 어떻게 되나요? Y도 수행하면 어떻게 되나요? 그리고 여기서 네트워크가 실패하면 어떻게 될까요?"*

설명이 현실과 100% 일치할 때까지 계속하세요. 여기서 환각을 보인다면 비용이 전혀 들지 않습니다. 코딩하는 동안 환각을 느끼면 디버깅하는 데 한 시간이 소요됩니다.

### 3. 고백 (플랜 모드)

에이전트가 "스토리에 고정"되면 '작성자(계획)' 모드로 전환하세요.

** 프롬프트:** *"이 수정 사항에 대한 구체적인 구현 계획을 작성하십시오."*

그러면 마크다운 파일(예: `plan.md`)이 생성됩니다. LLM에는 최신 편향이 있기 때문에 이는 매우 중요합니다. 채팅이 길어지면 상담원이 시작을 잊어버릴 수도 있습니다. 계획 파일은 나중에 참조할 수 있는 영구 앵커입니다. 이를 수동으로 검토하세요. **계획이 틀리면 코드도 틀리게 됩니다.**

### 4. 처형

이제 조사, 심문, 서면 자백을 거친 후에야 실제로 코드 작성을 허용할 수 있습니다.

1. 계획 파일을 참조하십시오.
2. 가장 똑똑한 모델을 선택하세요(예: Opus 4.5 사고).
3. 빌드를 클릭합니다.

코드에 흥을 돋우려는 노력을 멈추고 탐정처럼 행동해보세요. 그것은 모든 것을 변화시킵니다.

이제 Composer 1.5를 사용할 수 있습니다.