O salto que importa
O problema de usar agentes de IA para desenvolver não é “o modelo da semana”. Modelos mudam rápido. A pergunta difícil é: como transformar uma intenção humana em software confiável sem perder controle, qualidade e responsabilidade no caminho.
Vibe coding, a prática de construir pela conversa com o modelo, mostrou que IA consegue gerar muito código a partir de linguagem natural. Isso é poderoso para protótipos. Mas, em ambiente corporativo, entregar software não termina quando o código aparece. A entrega também envolve alinhar escopo, preservar arquitetura, proteger dados, validar comportamento, revisar mudanças, auditar decisões e manter o sistema saudável depois do deploy.
É aqui que entram duas ideias que precisam andar juntas:
- SDD, ou Spec-Driven Development: escrever e evoluir especificações que funcionam como um contrato.
- Harness Design: as ferramentas em volta do agente, para que ele tenha contexto, limites e validação.
Separadas, essas ideias ajudam. Juntas, elas mudam o padrão da entrega.
O que é SDD
SDD significa Spec-Driven Development, desenvolvimento guiado por especificação.
Neste contexto, uma spec, ou especificação, é um artefato vivo, versionado e revisável que responde:
- qual problema estamos resolvendo;
- para quem isso importa;
- o que está dentro e fora do escopo;
- quais comportamentos precisam existir;
- quais restrições técnicas, legais ou de produto precisam ser respeitadas;
- quais critérios provam que a entrega está correta;
- quais riscos precisam de revisão humana.
A mudança é simples: o agente não implementa “o prompt”, ele implementa um plano sólido, revisável e verificável.
O que é Harness Design
Harness Design é o ambiente do agente de código.
Se SDD responde “o que precisa ser verdade?”, o harness responde “como criamos um sistema onde o agente consegue executar, validar e melhorar sem depender de sorte ou contexto perdido na conversa?”.
Modelo não é agente
Um modelo responde. Um agente tenta concluir uma tarefa usando ferramentas em ciclo: ele lê contexto, toma uma ação, observa o resultado e decide o próximo passo.
O harness é o que torna esse ciclo útil no trabalho real. Ele diz ao agente quais regras respeitar, quais ferramentas usar, onde buscar contexto, quando pedir aprovação e como provar que terminou.
agente = modelo + harness
O que entra em um harness?
Pense no harness como a infraestrutura de trabalho do agente. Não é uma ferramenta única. É o conjunto que permite sair da conversa e chegar numa entrega validável.
- Instruções: arquivos como
AGENTS.md, rules e skills que carregam comandos, padrões e combinados do projeto. - Contexto: specs, decisões técnicas, arquitetura, docs de produto e histórico suficiente para o agente não trabalhar no escuro.
- Ferramentas: terminal, Git, navegador, GitHub, logs, MCP servers e outras integrações que deixam o agente agir no ambiente certo.
- Limites: sandbox, permissões, aprovações humanas e bloqueios para ações destrutivas ou sensíveis.
- Validação: lint, testes, typecheck, build, revisão de diff e checklists que criam pressão contra entrega quebrada.
- Observabilidade: UI, logs, métricas, traces, screenshots e checks reproduzíveis que o agente (e o humano) conseguem ler para entender o que aconteceu.
- Aprendizado: cada falha recorrente vira uma regra, teste, hook, doc ou skill. O harness melhora porque o time aprendeu.
O ponto não é criar uma prisão para o agente. É criar trilhos. Bons trilhos não impedem movimento; eles tornam o movimento previsível, revisável e seguro.