# Spec Driven chegou no limite — Harness Engineering é o próximo passo

**Channel:** Waldemar Neto - Dev Lab
**Source:** https://www.youtube.com/watch?v=dLs-Pbn8stU
**Transcript page:** https://www.withtranscript.ai/video/dLs-Pbn8stU

## Chapters

- 0:00 — Por que agentes precisam de harness
- 2:15 — Conceitos básicos de feedforward e feedback
- 5:32 — Falhas comuns que o spec não cobre
- 8:41 — Implementando harness na prática
- 12:19 — Encerramento e chamada final

## Transcript

**[0:00]:** Imagina só essa cena, dá um prompt para um agente de IA, constrói uma aplicação full stack com autenticação, dashboard e integração com Stripe. O agente sai gerando código doidão por 40 minutos, quando termina tu abre um GIF de 3.000 linhas alteradas. Metade funciona, metade não compila, tem feature duplicada, ele sobrescreveu um teste, ele deletou o teste, ele declarou tudo como pronto e tu gastou um monte de token. Isso não é um bug do modelo, os modelos de hoje são muito capazes, o problema é que ninguém ensinou ele como trabalhar. E se a gente quer escalar como indústria, além de fazer só funcionalidades com IA para fazer aplicações inteiras, a gente tem que resolver esse problema e eu vou te mostrar como as grandes empresas estão trabalhando para atacar isso.

**[0:35]:** A OpenAI acabou de gerar um milhão de linhas de código sem nenhuma linha escrita por humano e tudo funcionou. A Antropic fez agentes construindo apps inteiros em sessões que duraram dias e a diferença entre o que eles fizeram que a maioria de nós fazemos é a Harness Engineering. E nesse vídeo eu não vou só te explicar porque esse é o próximo passo necessário no desenvolvimento com o IA, como também vou te mostrar um exemplo de uma ferramenta que implementa a Harness Engineering na prática. Então, fica no vídeo que eu vou te mostrar a teoria e a prática para estar pronto para a próxima fase do desenvolvimento com o IA. Bom, primeira coisa, o que é Harness?

**[1:07]:** O modelo é a LLM, o Cloud, GPT-5, o que for... Harness é o todo o resto, as coisas que estão na volta. As instruções, a estrutura do repositório, os linters, os testes, os arquivos de progresso, os scripts de setup... É o ambiente operacional que envolve o modelo. Pensa assim, o modelo é um engenheiro, uma pessoa brilhante que acabou de ser contratado.

**[1:29]:** Ele é capaz de escrever qualquer coisa, mas se você o largar em um repositório sem readme, sem arquitetura documentada, sem CIs, sem testes, ele vai fazer bobagem. Não porque ele é burro, mas porque ele não tem contexto, ele vai fazer baseado na experiência dele e vai errar porque ele não tem o contexto daquele projeto. E o Harness é o onboard desse engenheiro, é o que transforma o modelo poderoso e um agente confiável, que é o que a gente mais precisa hoje como indústria. Esse conceito explodiu em fevereiro de 2026 com blog e posts da OpenAI, da Antropic e agora também no blog do Martin Fowler. Eles estão trazendo artigos detalhados sobre o tema que a gente pode entender para onde as coisas estão indo e já preparar o nosso ambiente para isso.

**[2:07]:** E a conclusão de todos eles é a mesma, o gargalo não é mais a inteligência do modelo, é a qualidade do ambiente onde ele opera, por isso que Harness é a chave.

**[2:15]:** Então, olhando para esse diagrama na tela, o Harness é todo o ambiente. Então, a gente tem o Feedforward, que eu vou falar mais sobre, que são os guides, os arquivos Markdown, e tem os sensors, as coisas que dão feedback para a gente. Isso é muito importante. Além disso, a gente tem memória e Bootstrap.

