5분의 생각 루프: 코딩 에이전트가 코딩을 전혀 시작하지 못하는 이유

ChatGPT로 작성한 기획서가 있습니다. 2,000단어의 분량, 30개의 글머리 기호, 4개의 표, 3개의 ‘중요 참고 사항’, 그리고 거킨(Gherkin) 문법으로 작성된 인수 기준까지 포함되어 있습니다. 누가 보아도 완벽한 지시서처럼 보입니다. 이를 코딩 에이전트에 붙여넣습니다. 상태 표시줄이 ’생각 중(Thinking…)’으로 바뀌고는 그 상태 그대로 멈춰 섭니다.

5분이 지나고, 10분이 흘러갑니다. 파일 하나 읽지 않고, 도구(tool) 하나 호출하지 않으며, 코드 한 줄 작성하지 않습니다. 스피너만 하염없이 돌며 토큰을 태우고 있을 뿐입니다. 결국 작업을 취소하고 프롬프트를 훨씬 짧게 다시 작성해 입력하자, 에이전트는 불과 90초 만에 전체 작업을 완수합니다.

이는 운이 나빴던 것도 아니고, 에이전트가 고장 난 것도 아닙니다. 에이전트 기반 코딩 워크플로우를 정체시키는 가장 흔한 원인이자, 거의 항상 사용자가 자초한 결과입니다. 사용자의 눈에 가장 친절하고 상세해 보였던 프롬프트를 모델은 다음과 같이 해석했기 때문입니다. “행동하기 전에 극도로 깊이 심사숙고하라.”

에이전트가 멈춘 것이 아닙니다 — 생각하라는 지시를 받았을 뿐입니다

추론 기능이 강화된 모델(Reasoning model)은 정해진 양만큼만 생각하지 않습니다. 작업이 얼마나 복잡해 보이는지에 대략 비례하여 생각(추론)에 자원을 할당합니다. 이는 모호성과 제약 조건의 밀도가 높을 때 더 길게 숙고하도록 강화 학습(RL) 과정에서 보상받은 학습된 정책(learned policy)입니다. 이 정책이 바로 핵심 메커니즘이며, 여러분의 워크플로우는 모델이 과잉 반응하도록 훈련받은 모든 요소를 먹잇감으로 던져주고 있는 셈입니다.

한 문단으로 요약한 인과 관계는 다음과 같습니다. LLM에게 “코딩 에이전트에 줄 좋은 프롬프트를 작성해 줘”라고 요청하면, LLM은 **완전성(comprehensiveness)**을 최적화합니다. 인간에게는 빈틈없이 포괄적인 것이 품질 높은 것으로 보이기 때문입니다. 그 결과 방대한 요구 사양서가 생성됩니다. 완벽한 아키텍처 요구사항, 엣지 케이스 체크리스트, “X, Y, Z를 반드시 처리해야 함”과 같은 제약 조건, 성능 및 보안 고려사항, 디렉터리 및 파일 구조 명시 등이 빼곡히 들어찹니다. 여러분이 나열한 모든 제약 조건은 추론 모델이 코드를 작성해도 안전하다고 안심하기 전까지 충족하고 검증해야 하는 변수가 됩니다. 문제는 제약 조건 간의 상호작용이 초선형적(super-linearly)으로 증가한다는 점입니다. 15개의 제약 조건이 주어지면, 모델은 생각 단계에서 대략 100개에 달하는 쌍별(pairwise) 상호작용을 사실상 모두 검토하게 됩니다. 사람이 작성한 프롬프트에는 암묵적인 우선순위(먼저 언급한 내용이 가장 중요함)가 존재하지만, LLM이 생성한 프롬프트는 모든 것에 ‘중요’ 플래그가 붙은 평탄한(flat) 목록이므로 어떤 것도 우선순위에서 배제할 수 없습니다.

요약하자면 이렇습니다. 추론 모델이 가장 오랫동안 생각하게 만드는 단 하나의 신호, 즉 **‘인지된 작업 복잡도(perceived task complexity)’**를 극대화하는 파이프라인을 구축해 놓고, 에이전트가 코드를 짜기 전에 왜 아키텍처 전체 검토를 끝없이 하고 있는지 의아해하고 있는 것입니다.

5분의 침묵 속에서 일어나는 일

에이전트가 멈춰 있는 시간은 결코 빈 시간이 아닙니다. 그 내부에서는 구체적인 연산이 진행되고 있으며, 이는 예측 가능한 순서를 따릅니다.

