SDD e Harness Engineering: Por Que Eles se Complementam (E Não se Substituem)

Martin Fowler publicou um artigo escrito por Birgitta Böckeler que está circulando em todos os grupos de desenvolvimento que acompanho: Harness Engineering for Coding Agent Users. Se você ainda não leu, vai querer ler depois deste post — o link está nas fontes ao final.

O artigo formalizou algo que muitos times já estavam fazendo de forma intuitiva: a ideia de que a confiabilidade de um agente de IA depende menos do modelo em si e mais do sistema de controle que envolve esse modelo. A fórmula que resume isso veio de Mitchell Hashimoto: Agent = Model + Harness.

O problema é que essa formulação clara, somada ao dado impressionante que LangChain melhorou seu agente de 52.8% para 66.5% no Terminal Bench 2.0 apenas mudando o harness (sem trocar o modelo), gerou uma interpretação que eu considero equivocada: a de que Harness Engineering substitui o Spec-Driven Development.

Não substitui. E este post explica por quê — com a argumentação dos dois lados, porque a discussão é genuína e merece ser tratada com seriedade.

---

O Que É Harness Engineering, De Verdade

Para a discussão ser útil, preciso ser preciso sobre o que é Harness Engineering. O conceito emergiu em campo em 2026, popularizado por relatórios do time do OpenAI Codex, Anthropic, LangChain, Thoughtworks e HumanLayer — todos convergindo para o mesmo insight.

O harness é tudo no agente, exceto o modelo. Inclui o contexto que o modelo recebe, as restrições que governam o que ele pode fazer, os mecanismos de validação que avaliam o que ele entregou, e os loops de feedback que permitem autocorreção.

Böckeler organiza os componentes do harness em duas categorias:

Guides (Controles de Feedforward): dirigem o agente antes de ele agir. Aumentam a probabilidade de que o agente acerte na primeira tentativa. Incluem:

• System prompts e instruções contextuais
• Arquivos de configuração de agente (AGENTS.md, CLAUDE.md, steering files)
• Constraints arquiteturais documentados
• Exemplos de código e padrões esperados
• Limites de escopo explícitos

Sensors (Controles de Feedback): observam depois de o agente agir e ajudam na autocorreção. Incluem:

• Linters com mensagens otimizadas para consumo do LLM
• Type checkers e validadores estruturais
• Suites de testes que o agente pode executar
• Ferramentas de análise estática que geram feedback acionável

A chave aqui é que sensors bem projetados não apenas detectam problemas — eles comunicam o problema de forma que o agente consegue corrigir. Um linter que retorna "erro na linha 42" é menos útil do que um linter que retorna "erro na linha 42: você está modificando estado compartilhado dentro de um callback assíncrono; extraia para uma variável local antes de entrar no callback."

O resultado mais citado para ilustrar o poder do harness é o experimento da LangChain: o mesmo modelo, com um harness melhor projetado, subiu do Top 30 para o Top 5 no Terminal Bench 2.0. A diferença de 52.8% para 66.5% não veio de um modelo maior ou mais caro — veio de melhores guides e sensors.

---

O Argumento do Outro Lado: "Harness Torna SDD Desnecessário"

Antes de defender meu ponto, preciso ser honesto sobre o argumento contrário, porque ele não é idiota.

A tese de quem defende que Harness Engineering substitui SDD pode ser resumida assim:

"Se o harness inclui guides que constrangem o comportamento do agente de forma eficaz, e sensors que corrigem desvios de forma contínua, você não precisa de especificações formais upfront. O agente vai convergir para o resultado certo através do mecanismo de controle, sem a fase de especificação que SDD exige."

Há evidências que suportam parcialmente essa visão. O experimento do OpenAI Codex onde um time de engenheiros construiu um produto de ~1 milhão de linhas de código sem código escrito manualmente usou principalmente harness — constraints arquiteturais, linters especializados, feedback loops automatizados — e não necessariamente especificações formais no estilo SDD para cada feature.

