Better Harness analisa o processo ao redor do agente de IA — não só o código que ele gera

Em vez de avaliar apenas se um agente de IA escreveu um trecho de código plausível, o Better Harness, projeto open source do Qoder, olha para todo o processo que cerca esse agente. A proposta é identificar falhas no fluxo de trabalho — instruções pouco claras, validações desconectadas, permissões mal definidas ou ausência de aprendizado entre tarefas — e transformá-las em correções pequenas, priorizadas e verificáveis em uma nova execução. 124

O Qoder anunciou a abertura do projeto no GitHub em 28 de julho de 2026, segundo reportagens da época. 5

A ideia central: avaliar o ambiente, não apenas a resposta do modelo

Um agente de programação não atua isoladamente. Ele trabalha dentro de um conjunto de instruções do repositório, especificações, ferramentas, permissões, scripts, testes, exigências de revisão, checagens de entrega e intervenções humanas. O Qoder chama esse conjunto de harness — algo como a estrutura operacional que orienta e controla o trabalho do agente. 2

Na documentação, esse ambiente pode incluir instruções do repositório, regras, skills, hooks, plugins, conectores, scripts, comandos de teste, verificações de lançamento e etapas de revisão humana. 2

A distinção é importante: mesmo um modelo competente pode falhar com frequência se o processo à sua volta for vago ou pouco instrumentado. Um projeto pode ter testes automatizados, mas não deixar claro em que momento o agente deve executá-los. Pode haver um arquivo de regras que o agente não consulta. Ou podem faltar mecanismos duráveis para registrar o que foi aprendido depois de uma tarefa problemática. O Better Harness procura essas fragilidades operacionais, em vez de assumir que a mera presença de uma configuração prova que o processo funciona. 145

As três camadas do Better Harness

O projeto é apresentado como uma estrutura de três camadas que conecta práticas de engenharia, um modelo de avaliação e uma implementação utilizável em projetos reais. 5

1. Práticas de Harness Engineering

A primeira camada trata dos mecanismos práticos que moldam o trabalho do agente: padrões de sessão e CLI, observabilidade, regras, skills, configuração de MCP, memória, hooks e automação. 5

Na prática, ela leva a perguntas como:

• O agente recebe objetivos, limites e contexto do repositório de forma clara?
• Seus caminhos de execução e permissões são controlados adequadamente?
• Testes, checagens e revisões estão conectados às mudanças que ele faz?
• Lições úteis viram ativos mantidos pelo projeto ou desaparecem ao fim da sessão?

A análise começa pelo mapeamento do harness atual: objetivos, contexto, pontos de entrada para execução, ciclos de feedback, mecanismos de entrega e captura de aprendizado. 1

2. Avaliação do Agent Work Loop

A segunda camada converte essas práticas em uma avaliação de cinco dimensões interligadas: entendimento da tarefa, execução controlada, validação das mudanças, entrega confiável e captura de aprendizado. 14

Com isso, a pergunta deixa de ser “o agente gerou um código que parece correto?” e passa a ser: o fluxo ponta a ponta consegue produzir repetidamente mudanças compreensíveis, controladas, validadas, entregáveis e informadas por trabalhos anteriores?

O modelo busca pontos de ruptura nesse ciclo, como um mecanismo ausente, uma integração desconectada, uma etapa que nunca foi executada de fato ou evidência insuficiente do resultado. 1

3. Implementação executável

A terceira camada transforma as práticas e o modelo de avaliação em algo que pode rodar em projetos reais, e não apenas em documentação. O Better Harness opera por meio de um agente de programação, coleta evidências do projeto e, quando houver suporte, de sessões reais; depois, produz próximos passos priorizados que podem ser verificados. 4

Os materiais atuais do projeto mencionam suporte a dez adaptadores de ambiente. Na cobertura de lançamento, Claude Code, Codex, Qoder e Cursor foram citados entre os ambientes compatíveis. 56

Como essa cobertura pode mudar, integrações com um ambiente específico devem ser confirmadas na documentação atual dos adaptadores. As fontes fornecidas, em particular, não comprovam suporte ao OpenClaw.

Como o Better Harness coleta evidências