1. 요구사항 추출 (Requirement extraction). 모델은 30개의 글머리 기호, 4개의 표, 3개의 ’중요 참고 사항’을 파싱하여 제약 조건 그래프(constraint graph)를 구성합니다.
2. 충돌 감지 (Conflict detection). 해당 항목들이 서로 모순되는 지점이나, 에이전트 자체의 시스템 프롬프트와 충돌하는 지점(“항상 코드베이스를 먼저 탐색하라” vs “Y 아키텍처를 사용하여 X를 구축하라”)을 찾아냅니다.
3. 계획 폭발 (Planning explosion). 단 하나의 파일도 건드리지 않은 채, 모든 조건을 완벽히 충족하는 단계별 계획을 수립하려고 시도합니다.
4. 그라운딩 실패 (Grounding failure). 아직 실제 환경의 피드백(파일 읽기, 테스트 실행 등)이 전무하기 때문에, 모델의 시뮬레이션은 한 번도 검사해보지 않은 저장소의 가상 상태를 상대로 자신의 논리를 끝없이 재검증하는 늪에 빠집니다.

사용자가 ’생각 중’으로 보는 화면의 실체는, 사전에 무결한 계획을 요구하는 ’사용자의 프롬프트’와 먼저 증거를 수집하라고 요구하는 ’에이전트 하네스(agent harness)’라는 두 명의 상사 사이에서 모델이 진자 운동을 하고 있는 상태입니다. 이 충돌을 해결하지 못하기에 모델은 스크래치패드(scratchpad, 생각 공간)에 머무르게 됩니다. 그대로 방치하면 추론 예산이 넉넉한 모델들은 5분 이상의 시간 동안 1만~2만 개에 달하는 숨겨진 추론 토큰을 기꺼이 소모하면서도 첫 번째 도구 호출(tool call)조차 발생시키지 않습니다. <think> 블록이 설정된 예산 한도(budget ceiling)까지 끝까지 도달해 버립니다. 이는 스스로 복구되지 않습니다.

LLM이 생성한 프롬프트가 에이전트에게 독이 되는 이유

ChatGPT는 ‘완전해 보이도록’ 최적화되어 있습니다. 반면 코딩 에이전트는 ‘행동하도록’ 최적화되어 있습니다. 이는 정반대의 목표입니다. 전형적인 LLM 작성 프롬프트는 단독으로도 분석 마비(analysis paralysis)를 일으키기에 충분한 일곱 가지 치명적인 패턴을 보입니다.

1. 제약 조건 과부하 (Constraint overload). 15~20개의 ’요구사항’은 사람에게는 꼼꼼함으로 읽힙니다. 하지만 추론 모델에게는 제약 조건 만족 문제(constraint-satisfaction problem, CSP)가 됩니다. 첫 번째 도구를 호출하기 전에 이 모든 제약 조건을 동시에 만족시켜야 합니다. 요구사항 간의 상호 관계에 모호함이 발생해도 에이전트는 되물어볼 수 없습니다. 대부분의 에이전트는 스스로 진행하도록 설정되어 있으므로, 모델은 오직 ’생각’을 통해서만 이를 해결하려 듭니다.

2. 잘못된 정밀성 (False precision). “서비스 레이어, 레포지토리 패턴, DTO를 갖춘 클린 아키텍처를 사용하라.” 프롬프트를 생성한 모델은 실제 코드베이스를 볼 수 없기 때문에 머릿속에서 이러한 아키텍처를 창작해 냅니다. 이제 코딩 에이전트는 아직 읽어보지도 않은 코드베이스에 이 아키텍처가 부합하는지 여부를 추론해야 하는 짐을 떠안게 됩니다.

3. 그라운딩 부재 (No grounding). “src/components/Auth.tsx에 파일을 생성하라.” 에이전트는 해당 경로가 존재하는지, 주변 모듈의 컨벤션이 어떤지 전혀 알지 못합니다. 사용자의 지시를 따를 것인지, 아니면 먼저 코드베이스를 탐색할 것인지를 결정하느라 추론 예산을 낭비합니다.

4. 부정형 지시 (Negative instructions). “X를 사용하지 마라. Y를 하지 마라. Z를 피하라.” 추론 모델은 부정어에 집착합니다. 자신이 그 규칙을 위반하지 않고 있음을 증명하는 데 많은 추론 예산을 쏟아붓습니다. 모든 “하지 마라”는 모델에게 검증해야 할 또 하나의 제약 조건입니다.

