동일한 코드 리뷰 작업을 22개의 AI 에이전트에 제공했습니다. 동일한 풀 리퀘스트, 동일한 고정된 커밋, 동일한 프롬프트, 동일한 모델 — 유일한 변수는 각 에이전트가 프로젝트의 규칙을 로드하는 방식이었습니다. 가장 저렴한 구성이 가장 철저한 것으로 판명되었고, 그 이유는 컨텍스트 엔지니어링에 대해 일반적인 것을 말합니다.
TL;DR: 컨텍스트 엔진 다이제스트와 하나의 기계 판독 가능한 정책 파일의 직접 읽기가 모든 다른 전략을 능가했습니다: 리뷰당 $1.56 및 9.6/13 검증된 결과 — 문서 읽기보다 저렴($2.30, 8.6/13)하고 다이제스트만보다 낫습니다($1.77, 7.8/13). 모든 것을 읽는 것이 최악의 점수를 받았습니다(7.4/13). 모든 22개 에이전트는 Claude Opus 4.8에서 실행되었고, 22개 중 21개가 동일한 결론에 도달했습니다.
무엇: 하네스, 컨텍스트 엔진, 그리고 하나의 풀 리퀘스트
“하네스"란 무엇입니까?
AI 에이전트가 프로덕션 저장소에서 작동하도록 하려는 모든 진지한 시도는 거버넌스의 두 계층을 발전시킵니다.
산문 계층 — 규칙, 아키텍처 규칙, 테스트 표준. 우리의 저장소에서 그것은 CLAUDE.md와 docs/**입니다: “백엔드는 snake_case입니다,” “도메인은 절대 인프라를 가져오지 않습니다,” “모든 라우트 핸들러는 비동기입니다.” 인간이 읽습니다; 에이전트도 읽으라고 지시받습니다.
기계 판독 가능한 계층 — 하네스 구성. 우리의 것은 저장소의 모든 경로를 위험 계층으로 분류하고 각 계층에 적용 가능한 게이트를 첨부하는 단일 JSON 파일입니다. CI가 읽습니다. 병합 정책이 읽습니다. 그것은 조언이 아닙니다 — 그것은 정책입니다:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(용어 참고: “하네스"는 또한 에이전트 런타임 자체를 이름 지으며 — harnext 에서와 같이 도구, 기술, MCP 서버의 스캐폴딩, “코딩 에이전트 하네스.” 이 게시물에서, 하네스 구성은 저장소의 정책 파일이고 그러한 런타임과 CI 모두가 적용합니다.)
코드 리뷰어 — 인간이든 에이전트든 — 이 파일 없이는 “이 PR이 병합되도록 허용되는가?“를 판단할 수 없습니다. review-agent 체크가 건너뛴 Tier-3 PR은 모든 테스트가 녹색이더라도 정책 위반입니다. 그 예를 기억하십시오; 그것이 실험을 결정합니다.
두 계층이 모두 존재하기 때문에, 저장소는 게이트를 의무화합니다: 어떤 에이전트도 이 컨텍스트를 로드하기 전에 작업을 시작하지 않습니다 — 그리고 검토자가 확인하는 확인 블록을 통해 그렇게 했음을 증명합니다. 이 게시물이 답하는 질문은 단순합니다: 그 게이트를 만족하는 가장 저렴한 올바른 방법은 무엇입니까?
harnext와 meaninggrid를 만나세요
meaninggrid는 harnext
의 호스팅된 컨텍스트 엔진이며, QualityUnit의 MIT 라이선스, 공급자 불가지론적 코딩 에이전트 하네스(6개 도구 — read, write, edit, bash, skill, mcp — npm i -g harnext)입니다. 컨텍스트 엔진에 대한 공급자의 피치는 무뚝뚝합니다: “당신의 에이전트의 뇌.” 소스는 지속적으로 업데이트되는 인덱스 — “그리드” — 로 스트리밍되고, 쿼리당 엔진은 “토큰 효율적인 컨텍스트로 순위를 매기고 잘라내고, 하네스에 직접 연결됩니다”: 연속 인덱스, 관련성 순위 매김, 중복 제거 및 캐시. harnext의 헤드라인 숫자는 평균적으로 쿼리당 −89% 토큰입니다. 그것은 공급자의 주장입니다; 이 실험의 한 가지 목적은 우리 자신의 실제 작업에서의 숫자로, 그런 종류의 압축이 실제로 절감하는 것 — 그리고 그것이 드는 비용을 측정하는 것이었습니다.
우리의 배포에서 그리드는 저장소의 산문 문서를 수집합니다; 각 수집은 불변의 버전 관리된 스냅샷을 생성합니다. 에이전트는 MCP(meaninggrid.harnext.dev/mcp)를 통해 단일 context_research 호출로 쿼리하고 snapshot_id로 스탬프된 합성되고 인용된 다이제스트를 받습니다. 이는 에이전트가 확인 블록에서 인용해야 합니다 — 감사 가능한 컨텍스트가 구체화됩니다.
게이트가 생성하는 것 — 확인 블록(예제; 프로젝트 세부 사항 생략됨):
Loaded via: optimized hybrid (context-engine digest + policy file only).
- context_research call #1 (conventions / layering / testing / security /
risk tiers) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- context_research call #2 (LLM-provider integration checklist +
flow-engine extra-care rules) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Read harness config (full) from disk for exact tier patterns,
requiredChecks, mergePolicy, evidenceConfig.
Did NOT read CLAUDE.md or docs/* (covered by the digest).
snapshot_id는 실제입니다 — 검토자는 에이전트가 작업한 규칙의 정확한 버전을 확인할 수 있습니다.
세 가지 가설
실험은 미리 작성된 세 가지 테스트 가능한 예측을 정착시키기 위해 설계되었습니다:
H1 — 다이제스트는 다시 읽기보다 저렴합니다. 산문 문서를 한 번 수집하고, 모든 에이전트가 매 작업마다 모든 문서를 다시 읽는 대신 모든 에이전트에 컴팩트한 합성 다이제스트를 제공합니다. 참이면: 리뷰당 의미 있게 낮은 비용, 동일한 결과.
H2 — 패러프레이즈는 정책을 파괴합니다. 다이제스트는 “Tier 3은 인간 리뷰가 필요합니다"를 손실 없이 전달할 수 있습니다. "requireReviewAgent": true를 손실 없이 전달할 수 없습니다 — 검토자가 위반을 주장하기 위해 필요한 정확하고 인용 가능한 세부 사항이 요약에서 죽습니다. 참이면: 다이제스트만 보유한 에이전트는 리터럴 정책 파일을 보유한 에이전트가 잡아내는 게이트 위반을 체계적으로 놓쳐야 합니다.
H3 — 더 작은 컨텍스트가 더 깊게 읽습니다. 컨텍스트는 두 번 비용이 청구됩니다 — 한 번은 달러로, 한 번은 주의력으로: 윈도우의 모든 중복 문서는 검토 중인 코드와 경쟁합니다. 참이면: 모든 것을 읽는 것(다이제스트 + 모든 문서)은 이기지 못해야 합니다; 가장 작은 충분한 컨텍스트가 이겨야 합니다.
우리가 어떻게 테스트했는가
22개 에이전트가 우리의 프로덕션 모노레포에서 동일한 Tier-3 풀 리퀘스트를 검토했습니다(LLM 공급자 통합: 44개 파일, +2,111 줄, 실제 지분 — 청구 테이블, 흐름 엔진 라우팅). 5개 팔, 컨텍스트 로딩 단계에서만 다름:
| Arm | Context loading | n |
|---|---|---|
| meaninggrid | context-engine digest only (2× context_research) | 5 |
| disk | reads 7+ docs from disk — no context engine | 5 |
| hybrid | digest + reads ALL the docs | 5 |
| opt-hybrid | digest + reads ONE file: the harness config | 5 |
| cold | no convention context at all (baseline) | 2 |
기본 규칙: 1개 고정된 커밋, 1개 프롬프트 본문, 1개 모델 — Claude Opus 4.8 — 모든 팔이 단일 동시 배치로 인터리빙됩니다. 에이전트는 PR의 댓글 스레드에서 차단되었으므로 이전 실험 라운드가 유출될 수 없습니다. 모든 숫자는 토큰 사용이 API 요청당 중복 제거되고 목록 가격으로 가격이 책정된 원본 에이전트 트랜스크립트에서 나옵니다. 품질은 13개 독립적으로 검증된 실제 결함에 대해 각 리뷰의 본문에서 패턴 매칭되고 거짓 양성에 대해 수동으로 감사됩니다. 모든 팔에 걸친 결과 합의: 21/22가 REQUEST CHANGES라고 했습니다.
그래서 뭐: 가장 저렴한 구성도 품질에서 이겼습니다
| Arm | Cost / review | Findings (of 13) | Gate findings (of 3) | Wall clock |
|---|---|---|---|---|
| meaninggrid | $1.77 | 7.8 | 0.2 | 5:34 |
| disk | $2.30 | 8.6 | 0.8 | 4:35 |
| hybrid | $1.83 | 7.4 | 0.8 | 5:40 |
| opt-hybrid ★ | $1.56 | 9.6 | 1.4 | 4:55 |
| cold | $1.64 | 8.0 | 0.5 | 4:13 |
★ = 우리가 이제 저장소의 기본 기술로 제공하는 구성입니다. 벽시계에는 22개 에이전트를 동시에 실행하는 공유 경합이 포함됩니다.
H1 — 확인됨
다이제스트만 팔은 $1.77로 검토했고, 문서 읽기는 $2.30(−23%), 우승한 다이제스트 더하기 한 파일 팔은 $1.56(−32%) — 동일한 결과에서. 저축은 복합됩니다: 다이제스트는 그렇지 않으면 모든 후속 API 호출의 컨텍스트를 통해 탈 문서 스택을 대체합니다.
H2 — 결정적으로 확인됨
건너뛴 review-agent 체크 — 이 PR의 진정한 병합 정책 위반 — 5/5 리터럴 정책 파일을 보유한 에이전트에 의해 잡혔고, 1/5 다이제스트만 보유한 에이전트에 의해 잡혔습니다. 메커니즘은 정확히 H2가 예측한 것입니다: 그 발견을 작성하려면, 에이전트는 정확한 CI 체크 이름을 정확한 구성 필드와 일치시켜야 합니다 — 패러프레이즈는 인용 가능한 증거가 아니므로 다이제스트만 보유한 에이전트는 회피하고 드롭합니다. 하나의 직접 읽기가 그것을 복원합니다.
H3 — 확인됨
모든 것을 읽는 하이브리드는 모든 팔 중 가장 많은 컨텍스트를 수행했고 최악의 점수를 받았습니다(7.4/13), 가장 작은 충분한 팔은 최고 점수를 받았습니다(9.6/13) — 그리고 단일 가장 깊은 발견에서 모든 팔 중 최고였습니다. 3개 파일에 걸쳐 호출 경로를 추적하는 것이 필요한 데드 코드 버그입니다. 중복 산문이 정보를 추가하지 않았습니다; 그것은 코드와 주의력을 놓고 경쟁했습니다.
하나의 정직한 각주: 콜드 베이스라인(8.0/13 at $1.64)은 13개 결함의 대부분이 강력한 모델이 규칙 컨텍스트 없이 발견하는 일반 코드 버그임을 보여줍니다. 콜드가 할 수 없는 것은 정책의 절반 — 게이트, 계층, 병합 규칙 — 이것이 정확히 팔이 분리되는 곳입니다.
산문을 다이제스트로 큐레이션하세요. 정책 파일을 원본으로 읽으세요. 아무것도 두 번 읽지 마세요.
완전한 공개
- 모델: 모든 에이전트의 모든 API 호출은 claude-opus-4-8(Claude Opus 4.8)에서 실행되었습니다 — 가정하지 않고 각 트랜스크립트 라인의
model필드에서 확인되었습니다. 결과는 다른 모델에서 다를 수 있습니다; 더 작은 모델은 큐레이션된 컨텍스트에 덜 의존하지 않고 더 의존할 가능성이 높습니다. - 가격: 비용은 작성 당시 Anthropic 목록 가격을 사용합니다; 실제 청구는 다를 수 있습니다. 상대적 비교는 영향을 받지 않습니다.
- 샘플 크기: 팔당 n=5(콜드의 경우 n=2), 1개 PR, 1개 저장소, 1개 작업 유형. 게이트 효과(5/5 vs 1/5)는 날카롭습니다; 다른 곳의 발견당 비율은 ±1 에이전트입니다. 이것을 벤치마크가 아닌 강력한 파일럿으로 취급하십시오.
- 품질 메트릭: 리뷰 텍스트에 대한 패턴 감지(인용 제외), 거짓 양성에 대해 수동으로 감사됩니다. 검증된 결함의 언급을 계산하며, 전체 리뷰 웅변성은 아닙니다.
- 타이밍: 모든 22개 에이전트는 1대의 머신과 1개의 API 할당량을 공유했습니다; 벽시계 숫자는 그 경합을 포함합니다.
- 우리는 두 번 우리 자신을 수정했습니다: 초기 토큰 수는 2–3배 부풀려졌습니다(트랜스크립트의 라인당 사용 중복; 요청 ID 중복 제거로 수정됨), 그리고 이전 타임라인 시각은 벽 시간을 과소 계산했습니다(전체 간격 속성으로 수정됨). 두 수정 사항 모두 여기의 모든 숫자에 포함되어 있습니다.
지금 뭐: 루프를 훔치세요
우리가 제공한 것
우승 팔은 이제 저장소의 기본 check-context-first 기술입니다: 컨텍스트 엔진 다이제스트를 가져오고(두 호출), 디스크에서 정확히 하나의 파일 — 하네스 구성 — 을 읽고, 스냅샷과 정확한 게이트를 인용하는 확인 블록을 방출합니다. 하나의 측정된 약점, 하나의 한 줄 정책 수정, 같은 날 다시 검증되었습니다. 그 루프 — 측정, 컨텍스트 정책 수정, 다시 검증 — 은 당신이 어떤 컨텍스트 엔진을 사용하든 훔칠 부분입니다.
월요일에 할 수 있는 것
- 에이전트 컨텍스트를 두 가지로 분할하십시오: 산문(규칙, 아키텍처, 테스트) vs 기계 판독 가능한 정책(CI 게이트, 위험 계층, 병합 규칙).
- 산문을 다이제스트하세요; 정책을 절대 다이제스트하지 마세요. 컨텍스트 엔진을 통해 산문을 제공하세요 — meaninggrid는 우리의 것입니다 — 그리고 정책 파일을 컨텍스트 게이트에서 필수 그대로 읽도록 만드세요.
- 컨텍스트를 감사 가능하게 만드세요. 수집된 컨텍스트를 버전 관리하세요; 검토자가 실제로 확인할 수 있는 확인 블록에서 스냅샷 ID를 인용하도록 에이전트에게 요구하세요.
- 믿기 전에 측정하세요 — 우리를 포함하여. 자신의 저장소에서 팔당 몇 개의 에이전트는 패턴을 보기에 충분합니다. 분위기가 아닌 검증된 발견에 대해 리뷰를 점수 매기세요.
공개 초대
당신이 자신의 저장소에서 이 실험을 실행하면 — 동일한 팔, 당신의 모델, 당신의 하네스 — 우리는 정말로 당신의 숫자를 보고 싶습니다, 특히 우리의 것을 반박하면. 그리고 당신의 팀이 이와 같은 컨텍스트 게이트를 설정하는 데 도움을 원하거나 meaninggrid와 harnext 스택에 대해 이야기하고 싶다면, FlowHunt 팀에 연락하거나 harnext.dev 에서 오픈 소스 하네스를 찾으세요. 복제, 질문, 수정 모두 환영합니다.