**[2:31]:** Essas coisas formam o conceito de Harness que as empresas estão estudando, que eu vou te mostrar aqui na prática. Mas saber o que é harness é só a superfície. O que importa é entender por que agentes falham sem ele e os tipos de falha são mais específicos do que você imagina e eu vou te mostrar agora. A Antropico documentou os tipos de falhas mais comuns de agentes rodando sem harness. São padrões previsíveis, mas antes da gente listar todos, a primeira coisa que você deve estar pensando é... Tá, mas o spec-driven não resolve isso que você está falando? Spec Driven é um tipo de Harness e ajuda bastante. É o que torna possível hoje a gente fazer funcionalidades inteiras, mas não criar sistemas inteiros. E isso é a próxima fase que a gente precisa ir e para isso a gente precisa de Harness. Bom, o primeiro problema clássico é o agente tentar implementar o app inteiro de uma vez.

**[3:18]:** A gente chama isso de One Shot Hero. Ele vai lá, estoura a janela no meio, deixa a feature pela metade porque ele alucina e a próxima sessão encontra um campo minado de coisas que não fazem sentido. Aqui, o Spec Driven ajuda, porque ele planeja quebra em tasks. Então, nessa parte já ajuda bastante. O segundo problema, tenho certeza que vários de vocês já passaram, é quando a gente olha para algo e diz, isso aqui já está pronto, que é a vitória prematura.

**[3:42]:** Ele, por estar com tanta coisa, chega num momento que ele diz, terminei isso daqui. Ele se perde num contexto muito grande. Então, ele para pela metade e deixa um monte de coisa para trás. Se você já usa a spec driven, uma spec que é o trabalho em tasks com uma lista de features definidas, isso te permite desenvolver em janelas de contexto melhor. Então, o problema 1 e 2 já estão cobertos, a spec impede o one shot e define o que o pronto significa.

**[4:07]:** Parabéns, já está metade do harness, já está te preparando para essa próxima fase. Bom, mas aí vem a coisa... Como assim eu estou na metade? O que é metade? Para entender isso, eu preciso te apresentar dois conceitos da engenharia de controle que são a base de tudo que vem depois.

**[4:21]:** Tem dois jeitos de controlar um sistema. O primeiro é o feedforward, onde você dá instruções antes da execução para aumentar a chance de dar certo. É preventivo. No nosso mundo, é a spec, o agents.md, as regras de arquitetura, as skills, tudo o que orienta a gente a escrever uma linha de código. Então, é esse lado aqui, os feedforward.

**[4:42]:** O segundo é o feedback, você observa o resultado depois da execução e corrige o que saiu errado. É essa parte aqui, dos sensores. No nosso mundo, são os linters, os testes, os type checkers, o review agent, tudo o que detecta um erro e permite autocorreção. Pensa, sei lá, no GPS do carro, o feedforward, É a rota que ele traça antes de sair. O feedback é quando ele detecta que você saiu ou errou a saída e recalcula em tempo real.

**[5:08]:** Se tivesse só a rota, você teria perdido no primeiro erro. Só com o recálculo, você sai sem direção nenhuma. Então, você precisa dos dois. É uma combinação. Por isso que a spec é o feedforward puro.

**[5:18]:** Ela diz o que fazer mas não verifica se foi feita de forma certa. Sim, eu sei que vários frameworks de Spec Driven, inclusive o nosso, o Tech Leaders Club, tem vários mecanismos, mas pensem que a gente quer escalar para fazer apps autônomas e aí tem mais algumas coisas que a gente precisa pensar.

**[5:32]:** A gente vai falar das coisas que o Spec Driven não resolve. A primeira é amnésia entre sessões. Cada nova sessão do agente começa do zero, sem memória do que veio antes.

**[5:41]:** É como uma equipe que trabalha em turnos onde ninguém faz passagem de bastão. O agente novo chega, olha o código e gasta metade dos tokens tentando entender o que aconteceu. A spec diz o que fazer, mas não o que foi feito, o que deu errado e qual o estado atual do código. Mas antes que perguntem, sim, eu sei que vários frameworks de Spec Driven estão começando a implementar memória, inclusive o nosso TechLeadsClub também tem, mas isso ainda não é um padrão e eles não estão muito avançados. Então, o que acontece?

