Harness Engineering Pt. I (e o primeiro post do blog!)
Oi, pessoal! Sou o Flávio e este é o meu primeiro post no blog! Por aqui, vou compartilhar minha experiência profissional — coisas que aprendi ao longo desses 10 anos de carreira, novidades em tecnologia, além de projetos nos quais posso estar envolvido. Aqui você vai encontrar conteúdo sobre Engenharia de Software, Design de Sistemas, DevOps, AI/LLM, e tudo o que de mais maluco estiver acontecendo no nosso setor! Espero muito que você curta e consiga aprender algo por aqui!
Mais um post sobre Harness Engineering
Sim, eu sei, esse assunto tá em todo lugar agora. A essa altura, você já sabe o que é Harness Engineering (HE), o que ele resolve e como construir seus próprios componentes de harness. Vou deixar o post do Addy Osmani como uma boa visão geral e referência útil caso você seja novo no tema. Meu objetivo nessa série de posts é mergulhar fundo em como tenho usado HE no meu dia-a-dia como Engenheiro de Software.
O ciclo vicioso da programação assistida por IA
Todo mundo diz que, desde a IA generativa, estamos nos tornando engenheiros 5x, 10x, 100x mais produtivos. Para realmente chegar lá, não basta abrir o agente de código de sua preferência, começar a pedir pra “criar uma nova página em React pra gerenciar o estoque de recursos da empresa. Adicionar os endpoints necessários no backend também. Sem erros.” e torcer pra funcionar. Ok, sejamos honestos: provavelmente vai funcionar — você vai ver centenas de linhas de código sendo geradas no seu terminal/IDE, o agente vai até executar o docker compose pra subir a aplicação, e voilà, aí está o que você pediu, materializado na sua frente.
De forma geral, você chega lá. Mesmo quando não rola na primeira tentativa, se você tiver paciência suficiente, vai conseguir conduzir o agente até entregar o que esperava. E você vai se sentir produtivo: uma tarefa que parecia ser de 3 dias foi entregue em uma tarde. É aí que as coisas começam a desandar. Depois de revisar a saída do agente (ou pior, quando um colega revisou seu PR em detalhe), você vai perceber que, no melhor cenário, você tem um protótipo, não uma solução final. Testes estão faltando, a tipagem não está devidamente aplicada, o layering da sua aplicação foi completamente ignorado, código repetido por todo lado, e por aí vai.
Mais uma vez, você vai pensar “ok, ainda posso usar o LLM pra fechar essas lacunas, e vou entregar muito mais rápido do que antes”. Esse é o segundo golpe: você vai pedir pro agente cobrir os arquivos tocados com testes, garantir a tipagem, seguir o layering do projeto… mas as coisas não saem como esperado. Isso porque você não deu ao agente as instruções completas pra atingir 100% das suas expectativas, e provavelmente é porque você nunca precisou pensar em quantas decisões tomamos em milésimos de segundos diariamente enquanto programamos — então escrever um prompt com essa profundidade não é fácil na primeira vez.
Até que você chega lá. Você finalmente encontra um conjunto de instruções que define o seu jeito de programar, de forma consistente e reproduzível, e agora sabe como pedir pro seu coding buddy fazer as coisas. Repetidamente, de novo e de novo. Sempre que começa uma nova tarefa, você ou vê o agente cometendo os mesmos erros — e precisa corrigi-lo toda vez —, ou antecipa o comportamento padrão dele e proativamente detalha tudo no prompt. O problema é que isso não escala: você realmente não é tão produtivo se precisa conduzir o agente pela mão em cada tarefa — você está supervisionando um Engenheiro Júnior, não treinando-o pra ser Sênior+.
Não estávamos falando de Harness Engineering?
É exatamente aí que o Harness Engineering entra em cena! O harness é definido como:
everything in an AI agent except the model itself
O objetivo do harness é restringir o modelo em determinados aspectos que ele não respeitaria intencionalmente 100% das vezes. A ideia é envolver o modelo com lembretes de contexto (probabilísticos — o agente pode raciocinar sobre eles e tomar outro caminho) e hooks de autocorreção (determinísticos — impedem o agente de desrespeitar certas restrições), inclinando os resultados gerados pelo agente na direção pretendida.
É aqui que o engenheiro 10x pode se tornar realidade: uma vez que você tenha definido o conjunto de modelos mentais e quality gates que aplicamos no nosso trabalho, podemos criar peças de harness pra deixar o agente de código ciente disso — e aí não precisamos mais instruí-lo, pelo menos em teoria. Claro, os modelos vão evoluir, o harness ao redor do seu agente de código vai evoluir, e talvez a forma como você programa e arquiteta software também mude, então novos harnesses customizados precisarão ser adicionados. Mas essa é a forma mais confiável de deixar o LLM se autocorrigir e chegar a um objetivo definido.
O que vem por aí
Com essa introdução, no próximo post da série vou falar sobre algumas skills que uso no dia a dia. Pretendo mostrar como uso hooks pra garantir um quality gate. Mais pra frente, vou usar a série como forma de mostrar meus avanços na criação de um workflow pra tarefas de longa duração, da concepção até a conclusão, garantindo que todos os objetivos intermediários foram atingidos.
Até o próximo post!
Este texto foi traduzido do inglês com suporte de inteligência artificial.