Harness engineering, desenvolvimento orientado por especificações (SDD) e vibe-coding descrevem partes diferentes do trabalho com agentes de programação. O SDD registra o que construir e como reconhecer o resultado esperado; o harness prepara o ambiente, as ferramentas e os limites de atuação do agente; o vibe-coding favorece a exploração rápida por meio de prompts e iteração. Podem coexistir no mesmo projeto, desde que decisões importantes e verificações não fiquem apenas implícitas numa conversa.
O que significa cada abordagem
Harness engineering: preparar o sistema de trabalho do agente
Harness engineering é o trabalho de projetar o ambiente em que um agente de IA executa tarefas de software: ferramentas, contexto, estrutura, restrições e formas de observar o que ele fez. Não é sinônimo de escrever prompts melhores nem o nome de um padrão universal.
Em seu relato de engenharia publicado em fevereiro de 2026, a OpenAI descreveu como um ambiente inicialmente pouco especificado limitava o progresso de agentes, por não oferecer ferramentas, abstrações e estrutura adequadas. A frase da equipe, “Humans steer. Agents execute.”, resume a divisão de trabalho que o artigo propõe, mas não é uma citação atribuída a uma pessoa específica. OpenAI: Harness engineering.
SDD: manter a intenção explícita e consultável
Spec-driven development, ou desenvolvimento orientado por especificações, coloca uma especificação escrita no centro do fluxo. Ela pode registrar requisitos, restrições, guardrails, critérios de aceitação e casos de borda, servindo de contexto compartilhado para orientar implementação, testes e artefatos de apoio. A especificação deve continuar versionada e consultável durante a vida do sistema, em vez de ser um documento inicial abandonado depois que o código começa.
Recommended Free Tools
#1 Best Overall
A Microsoft descreve uma abordagem spec-first para engenharia com IA; um handbook comunitário de SDD também trata a especificação mantida como artefato principal. São descrições de práticas, não prova de que exista uma única definição formal adotada por todo o setor. Microsoft: Spec-Driven Development; SDD handbook: What is Spec-Driven Development.
Vibe-coding: explorar por prompts e iteração
Vibe-coding é uma forma mais informal de começar com instruções em linguagem natural e ajustar o resultado em ciclos rápidos, sem necessariamente manter uma especificação estruturada como registro persistente da intenção. Na prática, é melhor entendê-lo como um ponto de um espectro: uma pessoa pode explorar livremente no início e formalizar os requisitos quando a mudança passa a exigir revisão, repetibilidade ou manutenção por uma equipe.
Rank #2
Essa distinção não é uma taxonomia consensual. A IBM observa que dívida técnica já existia antes do vibe-coding, embora gerar grandes quantidades de código sem compreendê-lo ou validá-lo possa acelerá-la. IBM: What is Spec-Driven Development?; Florent Clairambault: What Is Spec-Driven Development?.
Como as três peças se encaixam
Uma maneira prática de separar os papéis é perguntar o que deve ser construído, onde o agente vai trabalhar e que evidência demonstrará que o trabalho ficou correto.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteRank #3
| Pergunta | Parte do fluxo | O que ela resolve |
|---|---|---|
| O que queremos? | Especificação (SDD) | Registra intenção, restrições e critérios de aceitação. |
| Onde e com que regras o agente trabalha? | Harness engineering | Organiza ambiente, contexto, ferramentas e permissões. |
| Como sabemos que funcionou? | Verificação | Produz evidências independentes, como testes e inspeções, sobre o comportamento implementado. |
O vibe-coding pode ajudar a descobrir o que se quer durante a exploração inicial. Quando uma decisão precisa sobreviver à conversa e orientar trabalho futuro, registre-a na especificação; em seguida, use um ambiente preparado e verificações adequadas para executar e avaliar a mudança. Essa é uma forma útil de combinar as práticas, não uma receita universal.
O Harness Protocol ilustra uma implementação possível: propõe um arquivo YAML para descrever plugins, ferramentas, ambiente, comportamento e permissões. Trata-se de um projeto específico, não de um padrão geral seguido por todos os agentes. Harness Protocol: Overview.
O que uma especificação não garante
Escrever a intenção ajuda a torná-la rastreável, mas não prova que ela esteja correta nem que o código a cumpra. O handbook de SDD distingue a especificação da evidência de verificação e ressalta que a afirmação do próprio agente de que um critério foi satisfeito não é prova independente. Em caso de divergência durante um incidente, é o código que determina o comportamento em execução, mesmo que o documento diga outra coisa.
- Escreva critérios que possam ser verificados, em vez de depender de expressões vagas como “deve funcionar bem”.
- Execute testes ou outras verificações independentes; não trate uma resposta confiante do agente como evidência.
- Investigue divergências entre especificação, implementação e comportamento observado, e atualize o artefato apropriado.
SDD handbook: What is Spec-Driven Development.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Como escolher o nível de processo
Não há uma pontuação universal que determine quando usar cada prática. A decisão deve considerar o risco, o escopo, a reversibilidade da mudança e as necessidades de manutenção. Use estas perguntas para comparar opções reais de fluxo:
Best Value
- Persistência da intenção: requisitos e decisões importantes estão somente no histórico de prompts ou num artefato versionado?
- Ligação entre intenção e entrega: é possível relacionar critérios de aceitação à implementação e aos testes?
- Ambiente do agente: ferramentas, contexto, permissões e limites são suficientes e compreensíveis?
- Qualidade da verificação: existe evidência independente de que os critérios foram atendidos?
- Custo de processo e manutenção: o nível de especificação e governança é proporcional ao risco e à longevidade da mudança?
Para uma exploração pequena e reversível, uma conversa iterativa pode ser suficiente como ponto de partida. Para mudanças que precisam ser repetíveis, revisáveis ou mantidas por uma equipe, explicitar a intenção e os critérios reduz a dependência de contexto perdido. Se o agente não dispõe de ferramentas ou de um ambiente adequado, elaborar uma especificação por si só não corrige essa limitação.
O que os números publicados demonstram — e o que não demonstram
No artigo de fevereiro de 2026, a OpenAI reportou cerca de um milhão de linhas de código, aproximadamente 1.500 pull requests mesclados e uma média de 3,5 PRs por engenheiro por dia em seu próprio projeto e equipe. Esses números descrevem aquele relato interno; não são um estudo controlado nem uma previsão de produtividade para outras organizações. OpenAI: Harness engineering.
As fontes citadas aqui não estabelecem, por comparação independente, ganhos gerais de produtividade ou qualidade causados por SDD ou harness engineering. A Microsoft formula o princípio “AI has made software delivery faster, but speed alone does not guarantee better outcomes.” Essa é uma declaração do artigo da Microsoft, atribuído a Apoorv Gupta, e não o resultado de um estudo independente. Microsoft: Spec-Driven Development.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