5. 페르소나 충돌 (Identity conflict). “당신은 전문 시니어 엔지니어입니다…” — 이는 에이전트가 누구이며 어떻게 작동해야 하는지 이미 정의해 둔 에이전트 자체의 시스템 프롬프트 위에 덧씌워집니다. 두 개의 정체성 프레임이 충돌하면서, 모델은 둘 중 어느 프레임이 우선하는지 조율하느라 토큰을 소모합니다.

6. 형식 숭배 (Format worship). 표, JSON 스키마, 거킨(Gherkin) 인수 기준. 프롬프트 생성 모델은 전문적으로 보이기 위해 이를 추가합니다. 하지만 이를 소비하는 코딩 에이전트 모델에게 이들은 조율해야 할 추가 토큰이자, 행동하기 전에 내부 일관성을 검증해야 할 구조적 부담에 불과합니다.

7. 종료 조건 부재 (No exit condition). 훌륭한 에이전트 프롬프트는 목표 + 컨텍스트 + 두 개의 제약 조건으로 구성됩니다. 반면 LLM이 생성한 프롬프트는 완료의 정의(definition of done)가 없는 수필과 같습니다. 따라서 플래너(planner)는 언제 계획 수립을 멈추고 안심하고 코딩을 시작해야 할지 갈피를 잡지 못합니다.

패턴이 보이십니까? 이들 중 대부분은 에이전트가 어차피 따랐을 지침이거나, 실제 코드를 직접 살펴보아야만 해결할 수 있는 제약 조건들입니다. 프롬프트가 코드베이스를 보지 않은 채 장님처럼 작성되었기 때문에, 에이전트는 프롬프트가 만들어낸 가상의 문제를 해결하는 데 발이 묶이고 맙니다.

추론 모델이 상황을 10배나 악화시키는 이유

일반적인 챗 모델(chat model)에서는 시스템 프롬프트가 무거워도 고민을 줄이고 일단 작업을 바로 진행하는 경향이 있습니다. 하지만 추론 기능이 활성화된 코딩 모델은 정반대로 작동합니다.

• 생각 기능이 기본적으로 켜져 있습니다 (Thinking is on by default). 최근의 코딩 특화 추론 모델 중 다수는 확장 추론(extended thinking)을 완전히 끌 수 있는 옵션을 제공하지 않으며, 단지 노력(effort) 다이얼만 조절할 수 있습니다. 예를 들어 GLM-5.x는 추론 노력으로 low, high, max를 제공하며, 통합 환경에서 별도 설정이 없으면 기본적으로 최고 설정(max)으로 동작합니다. o-시리즈 모델들도 마찬가지입니다. 이 다이얼의 기본값은 모델이 제공하는 가장 비싼 솔루션 탐색 모드입니다.
• 숙고하도록 훈련받았습니다 (They are trained to deliberate). ARC(Agentic, Reasoning, Coding) 세대의 모델들은 행동하기 전에 더 깊이 생각하도록 강화 학습되었습니다. 이는 난해한 디버깅 작업에서는 훌륭한 기능이지만, “이 변수 이름을 바꿔라” 같은 단순 작업에는 불필요한 세금과 같습니다.
• 하네스가 기본 문턱을 높입니다 (The harness raises the floor). 코딩 에이전트에는 이미 무거운 자체 시스템 프롬프트(먼저 탐색하라, 도구를 사용하라, 컨벤션을 따르라, 테스트를 실행하라)가 탑재되어 있습니다. 그 위에 ChatGPT가 작성한 수필을 얹으면, 모델은 “행동하기 전에 먼저 생각하라”는 다중 레이어의 압박을 받게 되며, 각 레이어는 더 많은 스크래치패드 작성을 정당화합니다.
• 메타 지시어는 문자 그대로의 기폭제입니다 (Meta-instructions are literal triggers). 생성된 프롬프트를 다시 읽어보십시오. “코드를 작성하기 전에 아키텍처를 신중하게 생각하라”, “먼저 상세한 계획을 수립하라”, “엣지 케이스와 예외 처리를 고려하라”, “솔루션이 프로덕션 환경에 적합한지 확인하라” 중 적어도 하나는 거의 확실하게 포함되어 있을 것입니다. 이는 단순한 미사여구가 아니라, 추론 시간을 연장하라는 직접적인 명령입니다. 모델은 여러분이 무심코 내린 지시를 충실하게 따르고 있을 뿐입니다.

