Demos a mesma tarefa de revisão de código a 22 agentes de IA. Mesmo pull request, mesmo commit fixado, mesmo prompt, mesmo modelo — a única variável era como cada agente carregava as regras do projeto. A configuração mais barata se mostrou ser a mais completa, e o motivo diz algo geral sobre engenharia de contexto.
TL;DR: Um digest de context-engine mais uma leitura direta do arquivo de política legível por máquina superou cada outra estratégia: $1,56 por revisão e 9,6/13 achados verificados — mais barato que ler os documentos ($2,30, 8,6/13) e melhor que apenas o digest ($1,77, 7,8/13). Ler tudo obteve a pior pontuação de todas (7,4/13). Todos os 22 agentes foram executados em Claude Opus 4.8, e 21 de 22 chegaram ao mesmo veredicto.
O Quê: um harness, um context engine e um pull request
O que é um “harness”?
Cada tentativa séria de deixar agentes de IA trabalhar em um repositório de produção cresce duas camadas de governança.
A camada em prosa — convenções, regras de arquitetura, padrões de teste. Em nosso repositório isso é CLAUDE.md e docs/**: “backend é snake_case,” “domain nunca importa infrastructure,” “todos os manipuladores de rota são async.” Humanos leem; agentes são instruídos a ler também.
A camada legível por máquina — o harness config. O nosso é um único arquivo JSON que classifica cada caminho no repositório em níveis de risco e anexa portões aplicáveis a cada nível. CI lê. Política de merge lê. Não é conselho — é política:
"tier3": {
"requiredChecks": [
"lint", "test", "build", "review-agent",
"harness-smoke", "manual-approval", "expanded-coverage"
],
"mergePolicy": {
"minApprovals": 2,
"requireReviewAgent": true,
"allowSelfMerge": false
}
}
(Nota de terminologia: “harness” também nomeia o runtime do agente — o scaffolding de ferramentas, habilidades e servidores MCP que um agente atua através de, como em harnext , “o harness de agente de codificação.” Neste post, o harness config é o arquivo de política do repositório que esse runtime e o CI ambos aplicam.)
Um revisor de código — humano ou agente — não pode julgar “este PR é permitido fazer merge?” sem este arquivo. Um PR de Tier-3 com a verificação review-agent pulada é uma violação de política mesmo se cada teste estiver verde. Mantenha esse exemplo em mente; ele decide o experimento.
Como ambas as camadas existem, o repositório determina um portão: nenhum agente inicia o trabalho antes de carregar este contexto — e provando que fez, através de um bloco de confirmação que revisores verificam. A questão que este post responde é simplesmente: qual é a forma mais barata correta de satisfazer esse portão?
Conheça harnext e meaninggrid
meaninggrid é o Context Engine hospedado de harnext
, o harness de agente de codificação agnóstico de provedor licenciado com MIT da QualityUnit (seis ferramentas — read, write, edit, bash, skill, mcp — npm i -g harnext). O pitch do vendedor para o Context Engine é direto: “o cérebro do seu agente.” Fontes fluem para um índice continuamente atualizado — “a grade” — e por consulta o engine “classifica e poda em contexto eficiente em tokens, conectado diretamente ao harness”: índice contínuo, classificação de relevância, dedup e cache. O número de manchete do harnext é −89% tokens por consulta em média. Essa é a afirmação do vendedor; um propósito deste experimento foi medir, com nossos próprios números em uma tarefa real, o que esse tipo de compressão realmente economiza — e o que custa.
Em nossa implementação a grade ingere a documentação em prosa do repositório; cada ingestão produz um snapshot imutável e versionado. Agentes consultam através de MCP (meaninggrid.harnext.dev/mcp) com uma única chamada context_research e recebem um digest sintetizado e citado marcado com snapshot_id, que o agente deve citar em seu bloco de confirmação — contexto auditável feito concreto.
O que o portão produz — o bloco de confirmação (exemplo; especificidades do projeto omitidas):
Carregado via: hybrid otimizado (digest de context-engine + apenas arquivo de política).
- chamada context_research #1 (convenções / layering / teste / segurança /
níveis de risco) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- chamada context_research #2 (checklist de integração de provedor LLM +
regras de cuidado extra do flow-engine) -> snapshot_id 9483af61cf8a40a2a0d790c7047fcf08
- Ler harness config (completo) do disco para padrões exatos de tier,
requiredChecks, mergePolicy, evidenceConfig.
NÃO leu CLAUDE.md ou docs/* (coberto pelo digest).
O snapshot_id é real — um revisor pode verificar exatamente qual versão das regras o agente trabalhou.
Três hipóteses
O experimento foi projetado para resolver três previsões testáveis, escritas de antemão:
H1 — Um digest é mais barato que reler. Ingira os documentos em prosa uma vez, sirva cada agente um digest sintetizado compacto, em vez de cada agente reler cada documento em cada tarefa. Se verdadeiro: custo significativamente menor por revisão, em veredictos iguais.
H2 — Paráfrase destrói política. Um digest pode carregar “Tier 3 requer revisão humana” sem perda. Não pode carregar "requireReviewAgent": true sem perda — as especificidades exatas e citáveis que um revisor precisa para afirmar uma violação morrem em resumo. Se verdadeiro: agentes apenas com digest devem perder sistematicamente violações de portão que agentes com o arquivo de política literal capturam.
H3 — Contexto mais enxuto lê mais profundo. Contexto é pago duas vezes — uma vez em dólares, uma vez em atenção: cada documento redundante na janela compete com o código sob revisão. Se verdadeiro: ler tudo (digest + todos os documentos) não deve vencer; o contexto mais enxuto e suficiente deve.
Como testamos
Vinte e dois agentes revisaram o mesmo pull request de Tier-3 em nosso monorepo de produção (uma integração de provedor LLM: 44 arquivos, +2.111 linhas, stakes reais — tabelas de cobrança, roteamento de flow-engine). Cinco braços, diferindo apenas na etapa de carregamento de contexto:
| Braço | Carregamento de contexto | n |
|---|---|---|
| meaninggrid | apenas digest de context-engine (2× context_research) | 5 |
| disk | lê 7+ documentos do disco — sem context engine | 5 |
| hybrid | digest + lê TODOS os documentos | 5 |
| opt-hybrid | digest + lê UM arquivo: o harness config | 5 |
| cold | nenhum contexto de convenção (baseline) | 2 |
Regras básicas: um commit fixado, um corpo de prompt, um modelo — Claude Opus 4.8 — todos os braços intercalados em um único lote concorrente. Agentes foram impedidos da thread de comentários do PR, para que rodadas anteriores do experimento não vazassem. Cada número vem das transcrições brutas do agente, com uso de token deduplicado por solicitação de API e precificado a preços de lista. A qualidade é pontuada contra 13 defetos reais verificados independentemente no PR, correspondidos por padrão no corpo de cada revisão e auditados manualmente para falsos positivos. Acordo de veredicto em todos os braços: 21/22 disse SOLICITAR ALTERAÇÕES.
Então o quê: a configuração mais barata também venceu em qualidade
| Braço | Custo / revisão | Achados (de 13) | Achados de portão (de 3) | Relógio de parede |
|---|---|---|---|---|
| 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 |
★ = a configuração que agora enviamos como a habilidade padrão do repositório. Relógio de parede inclui contenção compartilhada de 22 agentes executando concorrentemente.
H1 — confirmada
O braço apenas com digest revisou por $1,77 vs $2,30 para ler os documentos (−23%), e o braço vencedor com digest-mais-um-arquivo por $1,56 (−32%) — em veredictos iguais. A economia se compõe: o digest substitui uma pilha de documentos que de outra forma percorreria cada chamada de API subsequente contexto.
H2 — confirmada, decisivamente
A verificação review-agent pulada — uma violação genuína de política de merge neste PR — foi capturada por 5 de 5 agentes com o arquivo de política literal, e por 1 de 5 agentes apenas com digest. O mecanismo é exatamente o que H2 previu: para escrever esse achado, um agente deve corresponder nomes exatos de verificação de CI contra campos de configuração exatos — uma paráfrase não é evidência citável, então agentes apenas com digest se protegem e a descartam. Uma leitura direta a restaura.
H3 — confirmada
O hybrid ler-tudo carregou o máximo de contexto de qualquer braço e obteve pior (7,4/13), enquanto o braço mais enxuto e suficiente obteve o melhor (9,6/13) — e foi o melhor de todos os braços no único achado mais profundo, um bug de código morto que requer rastrear um caminho de chamada em três arquivos. Prosa redundante não adicionou informação; competiu com o código pela atenção.
Uma nota honesta: o baseline cold (8,0/13 em $1,64) mostra que a maioria dos 13 defetos são bugs de código simples que um modelo forte encontra sem nenhum contexto de convenção. O que cold não pode fazer é a metade de política do trabalho — portões, níveis, regras de merge — que é precisamente onde os braços se separam.
Curate a prosa em um digest. Leia o arquivo de política bruto. Não leia nada duas vezes.
Divulgação completa
- Modelo: cada chamada de API de cada agente foi executada em claude-opus-4-8 (Claude Opus 4.8) — verificado a partir do campo
modelde cada linha de transcrição, não presumido. Os resultados podem diferir em outros modelos; modelos menores provavelmente dependem mais de contexto curado, não menos. - Preços: custos usam preços de lista do Anthropic no momento da escrita; a cobrança real pode diferir. As comparações relativas não são afetadas.
- Tamanho da amostra: n=5 por braço (n=2 para cold), um PR, um repositório, um tipo de tarefa. O efeito de portão (5/5 vs 1/5) é acentuado; taxas por achado em outro lugar são ±1 agente. Trate como um piloto forte, não um benchmark.
- Métrica de qualidade: detecção de padrão sobre texto de revisão (citações excluídas), auditado manualmente para falsos positivos. Conta menções de defetos verificados, não eloquência geral de revisão.
- Timing: todos os 22 agentes compartilharam uma máquina e uma cota de API; números de relógio de parede incluem essa contenção.
- Corrigimos a nós mesmos duas vezes: contagens de token iniciais foram infladas 2–3× (duplicação de uso por linha em transcrições; corrigido por dedup de ID de solicitação), e uma visualização de linha do tempo anterior subestimava tempo de parede (corrigido por atribuição de intervalo completo). Ambas as correções estão incorporadas em cada número aqui.
Pronto para expandir seu negócio?
Comece seu teste gratuito hoje e veja resultados em dias.
Agora o quê: roube o loop
O que enviamos
O braço vencedor agora é a habilidade padrão check-context-first do repositório: puxe o digest do context-engine (duas chamadas), depois leia exatamente um arquivo do disco — o harness config — e emita um bloco de confirmação citando o snapshot e os portões exatos. Uma fraqueza medida, uma correção de política de uma linha, revalidada no mesmo dia. Esse loop — medir, corrigir a política de contexto, revalidar — é a parte que encorajamos você a roubar, qualquer que seja o context engine que use.
O que você pode fazer na segunda-feira
- Divida seu contexto de agente em dois: prosa (convenções, arquitetura, testes) vs política legível por máquina (portões de CI, níveis de risco, regras de merge).
- Digira a prosa; nunca digira a política. Sirva a prosa através de um context engine — meaninggrid é o nosso — e faça do arquivo de política uma leitura verbatim obrigatória em seu context gate.
- Torne o contexto auditável. Versione o contexto ingerido; exija que os agentes citem o id do snapshot em um bloco de confirmação que revisores possam realmente verificar.
- Meça antes de acreditar — incluindo em nós. Um punhado de agentes por braço em seu próprio repositório é suficiente para ver o padrão. Pontuação as revisões contra achados verificados, não vibes.
Um convite aberto
Se você executar este experimento em seu próprio repositório — mesmos braços, seu modelo, seu harness — gostaríamos genuinamente de ver seus números, especialmente se refutarem os nossos. E se sua equipe quer ajuda configurando um context gate como este, ou quer conversar sobre meaninggrid e a pilha harnext, entre em contato com o time FlowHunt ou encontre o harness de código aberto em harnext.dev . Replicações, questões e correções são bem-vindas.