Um ponto central da abordagem é separar a coleta de evidências da avaliação final. Segundo o Qoder, o fluxo principal reúne dados brutos e os encaminha a três subagentes independentes, com acesso somente de leitura, antes da consolidação dos resultados. 1

As três perspectivas são:

• Project Harness: fundações de engenharia do repositório, como instruções, scripts, checagens e controles de entrega;
• Agent Customization: regras, skills, hooks e outras configurações específicas do agente;
• Session Evidence: registros do que o agente realmente fez em tarefas reais, quando esses dados estão disponíveis.

Essa divisão ajuda a separar o processo pretendido do processo observado. As evidências de projeto e configuração podem mostrar que uma capacidade existe; os registros de sessão ajudam a indicar se ela foi usada de maneira adequada em uma tarefa real. 14

Ter uma capacidade não é o mesmo que ela funcionar

O princípio mais útil do framework é simples: a existência de um artefato não comprova sua eficácia.

Imagine um repositório com uma suíte de testes automatizados. A presença dela mostra uma capacidade potencial. Mas não prova, por si só, que o agente executou os testes relevantes depois de alterar o código, interpretou o resultado corretamente ou usou esse retorno para evitar uma entrega defeituosa. A mesma lógica se aplica a regras, hooks, skills e etapas de aprovação. 15

Por isso, os relatórios do Better Harness procuram manter explícita a cadeia de evidências. Lacunas sustentadas pelos dados se tornam achados priorizados, com impacto, resultado esperado, reparo delimitado e critérios de aceitação. O que não tiver evidência suficiente permanece visível, sem ser convertido silenciosamente em uma pontuação confiante. 46

Para uma equipe, um achado útil deve permitir verificar:

1. O que foi observado no projeto, na configuração ou no registro de sessão;
2. Por que isso importa para o ciclo de entrega;
3. Qual correção específica é proposta, como uma regra, skill, hook, script, automação ou aprovação humana;
4. Como conferir o resultado após a implementação.

O ciclo de melhoria: inspecionar, corrigir e medir de novo

O Better Harness não é apresentado como uma auditoria pontual. Seu fluxo é iterativo:

1. Mapear o harness atual;
2. Identificar pontos de ruptura e lacunas de evidência;
3. Criar uma tarefa de correção delimitada para um achado sustentado;
4. Validar a correção com critérios de aceitação definidos;
5. Rodar a revisão novamente para inspecionar as evidências atualizadas. 14

É daí que vem a proposta de melhoria contínua. A ferramenta pode mostrar que o fluxo mudou e se há novas evidências para sustentar uma avaliação mais forte. Isso não demonstra, por si só, que uma correção causou melhor desempenho do agente em todos os projetos ou ambientes. Os materiais do Qoder destacam as evidências observadas e suas limitações, em vez de tratar mudanças de pontuação como prova de causalidade. 46

O que significa a revisão inicial de 30 projetos

Reportagens sobre o lançamento afirmaram que o framework foi usado inicialmente em 30 projetos reais no GitHub. 5 Esse resultado deve ser lido como uma aplicação exploratória da estrutura, e não como demonstração controlada de que o Better Harness melhora todos os agentes ou repositórios.

A documentação primária disponível sustenta o modelo de evidências, a estrutura dos achados e o fluxo iterativo de correção. Porém, as fontes fornecidas não trazem detalhes primários suficientes para avaliar de forma independente a seleção dos 30 projetos, o protocolo de pontuação ou resultados agregados. Essa ressalva é relevante ao comparar o Better Harness com benchmarks formais ou ao fazer alegações amplas de desempenho. 14

Uma tentativa de tornar a engenharia de agentes mais mensurável

O argumento mais amplo do Qoder é que a Harness Engineering pode se tornar uma infraestrutura de qualidade para o desenvolvimento de software assistido por IA: com vocabulário comum, controles de fluxo, evidências observáveis, dimensões comparáveis de entrega e ciclos repetíveis de melhoria. 12

O Better Harness é a versão prática dessa proposta. Ele oferece às equipes uma forma de inspecionar as condições em torno do trabalho de agentes em ambientes compatíveis, discutir evidências em vez de impressões e testar se uma mudança no processo se sustenta em execuções posteriores. Seu valor não está em prometer que toda correção melhorará o resultado, mas em tornar os fluxos de agentes mais inspecionáveis, revisáveis e refutáveis. 46