또한 반드시 알아두어야 할 치명적인 병리적 변종도 있습니다. 특정 서빙 스택에서는 복잡한 시스템 프롬프트, 다수의 가용 도구, 자동 도구 선택 기능이 결합될 때 추론 모델이 퇴행적 루프(degenerate loop)에 빠지는 현상이 보고된 바 있습니다. 노력 설정과 관계없이 동일한 문자가 수천 번 반복되거나 끝없이 계획만 다시 도출하며 도구 호출은 결코 일어나지 않습니다. 도구가 적고 단순한 프롬프트에서는 이 문제가 발생하지 않습니다. 이런 현상을 목격했다면 이는 프롬프트 문제가 아니라 서빙 측의 결함입니다. 하지만 실질적인 대처법은 동일합니다. 작업을 취소하고, 프롬프트를 줄이고, 다시 시도하거나 엔드포인트를 변경해야 합니다.

해결책: 단 하나의 목표, 컨텍스트, 세 가지 제약 조건

이 모든 비효율을 방지하는 원칙은 단 한 줄로 요약됩니다.

목표: 한 문장. 컨텍스트: 살펴볼 파일들. 제약 조건: 최대 세 개의 글머리 기호.

다음은 ChatGPT에게 “상세한 프롬프트를 작성해 달라”고 요청했을 때 생성되는 전형적인 나쁜 프롬프트의 형태입니다.

당신은 전문 풀스택 엔지니어입니다. Next.js 14 App Router, TypeScript, Prisma, Tailwind를 사용하여 현대적이고 확장 가능하며 프로덕션에 즉시 적용 가능한 인증 시스템을 구축하십시오. 구현하기 전에 기존 코드베이스를 철저히 분석하고 모든 엣지 케이스를 고려해야 합니다. 요구사항: (1) OWASP Top 10에 대해 안전해야 함… (20) 90% 커버리지의 포괄적인 테스트를 포함해야 함… [이후 1,500단어 추가]

그리고 동일한 의도를 에이전트가 즉각 실행할 수 있도록 바꾼 프롬프트입니다.

목표(Goal): 기존 앱에 이메일 + 비밀번호 로그인 기능을 추가합니다.
컨텍스트(Context): @src/app/layout.tsx @prisma/schema.prisma — 현재 인증 기능 없음.
제약 조건(Constraints): next-auth를 사용하고, 기존 UI를 유지하며, 결제 관련 코드는 건드리지 마십시오.

두 번째 버전이 완벽히 작동하는 이유는 복잡하게 분해할 요소가 없기 때문입니다. 모든 항목이 에이전트가 직접 검사할 수 있는 파일과 모순 없이 내릴 수 있는 결정에 직접 매핑됩니다. 솔루션 탐색 공간이 작기 때문에, 모델은 단 한 번의 패스만으로 “행동하기에 충분한 이해”에 도달하여 첫 번째 도구를 즉시 호출합니다.

만약 프롬프트 작성 과정에서 여전히 LLM을 활용하고 싶다면, 그 역할을 반대로 바꾸십시오. 지시서를 길게 쓰는 용도가 아니라 여러분의 의도를 압축하는 용도로 LLM을 사용하십시오. 프롬프트 생성 모델에 엄격한 포맷 제약을 부여하십시오.

아래의 내 아이디어를 코딩 에이전트용 프롬프트로 압축해 줘. 최대 500토큰. 형식: 목표 — 한 문장. 컨텍스트 — 살펴볼 파일. 제약 조건 — 최대 세 개의 글머리 기호. 아키텍처 설명 금지. “당신은 전문가입니다” 금지. 표 금지. 치명적인 경우가 아니면 “하지 마라” 목록 작성 금지. 내 아이디어: [내용 붙여넣기]

출력 분량을 제한하는 순간, 완전성을 추구하는 생성 모델의 불필요한 성향은 억제되고 여러분이 진정으로 원했던 뛰어난 요약 능력이 발휘됩니다.

완성도를 높이는 네 가지 추가 원칙

압축은 필수적이지만 그것만으로는 충분하지 않습니다. 네 가지 추가 원칙을 적용하면 남아 있는 빈틈을 메울 수 있습니다.

