Três Vozes, Uma Lacuna de Verificação: O Harness Virou Vocabulário Cruzado

Três praticantes independentes publicaram na mesma semana, nenhum coordenou com o outro, nenhum citou o outro, e nenhum usou o mesmo vocabulário. Oskar Dudycz, arquiteto independente no Substack, chamou de “harness”. Wei Zhang e Jessie Jie Xia, ambos da Thoughtworks, chamaram de Structured-Prompt-Driven Development. Leah Tharin, escritora de produto, chamou de “direção acima de velocidade”. Disciplinas diferentes, enquadramentos diferentes, um único destino.

Cada um apontava para a mesma forma: a IA tornou a fase de Ação do trabalho barata, e a disciplina que mantinha o trabalho honesto — verificação, observação, alinhamento entre intenção e resultado — ainda não acompanhou. A lacuna ficou visível o suficiente para que três pessoas de três cantos da prática a nomeassem de forma independente em sete dias.

Nós temos chamado essa lacuna de “harness” há algum tempo. O que mudou esta semana é que o termo não é mais só nosso.

Voz Um: O Harness Como Aceleração do OODA

O texto de Oskar Dudycz, “Vibing, Harness and OODA Loop”, enquadra o problema em termos cibernéticos. O OODA Loop — Observar, Orientar, Decidir, Agir — foi o modelo de John Boyd para tomada de decisão adversarial sob pressão de tempo. O argumento de Dudycz é que a IA comprime radicalmente a fase de Agir. Código é escrito em segundos, infraestrutura é provisionada em minutos, protótipos são montados antes do almoço. As outras três fases não foram desenhadas para essa cadência. Observar, Orientar e Decidir continuam em velocidade humana. Agir se desprendeu e disparou na frente.

O harness, no enquadramento dele, é a infraestrutura mecânica que arrasta o Observar de volta para o novo tempo do Agir. Concretamente, isso significa funções de diagnóstico que consultam endpoints de saúde de serviço automaticamente, scripts automatizados de setup e teardown escritos com execa e fetch nativo, múltiplas verificações rodando em paralelo — prontidão HTTP, resolução de nome de serviço, disponibilidade de métrica — e caminhos de limpeza reprodutíveis para que execuções falhas não deixem resíduo. Inspeção de logs do Docker no momento da falha, e não como arqueologia depois.

A frase que mais marca é a descrição que ele faz de um setup de infraestrutura feito uma vez com IA: “se você tentar repetir, não vai saber como fazer sem virar Voodoo de novo”. Essa frase captura o modo de falha que o harness existe para prevenir. Sem infraestrutura de verificação, a velocidade assistida por IA produz resultados que funcionam uma vez e não conseguem ser reproduzidos. O time fica mais rápido em construir coisas que não consegue reconstruir.

Dudycz é explícito sobre o que o harness não é: “Harness não é mágica, nem disciplina nova, nem o próximo buzzword”. É disciplina de testes e automação aplicada como acelerador, não como freio. O reenquadramento é o que torna o termo útil — essas sempre foram as práticas certas; o que é novo é a consequência de pulá-las.

Voz Dois: SPDD Como Artefato de Primeira Classe

O Structured-Prompt-Driven Development foi publicado em martinfowler.com, mas é assinado por Wei Zhang e Jessie Jie Xia, ambos da Thoughtworks. A distinção importa porque o enquadramento vem de uma prática de entrega, não de um ensaio pessoal — Zhang trabalha com entrega de IA e Xia é a Global CIO da Thoughtworks. Fowler hospeda; quem fala são praticantes da Thoughtworks.

O argumento deles: prompts são artefatos de entrega de primeira classe. Versionados. Revisados. Reusados. Aprimorados. Tratados com a mesma governança que o código, não como rascunho descartável perdido no histórico de chat. O veículo para esse tratamento é o REASONS Canvas — uma estrutura de sete partes cobrindo Requisitos, Entidades, Abordagem, Estrutura, Operações, Normas e Salvaguardas. Cada parte tem nome porque cada parte é algo que o time precisa conseguir apontar quando algo der errado.

O fluxo é um conjunto de comandos slash: /spdd-analysis, /spdd-reasons-canvas, /spdd-prompt-update, /spdd-sync. O último merece pausa. O SPDD exige sincronização bidirecional entre o prompt e o código que ele produz — o documento é atualizado quando a implementação muda, e a implementação é regenerada quando o documento muda. A disciplina que eles querem impor é que “intenção e implementação não se afastem”. A divergência entre especificação e código é o modo de falha que todo sistema documentado eventualmente desenvolve; a tese do SPDD é que o loop de IA, paradoxalmente, é o que torna o alinhamento contínuo barato o suficiente para ser mantido.

As três habilidades centrais que eles identificam — pensamento abstração-primeiro, alinhamento e revisão iterativa — são reconhecidamente as habilidades de um engenheiro sênior em produto regulado. O estudo de caso, uma evolução de motor de cobrança cobrindo precificação ciente do modelo e lógica de planos múltiplos, não é o tipo de trabalho em que se entrega um protótipo e pronto. É o tipo de trabalho em que alguém precisa conseguir explicar a mudança três anos depois para um auditor.