**[6:08]:** Para a gente ter um bom progresso, a gente precisa conseguir ter progress files, ter disciplina de usar o Git, tem scripts de bootstrap que reconstruam o contexto e mecanismos que a spec não cobre. Quarto é muito interessante, a gente marca uma feature como pronta sem testar de verdade, ele roda um curl, vê um 200 e segue em frente, mas a feature não funciona end-to-end. Por quê? A maioria dos frameworks de spec-driven define o que testar, mas não força. Se você usa o TLC spec-driven, a gente garante isso, a gente enforça isso, mas também não é um padrão em todas as ferramentas.

**[6:41]:** Porque o que força não é a instrução, o que força são os sensores, coisas externas, linters, test runners... Porque o agente não deve ser quem julga, quem julga tem que ser uma ferramenta que retorna um 01, porque se deixar o agente julgar, ele vai olhar para o código e vai achar que está bom o suficiente sem rodar o teste. Então, qualquer framework de spec driven, para cobrir essa parte, tem que garantir que no final de uma tarefa os testes vão ser executados e todos os outros comandos de sensores, por exemplo, linter, o que você precisar... Não é todos que cobrem isso. Outro grande problema, talvez um dos maiores problemas, é o agente rodar somente em um processo.

**[7:19]:** Hoje, mesmo usando o Spec Driven, você tem um agente que orquestra vários sub-agents, ou seja, o julgamento acontece ali. O caminho que as coisas estão indo é ter um agente que implementa, outro agente em outra janela totalmente separado, não é um sub-agent, em outro processo, tem um processo orquestrador que inicia um para implementar e inicia outro para validar o output do primeiro agente, ou seja, são Processos separados, agentes separados com missões separadas. Por quê? Quando você dá uma missão para um agente, ele vai tentar cobri-la. Então, se você der uma missão de implementar, ele vai fazer de tudo para implementar, inclusive deletar código.

**[7:53]:** Se você der uma missão de validar, ele vai fazer de tudo para validar. Inclusive, agora, quando vazou o código do Cloud Code, o Cloud Code já está se instrumentando para ter essa orquestração acima dos agentes que vai permitir ter uma parte que implementa e outra parte que valida. E o SASE é aquele slope acumulado. O código compila, mas ele viola as regras de arquitetura, duplica a lógica, não passa testes e cada sessão piora. Pensem que se a gente quer criar um sistema todo, se a cada funcionalidade a gente perder 20% ou seja lá 5%, vamos dizer que tem muito bom spec driven, Tem um código muito bom, muito bem documentado, mas você perde 5% a cada funcionalidade.

**[8:31]:** Quando você vai fazer um sistema todo, que nem se fizer de um milhão de linhas, no final você vai ter um código horrível. Então, o Harness é para te garantir que você vai sempre manter a qualidade em cada interação.

**[8:41]:** Agora, a gente vai ver aqui na prática o meu framework de Harness que eu estou fazendo para estudar esses conceitos a fundo e entender como as ferramentas vão implementar. O que vocês estão vendo aqui é um framework de Harness chamado PBQ que eu estou desenvolvendo. Ele é baseado nos blog posts das empresas.

**[8:55]:** Como que ele é feito? Ele é criado em cima de SPAC Driven usando a TLC SPAC Driven, que é a nossa skill que eu vou deixar aqui embaixo para vocês. E ele adiciona os outros conceitos que o SPAC Driven não cobre por si só. Então, aqui eu estou fazendo uma app de todo list, a primeira coisa que eu gerei foi uma spec e ele vai fazer tudo isso, vai gerar uma spec dizendo as user stories, a task completion e tal, explicando o que tem que ser feito. Ele tem o conceito de sprints que englobam várias tasks.

