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: 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.
Bons trilhos dão espaço para o agente se mover e tornam esse movimento previsível, revisável e seguro.
Onde isso quebra
Harness mal feito vira teatro. Regras no README que ninguém segue. Skill que ninguém invoca. Build que passa mas ninguém olha o diff. Contexto infinito jogado no prompt sem curadoria.
SDD mal feito vira documento morto: spec que ninguém atualiza, critérios que ninguém testa, escopo que muda só no chat.
Maturidade aparece quando uma falha leva o time a melhorar o sistema (regra, teste, limite, doc) em vez de só repetir o prompt com mais ênfase.
O papel do engenheiro
Com agentes no fluxo, o trabalho se desloca. Menos tempo digitando boilerplate. Mais tempo em especificação, revisão, governança e qualidade do harness.
Perguntas úteis para um harness explícito:
- O agente sabe o objetivo e o fora de escopo desta tarefa?
- Quais arquivos e ferramentas ele pode tocar sem aprovação?
- O que prova que terminou (teste, build, checklist)?
- O que nunca pode fazer sozinho (segredos, produção, force push)?
- Onde a falha de hoje vira regra de amanhã?
Trabalhar de forma AI-native exige ser dono do sistema que produz o diff, não aceitar mudanças geradas mais rápido.
Na prática (PM, QA, liderança)
- PM: a spec vira o contrato compartilhado. Menos “cadê a feature?”, mais “este critério de aceite está coberto?”.
- QA: entra antes da implementação. Critérios e riscos viram checks, não só bug no fim.
- Liderança: o risco deixa de ser só alucinação do modelo. Vira ausência de rastro: decisões só no chat, sem plano, sem validação, sem revisão no merge.
Se quiser a versão de campo (o que muda na terça-feira), leia o ensaio Harness no dia a dia.
Takeaway
Modelos mudam. Categorias de ferramenta mudam. O padrão que fica é mais simples: intenção clara (SDD), ambiente com trilhos (harness), validação explícita, humano responsável no merge.
Prompt solto explora. Entrega repetível pede sistema.