goldtag

Harness Engineering in Practice — How to Apply It to Your Project Right Now You understand the concept (Part 3). You've seen how Anthropic implements it (Part 4). That leaves one question. How do you apply it to your own project? This post covers concrete methods for putting harness engineering to work in production, and the shifts in the developer's role that this paradigm will bring. Principle 1: Start from Failure This is Mitchell Hashimoto's principle — and one the HumanLayer team arrived at independently. Don't try to design the ideal harness upfront. Every time the agent fails, add a structural safeguard that prevents that failure from recurring. In HumanLayer's words: "Have a shipping bias. Only touch the harness when the agent actually fails." The mindset resembles TDD (Test-Driven Development). Just as you write a failing test first and then write the code to make it pass — you observe the agent's failure patterns and add harness eleme...

Harness Engineering in Practice — How Anthropic Designs AI Agents The previous post covered the concept and components of harness engineering. This time, it's the real thing. Drawing on the concrete architecture patterns Anthropic published in their official engineering blog — along with experimental results from the OpenAI Codex team — let's look at how harnesses are actually applied in practice. The Basic Structure of an Agent Loop: The Inner Loop At the heart of every AI agent sits an agent loop . In Claude Code, it's called queryLoop . At its core, it's a while(true) loop. while (true) { 1. Prepare context (plan-mode attachments, task reminders) 2. Call the model (streaming API call) 3. Execute tools (detect tool call → validate schema → check permissions → execute) 4. Decide whether to continue (does the model have more to do?) } Each iteration is one "think, act, observe" cycle. The model thinks, invokes a tool, observes the resul...

What Is Harness Engineering — Designing the Reins for AI Agents In Part 1 of this series, I talked about the decline of prompt engineering. With CLI-based tools on the scene, the value of manually crafting elaborate prompts was fading. But as 2026 unfolded, I realized that what replaced prompt engineering wasn't simply "better tools." Prompt engineering gave way to context engineering, and now context engineering is giving way to an entirely new paradigm: harness engineering . In this post, I'll break down what harness engineering is, why it matters right now, and what its key components look like. A Harness for a Horse, a Harness for an Agent A harness originally refers to the tack fitted onto a horse. Bridle, saddle, stirrups — equipment designed not to suppress the horse's power, but to channel it in the right direction. In AI, the term means exactly the same thing. A harness is the entire external system that controls and directs an AI agent's power...

기본 설정을 의심하라 — 모델과 하네스의 과적합이 당신의 에이전트를 느리게 만든다 이 시리즈의 3편에서 흥미로운 사실을 언급했다. Terminal Bench 2.0에서 Claude Opus 4.6은 Claude Code — 자신이 훈련된 하네스 — 안에서 33위였지만, 다른 하네스에서는 5위권으로 올라갔다. 이 숫자가 의미하는 바를 제대로 소화하지 않고 넘어갔다. 4편에서 Anthropic의 아키텍처를, 5편에서 실전 가이드를 다루면서, 가장 반직관적이고 실전적으로 중요한 인사이트를 놓쳤다. 기본 하네스를 그대로 쓰는 것이 최적이 아닐 수 있다. 이 글에서 그 이야기를 마무리한다. 과적합은 어떻게 발생하는가 프론티어 코딩 모델은 자신의 하네스 안에서 후훈련(post-training)된다. Claude는 Claude Code 환경에서, Codex 모델은 Codex 환경에서 수천 시간의 코딩 작업을 수행하며 최적화된다. 이 과정에서 모델은 특정 하네스의 패턴에 적응한다. Claude Code가 도구를 호출하는 방식 에러를 반환하는 형식 컨텍스트를 구성하는 순서 파일 편집 도구의 인터페이스 모델은 이 특정 환경에서의 성능을 극대화하도록 훈련된다. 문제는 극대화가 일반화를 보장하지 않는다 는 것이다. 머신러닝에서 과적합(overfitting)이란, 훈련 데이터에 너무 잘 맞춰져서 새로운 데이터에 대한 성능이 오히려 저하되는 현상이다. 모델-하네스 관계에서도 같은 일이 일어난다. 모델이 기본 하네스의 특이점(quirk)에까지 적응하면서, 다른 구성에서의 잠재력이 묻힌다. 구체적 사례: Codex와 apply_patch OpenAI의 Codex 모델이 apply_patch 라는 파일 편집 도구에 극도로 결합된 사례가 있다. Codex 모델을 다른 하네스(OpenCode)에서 사용하려 했을 때, 별도의 apply_patch 도구를 추가해야 했다. 모델이 그 특정 도구 인터페이스 없이는 파일 편집을 제대로 수행하지 못했기 때문이다. 모델이...

