[AI]: Harness no Desenvolvimento com AI: Como Implementar Guardrails, Evals e Claude Code Passo a Passo · andersonlimadev

O termo harness saiu do nicho de pesquisa e entrou de vez no vocabulário de quem constrói produto com modelos grandes.

Isso não aconteceu por acaso.

Em 2025, muita gente tratava o modelo como o produto. Em 2026, a ficha começou a cair: o modelo importa, claro, mas o resultado real depende muito da camada operacional em volta dele. É essa camada que define:

que ferramentas o agente vê;
que contexto ele carrega;
o que ele pode fazer sem aprovação;
o que precisa de confirmação;
o que é auditável;
o que vira memória;
o que é descartado;
e como você mede se o sistema está realmente melhorando.

Essa camada é o harness.

No artigo oficial "Harnessing Claude’s intelligence", publicado pela Anthropic em 2 de abril de 2026, a empresa coloca isso de forma muito elegante: agent harnesses encode assumptions about what Claude can’t do on its own. Em português claro:

um harness é a forma como você empacota as suas suposições sobre o que o modelo precisa de ajuda para fazer.

E aí mora o problema mais interessante.

Quando o modelo melhora, parte dessas suposições envelhece. O que fazia sentido com uma versão anterior do modelo pode virar peso morto com a versão atual. Você acaba mantendo filtros, resets, prompts inchados, ferramentas hiper-especializadas e fluxos de aprovação que já não aumentam qualidade na mesma proporção em que aumentam latência, custo e atrito.

É por isso que esse tema ficou tão importante.

Este artigo vai em quatro direções ao mesmo tempo:

explicar o que é um agent harness de verdade;
mostrar por que ele virou um dos conceitos centrais do desenvolvimento com AI;
explicar por que essa abordagem pode ser uma alternativa melhor do que um SDD rígido em muitos cenários;
e mostrar um caminho prático, com exemplos em TypeScript, para implementar guardrails, evals e um fluxo inspirado em Claude Code.

Vou assumir aqui que SDD significa Spec-Driven Development, que é o sentido mais comum dessa sigla no contexto atual de AI-assisted development. Se você usa a sigla em outro sentido na sua equipe, adapte essa comparação.

A tese do texto é simples:

em times que trabalham com modelos capazes, o diferencial não está em escrever uma spec cada vez mais longa; está em construir um harness que deixe o modelo forte onde ele já é forte, restrinja o que precisa ser restrito e meça continuamente o que realmente funciona.

Esse é o ponto.

Artigo completo no meu blog, disponível neste link

O que é um harness no desenvolvimento com AI

Se você quiser a definição mais prática possível, use esta:

um harness é a camada de orquestração, contexto, ferramentas, memória, segurança e avaliação que fica em volta do modelo.

O modelo gera texto, código, tool calls e decisões. O harness define o ambiente em que isso acontece.

Na prática, um harness pode incluir:

system prompt;
ferramentas declarativas;
sandbox de execução;
políticas de aprovação;
memória e arquivos persistentes;
contexto carregado sob demanda;
subagentes;
logs e traces;
cache;
evals;
critérios de parada;
UX de interação.

Isso significa que Claude Code não é só um cliente bonito para Claude. Ele é um exemplo muito concreto de agent harness maduro.

Ele combina:

ferramentas amplas como shell e editor;
CLAUDE.md como memória hierárquica;
subagentes;
modos de permissão;
contexto progressivo;
verificação via comandos reais;
e uma interface que deixa o modelo agir sem perder completamente os limites.

Ou seja, quando você usa Claude Code, você já está usando um harness.

O que este artigo propõe é aprender com esse design para construir fluxos melhores nos seus próprios produtos e times.

Por que harness virou um tema central em 2026

O artigo da Anthropic traz três padrões principais:

use o que Claude já sabe;
pergunte "o que eu posso parar de fazer?";
defina os limites com cuidado.

Esses três pontos são muito mais profundos do que parecem.

1. Use o que o modelo já sabe

A Anthropic argumenta que vale a pena construir aplicações usando ferramentas que Claude entende bem. O exemplo central é excelente: bash e um editor de texto já foram suficientes para resultados de ponta em benchmarks como SWE-bench Verified, e o próprio Claude Code se apoia nessa base.