메타 지시어를 삭제하십시오 (Delete meta-instructions). 에이전트에 전달하는 모든 지시문에서 “신중하게 생각하라”, “먼저 계획을 수립하라”, “엣지 케이스를 고려하라”, “프로덕션 준비 수준을 보장하라” 같은 문장을 남김없이 제거하십시오. 추론 모델은 작업이 그럴 만한 가치가 있다고 판단되면 스스로 계획을 세웁니다. 그 판단을 모델에 맡기십시오. 이러한 문구를 지운다고 에이전트가 멍청해지는 것이 아닙니다. 불필요하게 심사숙고하라는 노골적인 명령을 거두어내는 것뿐입니다.

도구 우선 행동을 강제하십시오 (Force tool-first behavior). 첫 번째 행동을 저렴하고 구체적으로 만들 수 있는 직접적인 지시를 추가하십시오. “계획을 세우기 전에 대상 디렉터리를 먼저 검사하고 기존 테스트를 실행하는 것으로 시작하십시오. 전체 구현 계획을 한 번에 세우려 하지 마십시오.” 이는 에이전트의 루프를 ’생각 → 생각 → 생각 → 검사’에서 ’검사 → 생각 → 행동’으로 전환시킵니다. 초기에 확보된 실제 증거는 추측성 생각의 대부분을 단번에 무너뜨립니다. 모델의 의문점에 대한 답이 상상 속이 아니라 도구 실행 결과에 이미 담겨 있기 때문입니다.

상태 설명이 아닌 구체적인 실행 경계를 제시하십시오 (Give a concrete execution boundary, not a state description). “5페이지짜리 사양서에 설명된 대로 TTL, 축출 정책(eviction), 스레드 안전 작업을 갖춘 강력하고 확장 가능한 캐싱 레이어를 구현하라”는 지시와, “src/cache.ts에 캐시 인터페이스 초안을 작성하고 내가 검토할 수 있도록 멈추십시오”라는 지시를 비교해 보십시오. 후자는 단 하나의 결정, 하나의 파일, 하나의 검토 체크포인트만을 요구합니다. 초기 협업 단계를 작고 구체적인 경계로 쪼개는 것은 에이전트가 전체 기능에 대한 거대한 정신적 시뮬레이션을 사전에 돌리는 것을 방지하는 가장 확실한 방법입니다.

종료 조건과 크기 가드를 추가하십시오 (Add an exit condition and a size guard). 놀라운 효과를 내는 두 문장이 있습니다. “요구사항을 충족하는 가장 작고 일관된 변경을 선호하십시오. 작업에 명시적으로 요구되지 않는 한 기존 아키텍처를 재설계하지 마십시오.” 그리고 모호한 상황에 대비하여, “결정하기 어려운 경우 가장 단순한 옵션을 선택하고 진행하십시오.” 추론 모델은 계획이 완료되었다고 스스로 판단할 때 비로소 생각을 멈추며, 거기에는 별도의 타이머가 없습니다. 명확한 완료 정의와 완벽하지 않아도 괜찮다는 허용이 있어야만 모델의 생각이 수렴할 수 있습니다.

작업에 맞게 추론 노력(Reasoning Effort) 조절하기

노력(effort) 조절 다이얼이 존재하는 이유는 모든 작업에 동일한 설정이 들어맞지 않기 때문입니다. 이를 품질 슬라이더가 아니라 ’예산(budget)’으로 취급해야 합니다.

흔히 저지르는 실수는 ’최대(Max)’가 곧 ’최선(Best)’이라고 착각하는 것입니다. 최대 설정은 가능한 솔루션 공간에 대한 가장 비싼 탐색을 의미합니다. 이는 인증 시스템 전면 재설계에는 꼭 필요한 것이지만, 스캐폴딩 작업에는 심각한 낭비입니다. 올바른 원칙은 다음과 같습니다. 다음 유용한 행동에 도달하기에 충분한 만큼의 추론만 수행할 것. 만약 에이전트 통합 도구가 추론 노력을 전역적으로 High나 Max로 고정해 두고 있다면, 세션별로 이를 재정의하십시오. 새로운 기능의 첫 번째 파일을 만들 때는 Low로, 디버거가 켜져 있을 때만 High로 설정하는 식입니다.

