Trocar o modelo e manter o mesmo ambiente de execução raramente produz o salto que o marketing promete. O que muda o resultado, em muitos casos, é o conjunto que envolve o modelo: ferramentas disponíveis, regras de uso, memória de sessão, planejamento, subagentes, validações e o modo como o agente lê e escreve no repositório. Esse conjunto tem nome na literatura recente: harness.
Dois trabalhos de final de setembro de 2026 colocam o harness no centro da discussão. Beyond the Model: Demystifying Harness Effects in Software Engineering Agents (arXiv, 26 set 2026) compara harnesses, modelos e benchmarks (incluindo SWE-bench Pro e tarefas em nível de repositório). A conclusão prática é que a eficácia do harness depende ao mesmo tempo da capacidade do modelo e do tipo de tarefa. Uso estruturado de ferramentas e subagentes específicos da tarefa tende a gerar ganhos mais estáveis. Compressão agressiva de contexto e subagentes genéricos, em certos cenários de geração sobre repositório inteiro, chegaram a piorar o resultado.
Outro estudo, Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents, analisa o código-fonte de onze sistemas de agentes e descreve o harness como anatomia operacional: não é “prompt bonito”, é a camada que transforma um modelo de linguagem em algo capaz de trabalhar de forma repetível sobre um codebase — com permissões, loops de ferramenta, critérios de parada e mecanismos de verificação.
Isso desloca a conversa de “qual o melhor modelo” para “qual o ambiente em que esse modelo opera”. Times que só trocam o LLM e reutilizam o mesmo harness fraco repetem o mesmo padrão de falha com custo diferente. Times que investem em ferramentas certas para a tarefa, em contexto que o agente consegue usar de fato e em regras que limitam o que pode ser alterado sem revisão, obtêm comportamento mais previsível — inclusive com modelos menos badalados.
Na prática de engenharia, o harness vira objeto de desenho. Quais ferramentas o agente pode chamar. O que entra no contexto e o que fica de fora. Quando um subagente específico é acionado e quando não. Quais validações rodam antes do diff ser oferecido ao humano. Quem define isso está fazendo engenharia de software assistida por IA de verdade; quem só escolhe o modelo na interface está delegando o resultado ao acaso do ambiente padrão do fornecedor.
O modelo importa. O ambiente em que ele corre, muitas vezes, importa mais para o que chega ao repositório. Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.
Leia o artigo mais aprofundado, com exemplos e a análise de arquitetura completa.
Autor da série de livros “Engenharia de Software Assistida por IA” (disponível na Amazon). Aprofunde-se no tema de forma estruturada — do contexto à governança de agentes — pode consultar a série "Engenharia de Software Assistida por IA" clicando na imagem abaixo:
- ✅ Cupom de 30% OFF:
LEIA30. - ✅ Disponível também no Kindle Unlimited.
Referências
- Beyond the Model: Demystifying Harness Effects in Software Engineering Agents (arXiv, 26 set 2026)
- Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents (análise de onze sistemas de agentes)
Tags
#EngenhariaDeSoftware #IA #InteligenciaArtificial #SoftwareEngineering #AI #CodingAgents #Harness #ContextEngineering #EngenhariaDeSoftwareAssistidaPorIA
Top comments (0)