Você entra no mar e nada em linha reta. Pelo menos é o que parece, de dentro d’água.
A correnteza vai lhe empurrando pra fora da rota e você só se dá conta quando volta pra praia e percebe que tá longe da sua sandália.
Nadador experiente levanta a cabeça com frequência. Custa quase nada.
Agora imagine que nadar é produzir código e que o seu agente é muito rápido nisso.
O protocolo que ninguém pediu
O pedido tinha uma linha: “faz a autenticação seguindo o protocolo OAuth”.
O que voltou foi o protocolo inteiro, implementado do zero, com os fluxos que ninguém ia usar e os casos de exceção que ninguém pediu. E não era código ruim. Compilava, rodava e passava nos testes que ele mesmo tinha escrito.
Pra se ter uma ideia, a biblioteca oauthlib tem cerca de 12.520 linhas de código. É código maduro: testado e validado com milhões de downloads por mês. Em alguns minutos, o agente reescreveu o que a comunidade levou anos para amadurecer.
Nada disso foi para produção. Eu olhei, pedi que ele levantasse as bibliotecas que já faziam aquilo, e o trabalho inteiro virou lixo.
E olha a quantidade de token que foi pro lixo entre o meu pedido e a verificação: um protocolo inteiro.
Peça a pesquisa, não a implementação
O erro estava no pedido, não na resposta.
“Faz a autenticação” é claríssimo, e mesmo assim entrega um escopo inteiro. Ele é abrangente: diz o que fazer e não como. A decisão de implementar na mão ou usar uma biblioteca fugiu do controle de quem pediu.
E dava para consertar. Bastava pedir a mesma coisa que eu acabei pedindo, só que antes: “levanta as bibliotecas maduras que fazem isso e o que cada uma custa”. Esse é um pedido inteiro, e a resposta dele é uma decisão sua. Definida a direção, aí você acelera.
A diferença entre pedir isso antes e pedir depois é o tamanho do que se joga fora.
Então é só escrever pedidos melhores?
A conta aparece na areia
Não, e é aqui que o mar volta.
Pedir a pesquisa resolve os problemas que você já conhece. Quem pede assim é porque já cometeu esse erro antes. O problema é que a lista dos erros que você ainda não conhece é a que não acaba, e o agente pode assumir o que você não previu como parte do escopo.
Aí é onde o agente começa a desviar do pedido e você vai precisar identificar o desvio e corrigir o rumo. Se corrigir cedo, o novo rumo é quase igual ao original. Corrigido tarde, ele vira uma travessia inteira só para voltar à linha, e dessa vez nadando contra a correnteza.
E o desvio é traiçoeiro porque não dói enquanto acontece: dentro d’água, nadar torto e nadar reto são a mesma sensação.
Repare no que isso quer dizer. O tamanho do prejuízo não depende de quão errado o agente estava. Depende da quantidade de trabalho que ele fez sem supervisão.
A fórmula, para quem trabalha com agente
É disso que Alisson Vale trata em “A Fórmula da Eficácia”. Eficácia é fazer a coisa certa, e fazer a coisa certa não é saber de antemão qual decisão está correta. É evitar avançar estando errado. Você não controla se vai acertar. Controla quanto tempo leva até descobrir que está errando.
Por trás disso está o ciclo OODA, do estrategista militar John Boyd: observar, orientar, decidir, agir. Quem fecha a volta mais rápido decide melhor, não por acertar mais, mas por errar por menos tempo.
O que muda com agente é o preço da volta. Verificar uma hipótese custava uma reunião e uma semana. Hoje custa alguns minutos. A ferramenta que acelerou o erro acelerou junto a possibilidade de pegá-lo cedo, e quase ninguém está usando a segunda metade.
O relatório de 2026 do DORA resume a régua numa frase que vale colar na parede: “não medimos a IA pelo código que ela escreve, e sim pelos gargalos que ela desobstrui” (no original, “we don’t measure AI by the code it writes but by the bottlenecks it clears”). Um PR de 12.520 linhas é código escrito. E ele não desobstruiu gargalo nenhum: criou um.
Assuma que o agente vai errar
O ditado diz que errar é humano, mas ele também se aplica aos agentes. Da mesma forma que estamos sempre verificando e revisando o nosso trabalho e o dos nossos colegas, devemos usar como premissa que o agente também vai errar. Não por pessimismo, e sim por projeto. Quem acha que vai acertar sempre peca na verificação e descobre o erro da pior forma. Quem assume erro evita que ele persista e aprende mais.
Você provavelmente já acredita nisso. Na pesquisa State of Code da Sonar, com mais de 1.100 desenvolvedores, 96% dizem não confiar plenamente que o código gerado esteja funcionalmente correto, e 61% dizem que a IA costuma produzir código que parece certo e não é confiável.
O que não acompanha é a prática. Na mesma pesquisa, 82% dizem que a IA os faz programar mais rápido, e só 48% sempre conferem o que ela escreveu antes de commitar. A velocidade foi adotada. A verificação, não.
Assumindo que o agente pode errar, aqui vão quatro perguntas para você se fazer antes de mandar o prompt:
Cabe numa revisão? Se você não vai ler o diff inteiro, o pedido era grande demais.
O critério de pronto foi declarado antes? “Funcionou” não é critério. É condição mínima para aceitar a resposta.
Verificar é diferente de rodar? Rodar prova que executa. Verificar é conferir contra o critério que você escreveu antes.
É uma decisão por vez? Pedir a escolha da biblioteca e a implementação no mesmo pedido entrega as duas decididas por quem não conhecia o contexto.
Não é teoria contra a corrente. Na pesquisa de 2026 do The Pragmatic Engineer, com 906 pessoas, 56% fazem 70% ou mais do trabalho de engenharia com IA. E continuam com o terminal e a IDE lado a lado, revisando o que o agente muda.
Onde o ciclo curto custa caro
Verificar tem preço, e o preço é atenção.
O DORA report de 2026, The ROI of AI-assisted Software Development deu um nome pra isso: imposto de verificação (verification tax). É o tempo que você gasta revisando código gerado, e aponta esse imposto como uma das causas do vale de produtividade que aparece logo depois de adotar IA. Eles chamam esse vale de mensalidade da transformação, e avisam: quem lê a queda como fracasso corta o investimento bem no fundo dela.
E dá para medir o imposto. Na pesquisa da Sonar, 38% dizem que revisar código gerado dá mais trabalho que revisar o de um colega humano, e quase um quarto da semana de trabalho vai em conferir, consertar e validar o que a IA produziu. O tempo que você economiza escrevendo volta como tempo revisando.
Existe uma segunda fatura, e ela não vence agora. Addy Osmani chama de dívida de compreensão (comprehension debt): você entende cada vez menos da base de código que leva o seu nome. É trivialmente fácil revisar um código que você já não saberia escrever do zero, e quando a sua capacidade de ler para de acompanhar a de gerar, você não está mais fazendo engenharia. Está torcendo.
Então a medida não é “o menor pedaço possível”. Quem nada de cabeça erguida o tempo todo não nada, boia olhando. A medida é o maior pedaço que ainda cabe numa revisão de verdade, e ela é diferente para cada pessoa e para cada base de código.
É por isso que ele erra longe
A velocidade não é o problema. Ela é a melhor coisa que aconteceu com esse trabalho em muito tempo.
O problema é o que a gente escolheu fazer com ela. Dá para gastar velocidade dando mais braçadas antes de olhar, e é isso que produz um PR que ninguém consegue revisar. Ou dá para gastar do outro jeito: pedaço pequeno, critério escrito antes, cabeça erguida no caminho. A mesma velocidade, usada para errar perto.
E você? Qual foi o prompt que você mandou e o agente fez mais do que você conseguia revisar?
Se essa ideia foi útil, passa pra frente.
Excelente reflexão, valeu!
O Alisson Vale vem falando dessa questão de não confundir eficiência (fazer do jeito certo) com eficácia (fazer a coisa certa) há mais de 10 anos e eu notei como nos últimos tempos, ao trocar ideia sobre uso de IA com colegas isso sempre volta, pq quando a gente fica munido com várias skills pra fazer análise, fazer o "plumbing" de novas features, escrever código de acordo com os padrões do time, PRs e commits igualmente "caprichados", é fácil a gente entrar nesse modo acelerado e como vc disse, acabar bem longe.
Isso fica ainda mais perigoso pq antes de IA, quando chegava aquele momento no dia em que o cérebro cansava, só nos restava dar um tempo, ir tomar um café, fazer uma outra tarefa menos intensiva, mas agora isso pode virar uma sessão de vibe-coding não intencional, a gente só aprovando as coisas com mais facilidade, lendo mais rápido e por alto o que tá saindo - de novo, confundindo eficiência e produtividade com eficácia.
Aí volta a valer o mesmo princípio por trás de tudo quanto é boa prática dos últimos 30 anos, seja XP, TDD, Agile e agora com AI: ciclos curtos de iteração, feedback, validação, e não esquecer de as vezes parar um pouco pra voltar pro "big picture".