그리고 이러한 멈춤 현상이 여전히 발생한다면(실제로 일어날 것입니다), 이를 미스터리가 아닌 하나의 ’신호’로 받아들이십시오. 도구 호출 없이 생각이 60초를 넘어가면 과감히 취소하십시오. 계획이 이미 발산해 버렸으며 스스로 정상화되지 않습니다. 프롬프트 내용을 약 70% 쳐내고 다시 시도하십시오. 원인을 규명하기 위해 비용이 들지 않는 간단한 실험을 해볼 수 있습니다. 에이전트에게 아주 사소한 작업(“foo() 함수 위에 주석 추가”)을 먼저 시켜본 뒤 본 작업을 시키는 것입니다. 사소한 작업마저 멈춘다면 프롬프트가 아니라 설정이나 모델 엔드포인트의 문제입니다. 반면 본 작업만 멈춘다면 작업 복잡도와 프롬프트 구조의 문제이며, 이는 여러분이 제어할 수 있는 영역입니다.

진짜 중요한 지표 측정하기: 첫 번째 도구 호출까지의 시간(TTFT)

이 실패 모드가 쉽게 간과되는 이유는 개발팀들이 엉뚱한 지표를 측정하기 때문입니다. 에이전트가 얼마나 오래 “생각했는가”에 신경 쓸 필요는 없습니다. 시계 시간(wall-clock) 기준의 생각 시간은 모델 추론, 제공자 대기열(queueing), 컨텍스트 처리, 실제 숙고 시간이 모두 뒤섞여 있기 때문입니다. 여러분이 실제로 측정하고 조치를 취할 수 있는 핵심 지표는 다음과 같습니다.

• 첫 번째 도구 호출까지의 시간 (Time to first tool call, TTFT) — 프롬프트 제출 후 에이전트가 실제 환경과 상호작용하기까지의 시간 간격입니다. 5분의 루프가 발생하는 지점이 바로 여기입니다.
• 첫 번째 편집까지의 시간 (Time to first edit) — 에이전트가 파일을 실제로 수정하기까지 걸리는 시간입니다.

첫 번째 도구 호출까지 4분이 걸리는 ‘느린’ 에이전트와 7초가 걸리는 ‘빠른’ 에이전트의 지능 수준이 다른 것이 아닙니다. 느린 쪽은 보정이 잘못되어 있을 뿐입니다. 코드를 열어볼 기회도 얻기 전에 불가능한 사전 계획 문제에 내던져진 것입니다. 규모 있게 에이전트를 운영하고 있다면 세션별로 두 지표를 가시화하고, 도구 호출이 전무한 상태에서 첫 번째 도구 호출 시간이 임계값을 초과할 때 알림을 발생시키십시오. “도구 호출 없음, 레포지토리 증거 없음, N분 경과 → 개입”이라는 와치독(watchdog) 규칙을 설정하면, 5분의 정체 현상은 답답한 대기가 아니라 시스템에 의해 감지되고 포착되는 조건이 됩니다.

핵심 결론

이 모든 현상은 결코 모델의 품질 문제가 아닙니다. 깔끔하고, 실제 환경에 그라운딩되어 있으며, 명확한 경계가 주어진 작업을 받은 추론 모델은 놀라울 정도로 빠르고 뛰어납니다. 반면, 한 번도 본 적 없는 코드베이스와 일치시켜야 하는 2,000단어 분량의 사양서가 주어지면, 추론 모델은 극도로 모호한 문제를 해결하기 위해 최대치로 생각하는 존재로 돌변하며 그 결과 나오는 5분간의 침묵은 지극히 당연한 산출물일 뿐입니다.

그러므로 에이전트가 얼마나 많이 생각할 수 있는지를 최적화하지 마십시오. 다음의 올바른 행동을 취하는 데 필요한 정보를 얼마나 빠르게 획득할 수 있는지를 최적화하십시오. 우리가 원하는 에이전트 루프는 생각 → 생각 → 생각 → 행동이 아닙니다. 충분한 추론 → 증거 수집 → 행동 → 관찰 → 검증의 반복입니다. 압축 원칙, 도구 우선 지시, 추론 노력 예산 책정, 와치독 규칙 등 다른 모든 기법은 모델을 바로 이 건강한 루프 안에 머물게 하기 위해 존재하는 것입니다.

목표는 직접 작성하십시오. 에이전트에게 살펴볼 파일을 정확히 지정해 주십시오. 최대 세 가지 제약 조건과 완료의 정의를 전달하십시오. 그런 다음 에이전트의 길을 터주십시오. 코딩을 시작하기 위한 계획을 세우느라 허비하던 바로 그 시간에, 에이전트는 이미 코드를 작성하기 시작할 것입니다.

연구 노트: [[Preventing Coding Agent Thinking loop]]