A versão mais sofisticada do argumento é: SDD resolve o problema de intenção com um processo manual (o dev escreve a spec). Harness resolve o mesmo problema de forma mais robusta porque os sensors detectam quando a implementação diverge da intenção e corrigem automaticamente, criando um loop de feedback mais confiável do que uma spec estática que pode estar incompleta ou desatualizada.

Esse argumento tem mérito. Vale levá-lo a sério antes de refutá-lo.

---

Por Que Não Substitui: A Análise das Camadas

Meu ponto central é este: SDD e Harness Engineering operam em camadas de abstração diferentes, e confundi-los é o mesmo erro que confundir arquitetura de sistema com infraestrutura de deployment.

Ambos são necessários. Resolvem problemas distintos. A presença de um não elimina a necessidade do outro.

SDD opera na camada de intenção. A especificação responde à pergunta: o que este componente deve fazer, dentro de quais restrições, com quais interfaces, para qual finalidade de negócio? Essa pergunta é fundamentalmente humana — requer entendimento do domínio, dos requisitos não-funcionais implícitos, das decisões de design que não estão em nenhum código.

Harness Engineering opera na camada de execução. O harness responde à pergunta: como garantir que o agente execute de forma confiável o que foi especificado? Isso inclui os mecanismos técnicos que tornam a execução do agente mais determinística, verificável e autocorretiva.

Uma spec bem escrita é, na terminologia de Böckeler, um guide — um controle de feedforward que direciona o agente antes de ele agir. Mas o harness é mais do que guides. É também sensors, loops de feedback, mecanismos de validação. SDD sem harness tem boa intenção mas execução não-confiável. Harness sem SDD tem boa infraestrutura mas intenção ambígua.

---

O Problema do Harness Sem Especificação

Vou ilustrar com um cenário concreto por que harness sem spec cria problemas específicos.

Imagine um agente de desenvolvimento com um harness excelente: linters precisos, type checkers rigorosos, testes automatizados abrangentes, constraints arquiteturais bem definidos. O harness garante que o código gerado é tecnicamente correto, segue os padrões do projeto, e passa em todos os testes existentes.

Agora o agente recebe a tarefa: "Adicione autenticação de dois fatores ao fluxo de login."

Sem especificação, o agente vai implementar 2FA de alguma forma — provavelmente uma forma tecnicamente correta, que passa nos linters e nos testes. Mas qual forma? SMS? TOTP? Biometria? Email com código? E quais são as regras: obrigatório para todos os usuários ou opcional? Com período de grace para usuários existentes? Quais são as políticas de fallback se o segundo fator falhar?

O harness não responde nenhuma dessas perguntas. Ele garante que como o agente implementar vai ser tecnicamente sólido. Mas o que implementar fica a cargo da interpretação do agente sobre a tarefa vaga — e cada interpretação razoável gera um produto diferente.

A spec resolve isso. Não porque specs são documentos burocráticos, mas porque são o artefato que externaliza as decisões de design que existem na cabeça do dev e as torna acessíveis ao agente de forma estruturada.

---

O Problema do SDD Sem Harness

O caso contrário também falha de forma específica e documentada.

SDD sem harness adequado é o cenário que gera o "loop de 3 meses" que discutimos no post sobre Vibe Coding vs SDD: você tem specs boas, o agente gera código a partir delas, mas sem sensors que verificam continuamente se a implementação mantém a coerência com as specs ao longo do tempo, o sistema vai acumulando deriva.

Uma feature nova é implementada com spec. Mas a feature anterior foi modificada — e a spec da feature nova assumia que a anterior se comportaria de certa forma. Sem um sensor que detecte essa violação de contrato, a divergência fica invisível até virar um bug em produção.

O harness, nesse contexto, é o que transforma specs estáticas em especificações vivas: a spec define o comportamento esperado, e os sensors detectam continuamente quando o comportamento real diverge.

---

A Visão de Fowler: Spec Como Guide

