Vozes
Simon Willison: a habilidade com agentes é verificar
Para Simon Willison, a skill que separa quem lucra com agentes de código é instruir e verificar, não revisar linha a linha. Por que isso vale na sua operação.
Simon Willison, cocriador do Django e criador do Datasette, é uma das vozes que mais gente lê quando o assunto é usar modelos de linguagem de verdade, e não em slide. Em um post curto publicado em 22 de agosto, ele resumiu numa frase o que separa quem realmente lucra com agentes de código de quem só se ilude com eles. A frase merece ser lida com calma, porque ela corrige o mal-entendido mais comum sobre programar com IA.
O que ele disse
Nas palavras do próprio Willison: "A habilidade-chave para fazer uso produtivo de agentes de código é conseguir instruí-los com confiança sobre como fazer as mudanças e depois verificar com confiança que essas mudanças foram aplicadas da forma correta." E ele completa: "Às vezes isso envolve revisar cada linha de código que eles escreveram, mas há outras formas de atingir esse objetivo. Examinar cada linha de código nunca foi a maneira mais eficaz de validar uma mudança em um software."
O ponto é fino e fácil de passar batido. Willison não está dizendo que revisão de código não importa. Está dizendo que a revisão linha a linha, aquela leitura exaustiva que muita gente trata como o padrão-ouro de qualidade, sempre foi uma ferramenta limitada, e continua limitada quando o autor do código é um agente. A ilusão de controle que ela dá é justamente o risco.
Por que a verificação é o gargalo, não a geração
A intuição de quase todo mundo sobre agentes de código está no lugar errado. As pessoas se impressionam com a velocidade da geração: o agente escreve em segundos o que levaria uma tarde. Mas a geração nunca foi o gargalo do software. O gargalo sempre foi ter certeza de que o que foi escrito faz o que deveria, e só o que deveria.
Quando um humano escreve o código devagar, ele carrega no processo um monte de verificação implícita: ele pensou no caso de borda, lembrou da regra de negócio, sentiu o cheiro de que algo ia quebrar. O agente pula essa parte. Ele produz uma resposta plausível em altíssima velocidade, e a plausibilidade é traiçoeira, porque um código errado pode parecer perfeitamente razoável na leitura. Por isso ler linha a linha engana: você está avaliando se o código parece certo, não se ele está certo.
A geração ficou barata. A verificação ficou o trabalho. Quem não move a sua atenção da primeira para a segunda vai produzir mais código e mais erro na mesma proporção.
Willison está apontando para uma mudança de onde o esforço humano rende. Instruir bem, com um pedido claro e um critério de sucesso, e depois provar que o resultado bate com esse critério: por teste automatizado, por observabilidade, por uma revisão dirigida aos pontos de risco. Ler tudo vira uma entre várias táticas, usada onde o risco pede, não um ritual aplicado a cada mudança.
A ponte com o que já dissemos
Essa tese conversa direto com duas ideias que já tratamos aqui. A primeira é a de ensinar o agente de código a se avaliar, com Hamel Husain: evals e testes são exatamente o "verificar com confiança" que Willison descreve, só que sistematizados. A segunda é o alerta de DHH sobre a execução sem fim que a IA facilita: quando gerar código fica trivial, o perigo é confundir volume com progresso. As duas apontam para o mesmo lugar que Willison: a restrição saiu da produção e foi para a validação.
Vale também um gancho com um tema desta semana. Quando os protocolos de agentes começam a se conversar via A2A e MCP, a superfície de coisas que precisam ser verificadas só cresce. Um agente que aceita instrução de outro agente é mais poder e mais risco ao mesmo tempo. A habilidade de verificar, que Willison coloca no centro, deixa de ser virtude de programador cuidadoso e vira requisito de operação.
O que fazer com isso na segunda de manhã
O recado é organizacional, não só técnico. Se a sua empresa está acelerando o uso de agentes de código, três movimentos práticos.
Contrate e promova pela habilidade certa. A pessoa valiosa na era dos agentes não é a que digita mais rápido, é a que sabe especificar com precisão o que quer e provar que o resultado está correto. Isso é uma competência treinável, e vale colocá-la no centro da avaliação de quem trabalha com IA.
Monte o arnês de verificação antes de abrir a torneira. Testes automatizados, critérios de aceite escritos, observabilidade em produção e revisão dirigida a risco. Sem isso, acelerar a geração só acelera a chegada do bug. Com isso, a velocidade do agente vira ganho real.
E resista à revisão linha a linha como muleta. Ela dá conforto e consome tempo, muitas vezes sem pegar o erro que importa. Reserve-a para os trechos onde o risco justifica, e confie mais no teste que roda do que no olho que cansa.
A frase de Willison é curta, mas reorganiza a prioridade de qualquer time que programa com IA. O agente resolveu a parte fácil, escrever. A parte que decide se isso vira produtividade ou dívida, verificar, continua sendo humana. Quem entende isso cedo transforma agente de código em vantagem; quem não entende, transforma em uma máquina de gerar retrabalho bem-apresentado.
Se o seu time está adotando agentes de código e você quer montar o processo de verificação antes de acelerar, fale com a gente no WhatsApp para desenhar isso na sua operação.
Fontes
Perguntas frequentes
Quem é Simon Willison e por que ouvir ele sobre agentes?
Simon Willison é um engenheiro britânico, cocriador do framework Django e criador do Datasette, uma ferramenta de exploração de dados. Há anos ele mantém um dos blogs mais influentes sobre LLMs na prática, testando modelos, documentando padrões de engenharia com IA e a biblioteca llm que ele mantém. Ele não fala de agentes como vendedor nem como cético de plateia: fala como quem usa a ferramenta todo dia e escreve o que funciona e o que quebra. Por isso a leitura dele sobre verificação tem peso.
Se não é para revisar linha a linha, como valido o código de um agente?
Willison aponta que ler cada linha nunca foi o método mais eficaz, nem mesmo antes da IA. As alternativas: escrever testes automatizados que provem o comportamento esperado, definir critérios de aceite claros antes de pedir a mudança, usar observabilidade para ver o código rodando com dados reais, e revisar com foco nos pontos de risco em vez de varrer tudo. A revisão linha a linha vira uma entre várias ferramentas, usada onde o risco justifica, não um ritual aplicado a tudo por padrão.