O código também ensina seu agente a errar

O agente encontra um comentário explicando uma gambiarra. Em vez de resolver o problema, usa aquela explicação para justificar outro remendo.

Lauren Tan, a @poteto, relata ter visto esse comportamento no código do Cursor. A reação no Dune, framework que sustenta o Grokbot, foi radical: proibir comentários para evitar que virassem justificativas para perpetuar soluções provisórias.

Eu não copiaria essa proibição. Comentários podem preservar decisões importantes. Mas o problema que motivou a escolha merece atenção: o agente recebe suas instruções e também lê os exemplos que você deixou no código.

Se os dois discordam, escrever mais uma regra no chat pode ser pouco.

A gambiarra ganhou status de exemplo

Você pede para seguir os padrões do projeto. O agente procura uma implementação parecida, encontra um atalho antigo e estende aquela solução.

Isso parece obediência. Dependendo do exemplo encontrado, é justamente o problema.

Lauren descreve a base de código como uma forma de memória. Não é um novo treinamento do modelo: os arquivos que ele consulta entram no contexto daquela tarefa. O padrão disponível ajuda a determinar a próxima mudança.

Um remendo tolerado ganha uma função que talvez não tivesse antes. Passa a ensinar como o sistema deve ser construído.

Por isso, a pergunta útil numa revisão vai além de "esta alteração funciona?":

Essa pergunta é uma adaptação da proposta de Lauren. Ela ajuda a separar uma solução aceitável para o caso atual de um exemplo que vale multiplicar. Se a resposta for não, vale identificar o atalho antes que ele vire convenção.

Uma instrução não é uma barreira

Imagine um relatório que trava a tela porque faz um cálculo pesado no mesmo lugar responsável por responder aos cliques. Você corrige a implementação e escreve: "não faça operações pesadas na interface".

Na próxima tarefa, o agente encontra outro relatório antigo e repete o padrão.

A orientação estava certa. O caminho errado continuava aberto.

No vídeo, Lauren apresenta uma ordem de preferência: arquitetura do código, análise estática, regras e revisão automatizada, skills e, por último, um guia de estilo dependente de revisão humana. Quanto mais a correção depende de alguém lembrar de uma frase, menos ela impede a reincidência por conta própria.

No exemplo do relatório, separe o cálculo da interface. Configure a checagem para rodar automaticamente a cada alteração e bloquear a integração se houver a importação proibida. O agente recebe um erro verificável, não apenas uma recomendação.

Lauren descreve restrições desse tipo no Dune para separar responsabilidades entre processos. Isso não prova que a aplicação inteira esteja livre de lentidão. Impede um caminho específico para introduzi-la.

Uma regra lembrada ajuda. Um erro bloqueado não precisa de lembrete.

Skills continuam úteis para explicar como trabalhar. Testes conferem comportamentos. A arquitetura pode restringir o que é possível montar. São proteções diferentes, com custos diferentes; não precisamos transformar toda preferência de escrita numa proibição técnica.

Antes de cobrar prova, dê meios de produzi-la

O agente precisa conseguir verificar o trabalho sem improvisar uma ferramenta nova a cada conversa.

Lauren combina dois componentes. Uma CLI, ferramenta operada por comandos, permite abrir a aplicação e coletar evidências, como registros de desempenho. Um mapa de funcionalidades explica o que existe no produto e como chegar a cada parte.

A necessidade do mapa apareceu num caso bem concreto: usuários enviavam capturas parciais da interface com pedidos vagos. Os agentes conseguiam operar o aplicativo, mas não sabiam localizar o problema mostrado.

Controle sem contexto deixava o agente adivinhando. O mapa oferecia caminhos de navegação; a ferramenta permitia percorrê-los e observar o resultado.

No nosso exemplo hipotético, não basta pedir "teste o relatório". A equipe precisa disponibilizar uma forma reproduzível de abrir aquela tela, carregar uma amostra autorizada e registrar o comportamento esperado. A correção do cálculo precisa ser conferida também; deixar a tela fluida entregando números errados não resolve.

A evidência deve corresponder ao que foi prometido. Uma captura de tela mostra aparência. Não demonstra, sozinha, desempenho ou correção dos dados. E testes nos casos escolhidos não equivalem a uma prova formal de todo o sistema.

Primeiro, pare de fabricar novas cópias

A proposta de Lauren inclui o papel de um gardener, alguém responsável por cuidar dos padrões do projeto. A função envolve remover dívida técnica, manter um caminho recomendado e criar checagens contra a repetição de erros.

O detalhe que torna isso praticável: você não precisa limpar o repositório inteiro antes de começar a impedir novas ocorrências.

Se existem implementações antigas do relatório, é possível restringir novas importações indevidas enquanto a equipe migra o legado em etapas. As exceções existentes precisam ficar explícitas, sem oferecer um atalho aberto para qualquer código novo.

Só bloquear também não basta. O caminho permitido precisa estar disponível e ser fácil de encontrar. Caso contrário, você apenas troca a revisão repetitiva por agentes presos numa mensagem de erro.

Eu começaria por uma falha bem delimitada, com uma alternativa funcionando. Depois pediria uma alteração que tentasse repetir o erro antigo, num ambiente de teste. A checagem deveria rejeitá-la. A implementação correta deveria passar.

Isso verifica a proteção, não só a boa vontade de quem recebeu as instruções. Se a checagem também bloquear casos válidos, ela precisa ser ajustada antes de virar padrão.

O que eu realmente penso

Um princípio da Olympus diz que a qualidade do processo define a qualidade das entregas. Para uma equipe enxuta, eu aplicaria isso às decisões que continuam exigindo a mesma intervenção humana.

O trabalho experiente aparece quando alguém percebe por que um erro se repete e decide onde colocar a proteção. Nem sempre a resposta é mais documentação. Às vezes é remover um exemplo ruim, oferecer uma implementação de referência ou impedir uma combinação inválida.

Também não usaria esse argumento para justificar uma reescrita interminável. O apetite do Shape Up cabe aqui: reservar um esforço limitado para eliminar um tipo de erro, sem transformar a melhoria numa reforma geral do produto.

Construir uma empresa calma inclui escolher quais problemas não deveriam voltar à mesa toda semana. Ainda haverá revisão humana, exceções e decisões de produto. Eu prefiro guardar essa atenção para o que exige julgamento, em vez de fiscalizar repetidamente uma importação que o próprio sistema poderia rejeitar.

Sua missão para os próximos 7 dias

Bloqueie um erro recorrente num projeto em que você já trabalha.

1. Localize o exemplo ruim. Escolha uma correção repetida e identifique o trecho que ensina o atalho. Defina qual comportamento precisa ser preservado.

2. Prepare a alternativa e a barreira. Disponibilize o caminho correto e uma checagem adequada ao erro. Limite o escopo; mantenha permissões e revisão antes de qualquer mudança em produção.

3. Tente reincidir em ambiente de teste. Confirme que o caso errado é rejeitado e o válido continua funcionando. Guarde a evidência. Um pedido mais enfático no chat não encerra esse experimento.

Conteúdos recomendados

• Lauren Tan: confiança, verificação e arquitetura para agentes. O vídeo que originou esta edição, especialmente a hierarquia das correções e o papel do gardener. Em inglês, no X; o acesso pode exigir login.

• Fail Fast — James Shore. O texto e o PDF explicam por que tornar erros visíveis perto da origem ajuda mais do que escondê-los com remendos. Em inglês, acesso aberto.

Forte abraço, Equipe Olympus