O insight aqui é poderoso:

quanto mais você tenta esconder a complexidade do mundo atrás de abstrações artificiais demais, mais corre o risco de engessar o agente.

Ferramentas gerais, quando o modelo as domina bem, envelhecem melhor.

2. Pergunte o que você pode parar de fazer

Esse talvez seja o ponto mais importante de todo o artigo.

Harnesses acumulam decisões de projeto:

sempre passar todo output de ferramenta de volta pelo modelo;
sempre pré-carregar instruções no prompt;
sempre resumir contexto de um jeito específico;
sempre criar uma ferramenta dedicada para cada ação;
sempre exigir intervenção humana em cada etapa.

O problema é que parte dessas decisões nasceu para compensar limitações antigas do modelo. Quando o modelo melhora, você precisa reavaliar quais compensações ainda fazem sentido.

3. Defina limites com cuidado

Nem tudo deve ser "bash livre".

A Anthropic também mostra o outro lado: em ações com impacto real, ferramentas tipadas e declarativas podem ser superiores por motivos de:

segurança;
UX;
observabilidade;
auditoria;
reversibilidade.

É aqui que guardrails entram com força.

O que Claude Code ensina sobre agent harnesses

Se você observar Claude Code como produto, ele é praticamente uma aula de design de harness.

Ele parte de uma hipótese simples:

dar ao modelo ferramentas gerais e úteis;
deixar o próprio modelo decidir quando ler mais contexto;
dar caminhos para persistir ou resumir contexto;
permitir isolamento com subagentes;
e colocar segurança e permissão como uma camada operacional, não como um sermão no prompt.

Isso é muito importante.

Muita gente ainda tenta resolver quase tudo com:

prompt gigante;
checklist no system prompt;
e medo operacional.

Só que prompt não substitui ambiente.

Claude Code mostra outra direção. Em vez de tentar forçar o modelo a "ser bonzinho", ele combina:

ferramentas;
memória;
contexto;
permissões;
e verificações.

Essa combinação é o harness.

Por que um harness pode ser uma alternativa ao SDD

Aqui vale nuance.

Eu não estou argumentando que Spec-Driven Development morreu ou ficou inútil. Em vários cenários, SDD continua excelente, especialmente quando você tem:

requisitos regulatórios fortes;
times grandes com handoffs formais;
contratos de integração sensíveis;
necessidade alta de previsibilidade documental;
mudanças caras de reverter.

Mas existe um limite muito claro para SDD quando o assunto é desenvolvimento com agentes.

O problema do SDD rígido

Num fluxo de SDD rígido, você frequentemente assume que a melhor forma de controlar o sistema é:

especificar tudo antes;
reduzir variação durante execução;
usar a spec como fonte principal de verdade;
medir aderência à spec.

Isso funciona quando:

o espaço de solução é relativamente estável;
a implementação é mais previsível;
o executor não muda de capacidade toda semana.

Só que modelos mudam rápido.

E mais: a própria maneira como um agente bom resolve o problema pode melhorar entre uma versão e outra. Então um harness centrado em observação, limites e avaliação costuma ser mais adaptativo do que um fluxo excessivamente centrado em uma spec fixa.

Onde o harness ganha

Um bom harness ganha quando o trabalho depende de:

autonomia controlada;
exploração do ambiente;
capacidade do modelo de escolher a próxima ação;
recomposição dinâmica de contexto;
e melhoria contínua baseada em evals.

Nesse tipo de cenário, a pergunta mais valiosa deixa de ser:

"a implementação seguiu a spec?"

e passa a ser:

"o harness está produzindo resultados confiáveis, auditáveis e melhores ao longo do tempo?"

A formulação mais honesta

Então a melhor forma de dizer isso é:

um harness não substitui toda forma de SDD, mas é uma alternativa mais adaptativa ao SDD rígido em fluxos agentic, especialmente quando a capacidade do modelo evolui rápido e o ambiente importa tanto quanto a especificação inicial.

Artigo completo no meu blog, disponível neste link