하네스 엔지니어링 활용편 — 내 프로젝트에 당장 적용하는 법 개념을 이해했고(3편), Anthropic의 구현을 살펴봤다(4편). 이제 남은 질문은 하나다. 내 프로젝트에 어떻게 적용하는가? 이 글에서는 하네스 엔지니어링을 실무에 활용하는 구체적인 방법과, 이 패러다임이 가져올 개발자 역할의 변화를 다룬다. 원칙 1: 실패에서 시작하라 Mitchell Hashimoto의 원칙이자, HumanLayer 팀이 독립적으로 같은 결론에 도달한 것. 이상적인 하네스를 미리 설계하려 하지 마라. 에이전트가 실패할 때마다, 그 실패를 구조적으로 방지하는 장치를 추가하라. HumanLayer 팀의 표현: "출하 편향을 가져라. 에이전트가 실제로 실패한 경우에만 하네스를 건드려라." 이것은 TDD(Test-Driven Development)의 사고방식과 닮아 있다. 실패하는 테스트를 먼저 만들고, 그것을 통과시키는 코드를 작성하는 것처럼 — 에이전트가 실패하는 패턴을 관찰하고, 그것을 방지하는 하네스 요소를 추가한다. ETH Zurich의 연구가 이 원칙을 뒷받침한다. 138개 에이전트 설정 파일을 테스트한 결과: LLM이 생성한 설정 파일: 성능 저하 + 비용 20% 이상 증가 사람이 작성한 설정 파일: 겨우 4% 개선 코드베이스 개요, 디렉터리 목록: 아무 도움도 안 됨 에이전트는 저장소 구조를 스스로 충분히 탐색한다. 보편적으로 적용되는 최소한의 지침만 투입하면 된다. 원칙 2: 적게 넣어라 하네스 엔지니어링에서 가장 반직관적인 원칙이다. 더 많은 규칙, 더 많은 도구, 더 많은 에이전트가 항상 더 나은 결과를 만들지 않는다. Vercel의 사례: 초기에 모든 도구를 제공했지만, 도구를 줄이자 오히려 성능이 향상됐다. MCP 서버를 많이 연결하면? 도구 정의 자체가 시스템 프롬프트의 토큰을 소비한다. 200K 컨텍스트 윈도우가 MCP 도구가 너무 많으면 실제로는 70K밖에 안 될 수 있다. HumanLayer의 해...

하네스 엔지니어링 적용편 — Anthropic은 AI 에이전트를 어떻게 설계했나 이전 글에서 하네스 엔지니어링의 개념과 구성 요소를 다뤘다. 이번에는 실전이다. Anthropic이 공식 엔지니어링 블로그에서 공개한 구체적인 아키텍처 패턴들과, OpenAI Codex 팀의 실험 결과를 바탕으로 하네스가 실제로 어떻게 적용되는지 살펴본다. 에이전트 루프의 기본 구조: Inner Loop 모든 AI 에이전트의 심장에는 에이전트 루프(Agent Loop) 가 있다. Claude Code에서는 이것을 queryLoop 라고 부른다. 본질적으로 while(true) 루프다. while (true) { 1. 컨텍스트 준비 (계획 모드 첨부파일, 작업 리마인더) 2. 모델 호출 (스트리밍 API 호출) 3. 도구 실행 (도구 호출 감지 → 스키마 검증 → 권한 확인 → 실행) 4. 계속 결정 (모델이 더 할 일이 있는가?) } 각 반복이 하나의 "사고 → 행동 → 관찰" 사이클이다. 모델이 생각하고, 도구를 호출하고, 결과를 관찰하고, 다시 생각한다. 도구 실행 흐름 은 이렇다: 모델이 출력에서 도구 호출을 생성 하네스가 도구 호출을 감지하고 텍스트 생성을 중지 입력을 스키마(Zod 검증 JSON Schema)에 대해 검증 권한 파이프라인 실행 (일반 규칙 → 도구별 체크 → 자동 분류기 → 사용자 승인 폴백) 도구 핸들러가 작업 실행 결과가 모델의 컨텍스트에 다시 주입 루프 계속 이것이 Inner Loop다. 대부분의 간단한 작업은 이 루프 안에서 완료된다. 하지만 복잡한 작업, 특히 여러 시간이 걸리는 장기 실행 작업에서는 이것만으로 부족하다. 컨텍스트 윈도우가 가득 차고, 모델의 추론 능력이 저하된다. Outer Loop: Ralph Loop 패턴 Anthropic이 장기 실행 작업을 위해 개발한 것이 Ralph Loop 패턴이다. 아이디어는 단순하다. 모델이 작업을 끝내려고 할...