A Lei de Brooks diz que adicionar pessoas a um projeto atrasado o atrasa ainda mais. Sua mutação na era da IA é mais afiada: adicionar agentes a um projeto com requisitos pouco claros não só o deixa mais lento, como faz a resposta errada chegar antes. Essa é a dor. Você tem um projeto com requisitos que nunca foram definidos, e alguém decide resolvê-lo lançando vários agentes. Cada agente produz em velocidade de máquina, então você não espera mais tempo por uma resposta correta: espera menos tempo por uma resposta segura, coerente e completamente errada.
No desenvolvimento clássico, a confusão é um gargalo. Um time humano só consegue avançar a uma certa velocidade, e os mal-entendidos demoram para vir à tona. Com os agentes de IA, o gargalo desaparece, mas a confusão fica. Cada agente conclui sua parte em minutos e, como os requisitos eram pouco claros, cada parte incorpora a mesma ambiguidade de um jeito diferente. A integração dessas partes multiplica os erros em vez de corrigi-los.
No dia a dia, isso parece um sprint para lugar nenhum. Você pede a um agente que gere uma funcionalidade, e ele devolve um código que parece plausível. Pede a outro que revise, e ele aprova porque compartilha o mesmo modelo mental errado. Você adiciona um terceiro para escrever testes, e os testes passam contra o comportamento incorreto. O ciclo inteiro parece produtivo até alguém ler os requisitos, ou o que sobrou deles.
A raiz do problema não são os agentes. É que ninguém obriga a saída a ser comparada com algo estável. Quando os requisitos são vagos, os agentes preenchem as lacunas com suposições. Mais agentes significa mais suposições, e cada suposição parece uma decisão para o próximo agente.
O padrão que quebra esse ciclo é fazer a IA se revisar. Na prática, consiste em introduzir no fluxo um momento em que a saída do agente se volta contra ela mesma: que declare os requisitos que inferiu, que enumere as suposições que assumiu e que verifique se a resposta realmente os satisfaz. Uma segunda passada, um prompt diferente ou uma autoavaliação deliberada detecta a lacuna antes que ela vá mais longe.
A verificação precisa ser concreta. Perguntar “você tem certeza?” não basta. O agente precisa comparar a resposta com o pedido original, expor contradições e apontar os detalhes que faltam. Quando os requisitos são pouco claros, a verificação mais importante é a primeira: “O que exatamente você supôs sobre o que eu pedi?” Essa pergunta obriga o agente a colocar na mesa os requisitos que estavam ocultos.
Depois que você aplica esse padrão, a mutação da lei perde os dentes. Você continua podendo adicionar agentes, mas eles não ficam livres para produzir saída sem revisão. Cada agente tem um ponto de controle obrigatório onde o próprio raciocínio é examinado. Isso muda a dinâmica: em vez de acelerar rumo à resposta errada, os agentes começam a convergir para um entendimento comum corrigido.
O efeito prático é que o projeto fica mais lento nos primeiros minutos e mais rápido depois. O passo mais lento é aquele em que o agente para e revisa o próprio trabalho. Esse passo é exatamente o que evita que a cascata de mal-entendidos plausíveis se transforme na entrega final.
Você vai sentir vontade de pular a revisão porque parece tempo perdido. O agente já te deu uma resposta, e ela soa convincente. Mas, se os requisitos não estão claros, cada resposta é uma suposição com marca de tempo. A revisão não é uma formalidade; é o único jeito de transformar os agentes em detectores de confusão em vez de multiplicadores dela.
O padrão é simples o bastante para usar hoje: faça a IA se revisar. Não confie na primeira saída, não adicione mais agentes esperando que um deles tenha sorte; faça da autoverificação um passo obrigatório no loop de cada agente. Esse é o caminho através da dor. Ele não define magicamente os requisitos que faltam; ele os expõe e te dá a oportunidade de corrigi-los antes que a resposta errada se transforme no entregável.