Quanto guideline um agente de código precisa?

Disclaimer Este texto foi inicialmente concebido pela IA Generativa em função da transcrição de um vídeo do Dev Eficiente. Se preferir acompanhar por vídeo, é só dar o play. Introdução Quanta configuração um agente de código realmente precisa para gerar bom código? Essa é a pergunta que eu venho tentando responder na prática, e ela faz parte de uma busca maior: até onde dá para minimizar o ser humano no loop da produção de código a partir de uma necessidade. Para começar a entender isso, montei um experimento. Peguei o mesmo backlog e pedi para que ele fosse implementado por quatro versões de agente, cada uma com um nível diferente de harness, ou seja, o conjunto de configuração e guideline ao redor do agente. A ideia era simples: será que um agente com pouca configuração gera algo muito diferente de um agente com muita configuração, ou com diferentes granularidades de configuração? Neste post eu mostro o desenho do experimento, os resultados e o que eu concluí até agora. O contexto: minimizar o humano no loop A plataforma onde hoje servimos os conteúdos do Dev + Eficiente foi integralmente desenvolvida com apoio de agentes baseados em IA generativa. Tanto o back-end quanto o front-end foram construídos com o Claude Code como principal agente, num trabalho que eu fiz junto com Anderson. Nessa rotina, a pergunta que não para de aparecer é até onde dá para revisar o mínimo possível de código. Esse tema não é só meu. Se você for ao blog da Anthropic, vai encontrar um post de 24 de março de 2026 chamado "Harness Design for Long-Running Application Development", onde uma engenheira descreve uma configuração que você ouve bastante por aí: um agente planejador, um agente gerador e um agente avaliador, rodando em sessões separadas, com o gerador e o avaliador colocados um contra o outro para maximizar a qualidade gerada. No blog da OpenAI tem um post de 11 de fevereiro de 2026, "Harness Engineering: Leverage Codex in an Agent-First World", contando sobre um app cuja restrição era que todo o código fosse desenvolvido pelo agente. Cada empresa conta a sua história. Foi a partir dessas inspirações, e da minha própria experiência, que tentei montar algo o mais próximo possível de um experimento isolado: mesmo input, configurações diferentes. O desenho do experimento Peguei o backlog de um desafio que temos na Jornada Dev + Eficiente: implementar o processo de checkout da Hotmart. São dez tarefas, com níveis de complexidade diferentes. A proposta foi implementar esse backlog de uma vez só, com quatro versões de configuração diferentes: Sem guideline nenhum. Só um prompt inicial de entrada definindo a condição de parada. Nada além disso. É uma implementação baseada unicamente no que o modelo aprendeu no treinamento e no que ele consegue produzir em função do que pedi. Apenas o CLAUDE.md. Extraí um CLAUDE.md da plataforma Dev + Eficiente. Ali estão os guidelines de back-end, os padrões de design, o padrão para testes, o padrão para geração de log e o esquema que eu uso para deixar a geração de log mais sistemática. CLAUDE.md mais uma skill revisora de código. A skill tem categorias de checagem: língua e nomenclatura, padrões de design do domínio, padrões de design das bordas mais externas, como olhar para controllers que lidam com requisições HTTP, como lidar com testes e como olhar para logs. CLAUDE.md mais múltiplos agentes revisores de granularidade ultrafina. Aqui são vários revisores especializados, cada um com um recorte: um revisor que olha a complexidade do código usando o CDD, que enxerga complexidade pelo viés do esforço cognitivo para entender o código; um revisor de controller, com as práticas que eu defendo para essa camada; um revisor de bordas externas, olhando os objetos de transporte; um revisor de design para domínio, linguagem e log; e uma skill orquestradora que conversa com as outras. Faltou uma quinta versão, que seria fazer tudo de fato em sessões separadas, isolando o contexto e reiniciando a sessão a cada etapa, como