O próprio artigo de Fowler/Böckeler endossa implicitamente essa complementaridade ao colocar specs e arquivos de instrução de agente dentro da categoria de guides do harness.

Ou seja: na taxonomia do Harness Engineering, a spec de SDD é um componente do harness — especificamente, um guide de feedforward. SDD não é concorrente do Harness Engineering; é uma metodologia para criar guides de alta qualidade.

A discussão "harness substitui SDD" parte de uma premissa incorreta: que SDD e Harness Engineering são alternativas. Eles não são. SDD é uma das práticas que você usa para criar guides eficazes dentro de um harness bem projetado.

A Thoughtworks capturou isso com precisão: "Harness engineering com specs bem escritas é o estado da arte. Harness sem specs é infraestrutura buscando intenção. Specs sem harness é intenção sem infraestrutura."

---

Como Implementar os Dois na Prática

Com essa base conceitual, o que muda na prática?

O harness como estrutura organizadora. Em vez de tratar SDD como uma prática isolada, pense nele como a camada de guides do seu harness. Quando você escreve uma spec, você está criando um guide. Quando você configura seu CLAUDE.md ou AGENTS.md, você também está criando guides. Quando você escreve testes com mensagens de erro informativas, você está criando sensors.

Specs informam sensors. Bons sensors para código de agente não são só "o teste passou ou falhou". São validadores que verificam se a implementação respeita os critérios definidos na spec. Um validator que verifica "o componente retorna Result<T> em todos os casos de erro, como definido na spec" é mais valioso do que um teste unitário genérico.

Sensors revelam gaps de spec. Quando um sensor detecta repetidamente o mesmo tipo de desvio, isso é informação sobre a spec: ela é ambígua em algum ponto que o agente está interpretando de forma inconsistente. Esse feedback deve alimentar a melhoria da spec, não apenas a correção da implementação.

Evolução do harness ao longo do projeto. Em projetos novos, spec-heavy é mais importante porque o agente tem menos contexto. Com o projeto maduro e com bom conjunto de sensors e tests, você pode reduzir a granularidade das specs porque o harness começa a capturar muito do conhecimento do sistema. É uma evolução natural, não uma substituição.

---

Conclusão: O Stack Completo de Desenvolvimento Agêntico

A forma mais clara de resumir meu ponto: SDD e Harness Engineering são camadas de um stack, não alternativas em uma escolha.

O stack completo de desenvolvimento agêntico maduro em 2026 parece com isso:

1. Intenção (SDD): especificações que definem o que construir, com critérios verificáveis e constraints explícitos
2. Guides (parte do harness): specs, AGENTS.md, exemplos, constraints arquiteturais — feedforward controls
3. Execução (agente + modelo): geração de código dentro das restrições dos guides
4. Sensors (parte do harness): linters, type checkers, testes, validators — feedback controls que detectam e corrigem desvios
5. Revisão humana (Human in the Loop): validação nos pontos de alto risco e alta ambiguidade

Cada camada resolve um problema distinto. Remover qualquer uma cria uma falha específica e documentada. E a experiência de times que estão produzindo com alta confiança em 2026 — como os times que o OpenAI descreveu no artigo original de Harness Engineering — usa todas as camadas de forma integrada.

Quem debate "harness vs SDD" está, com todo respeito, fazendo a pergunta errada. A pergunta certa é: como implemento as duas práticas de forma que se reforcem mutuamente?

---

Fontes

• Harness Engineering for Coding Agent Users — Martin Fowler / Birgitta Böckeler
• Harness Engineering: First Thoughts — Martin Fowler
• Humans and Agents in Software Engineering Loops — Martin Fowler
• OpenAI Introduces Harness Engineering: Codex Agents Power Large-Scale Software Development — InfoQ
• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• Spec-Driven Development: Unpacking One of 2025's Key Practices — Thoughtworks
• Harness Engineering: The Missing Layer in Specs-Driven AI Development — Loiane Groner
• Spec-Driven Development Is Eating Software Engineering — Medium / Vishal Mysore
• Building AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering — arXiv