**[9:21]:** Depois eu tenho um arquivo de progress, o arquivo de progress é o que eu mostrei para vocês, isso aqui é o que guarda o progresso entre sprints, entre grupos de tasks e ele marca o que foi concluído e também deixa um log do que foi feito. Agora começa a vir as partes interessantes. A primeira é os contratos. O que é um contrato? É um contrato entre o agente que desenvolve e o agente que testa.

**[9:42]:** Eles falaram muito sobre isso nos blog posts. São agentes separados com missões diferentes. Então, no momento de planejamento, quando um sprint vai começar, o agente que vai desenvolver cria uma lista de coisas que ele vai fazer. O agente que vai avaliar Ele olha para essa lista e diz se essa lista está batendo com a spec e depois, quando for testar, ele vai testar um a um. Por que é importante ter essa lista e ser agentes separados?

**[10:06]:** Porque o agente que testa vai bater um a um e não deixar escapar nada. E isso também é importante, porque se o agente que testa não tivesse uma lista concordada com o agente que vai implementar, ele ia começar a sugerir outras coisas não relacionadas e o agente ia entrar em um loop infinito de fazer coisas. Então, essa concordância é muito importante. Se eu der um resume aqui no meu que estava rodando, vocês vão ver o estado que ele está. Eles concordaram num contrato e está sendo construído agora.

**[10:33]:** Depois dele construir, vai vir outro agente que vai testar, vai pegar o contrato e vai ver o que precisa ser testado e passar pela lista e dizer se passou ou não. Se não passou, ele dá o output que não passou, o orquestrador inicia o passo de construção de novo para corrigir o que foi feito. Dessa maneira, ele vai se autocorrigindo até chegar na versão final. Bom, ele terminou de construir e fez uma validação básica e agora está no período de QA. E a gente vai ver o que ele vai avaliar, ele vai dar o output aqui dentro de evaluation, se passou ou não.

**[11:02]:** Se não passou, ele vai mandar de volta para ser arrumado até que passe. Então, é um novo agente. Aí a pergunta que vem é, vai gastar mais tokens? Certamente. Assim, não tem como a gente fugir de gastar mais tokens.

**[11:13]:** É que nem CodeReview, Cunha, todo esse tipo de coisa. Aí é uma conversa separada. Enquanto ele está rodando, um framework legal para vocês darem uma olhada que está começando a implementar isso é o Get Done. Esse framework aqui para o cloud está começando a implementar isso, ele usa um orquestrador também, mas fazendo os testes iniciais ele ainda não está muito estável, mas sugiro muito dar uma olhada para testar e acompanhar essa nova tendência. A gente provavelmente na Teclids Club vai lançar também um framework nosso para implementar a Harness, tipo esse meu aqui.

**[11:38]:** Bom, QA passou, R$0,51 para fazer toda a implementação e aqui tem a Evaluation. Aqui a gente consegue debugar tudo que foi avaliado no período de Evaluation. E ele dá um Score e diz qual era o mínimo para passar de cada uma delas. Essa Evaluation, galera, pode ser o quê? Teste de unidade, teste de integração, Playwright, o que vocês quiserem.

**[11:58]:** Isso que é a ideia do Harness, ser uma coisa dinâmica. Então, pensem que esse é o fundamento de Harness Engineering, ter um agente que implementa, outro que valida, você usar toda a documentação e o contexto para garantir que a implementação vai do jeito certo e você ter esses sinais guardrails que rodam do outro lado para garantir que tudo está passando e não deixa só na mão da gente para fazer.

**[12:19]:** Comentem aqui se você já tinha visto sobre Harness Engineering, se vocês estão começando a aplicar nos projetos de vocês, se vocês já usam o Spec Driven, também tem um vídeo meu falando tudo sobre o Spec Driven, comenta aqui e vejo vocês mais tarde.