Voz Três: Direção Quando o Proxy de Produtividade Quebra

O texto de Leah Tharin, “Direction Over Speed”, aborda o mesmo problema pelo lado de produto. A observação dela: a IA quebrou o disfarce da produtividade-falsa-por-entrega. Por duas décadas, o proxy operacional da indústria para “esse time é produtivo” foi “esse time entrega”. Protótipos hoje são baratos. Specs se escrevem sozinhos. Tickets fecham. Gráficos de velocidade sobem. O proxy perdeu o sinal — entregar parece igual quer o time esteja construindo a coisa certa, quer esteja construindo a errada.

A recomendação dela é estrutural: times menores, de quatro a cinco pessoas, com o gerente de produto mais próximo do trabalho, especialmente em features de IA. A razão é que, em features de IA, a pergunta “isso está bom” não pode ser respondida por uma métrica. Não existe equivalente de taxa de conversão para “o modelo se comportou do jeito que pretendíamos”. Alguém tem que ver a saída. Alguém tem que julgar. Quanto menor o time, mais perto o juiz fica do trabalho que está sendo julgado.

Ela não escreve sobre harness de engenharia ou artefato de prompt. Mas a tese subjacente é a mesma: os proxies antigos de qualidade pararam de funcionar quando a IA tornou a saída barata, então outra coisa precisa carregar a carga de verificação. Para ela, essa outra coisa é o ciclo de julgamento humano, mantido apertado pelo tamanho do time. Para Dudycz é diagnóstico automatizado. Para Zhang e Xia são artefatos canônicos. Mecanismos diferentes, função compensatória idêntica.

Três Vocabulários, Um Edifício

Quem leu os três textos na mesma semana — nós lemos — não consegue perder a convergência. A IA comprimiu o Agir. As outras fases do trabalho — observar, julgar, alinhar, verificar — não comprimiram junto. A lacuna que se abre quando uma fase dispara à frente das outras é a lacuna de verificação. Cada autor está propondo um mecanismo para fechá-la.

Dudycz: automatize o Observar para que ele acompanhe a velocidade do Agir. Chame isso de harness.

Zhang e Xia: codifique a intenção em artefatos que viajam com o código, para que Decidir e Agir permaneçam sincronizados. Chame isso de SPDD.

Tharin: encolha o time para que o julgamento humano consiga acompanhar a velocidade da saída. Chame isso de direção acima de velocidade.

Três vocabulários. Um destino. O destino é infraestrutura de verificação que escala com a velocidade induzida pela IA.

Nós temos escrito sobre esse destino pelo lado da engenharia. O que é o harness e por que ele difere da execução de agente. O que um agent harness contém de fato. Como o desenho do harness muda em aplicações de longa duração. Como o raciocínio estruturado vira superfície de governança. Esses textos estabelecem o termo dentro da nossa prática. O que esta semana acrescentou é confirmação independente de que o termo — ou um dos seus sinônimos — está em uso ativo por praticantes que jamais leram nosso material.

O Que Isso Significa Para Quem Compra

Quando um conceito é nomeado simultaneamente por três praticantes independentes usando três vocabulários diferentes, o conceito passou da fase de adotante inicial. Deixou de ser metáfora privada das pessoas que viram o problema primeiro. Virou modo de falha reconhecido sendo endereçado por movimentos múltiplos e convergentes.

Para quem compra, a pergunta prática muda. Já não é se o time precisa de infraestrutura de verificação para absorver a velocidade da IA. O mercado respondeu. A pergunta prática é qual vocabulário o time vai usar para descrever o que está construindo, porque a escolha do vocabulário é também a escolha do corpo de prática em que o time vai se apoiar.

Se o time pensa em termos de OODA, o enquadramento de Dudycz dá uma narrativa cibernética para por que instrumentação importa e o que instrumentar primeiro. Se o time pensa em termos de artefatos e rastreabilidade, o enquadramento da Thoughtworks dá uma narrativa de processo de entrega e um canvas para preencher. Se o time pensa em como produto e engenharia trabalham juntos, o enquadramento de Tharin dá uma razão estrutural para resistir a escalar tamanho de time como resposta a ganho de produtividade da IA.

Nós usamos “harness” porque é o termo em torno do qual nossa escrita se organizou. Mas a substância é portável. Qualquer que seja o vocabulário que cole na sua organização, o trabalho é o mesmo: reconstruir verificação na nova velocidade, ou ver a reprodutibilidade sair quietamente pela porta.

O vocabulário vai continuar se multiplicando. O destino é o mesmo.

Fontes

Vibing, Harness and OODA Loop — Oskar Dudycz, abril de 2026.
Structured-Prompt-Driven Development — Wei Zhang e Jessie Jie Xia (Thoughtworks), abril de 2026.
Direction Over Speed — Leah Tharin, abril de 2026.

A Victorino ajuda organizações de engenharia a construir o harness — infraestrutura de verificação que permite a times assistidos por IA andarem rápido sem perder reprodutibilidade: contato@victorino.com.br | www.victorino.com.br