Comentários TODO obsoletos distraem agentes de IA, mostra estudo do Google

Um comentário TODO(bug/12345) esquecido há anos no código pode parecer inofensivo para um humano, que aprendeu a ignorar esse tipo de ruído. Para um agente de IA↳Agentes de IA42 conteúdosOpera passa a integrar ChatGPT, Claude e outros agentes de IADev (Back & Front) · mar 2026Operações mais inteligentes, decisões mais rápidas: o impacto da IA agêntica na rotina de TIAI · abr 2026Adobe aposta em orquestração de agentes de IA: o que muda para devsDev (Back & Front) · abr 2026Ver tudo em AI → lendo o mesmo arquivo durante a fase de planejamento de uma tarefa, esse comentário é lido como uma instrução ativa. É essa diferença de leitura que o Google Developers Blog quantificou num post publicado em 6 de novembro de 2026, assinado por Sam Saccone (Senior Staff Software Engineer) e Madhuri Garikapati (Senior Staff Data Scientist).

O que é fácil para humanos passarem batido no código, os agentes enxergam como uma chamada para agir.

Sam Saccone e Madhuri Garikapati, Google Developers BlogWhat is easy for humans to skim past in code, agents see as a call to action.

Como o Google mediu algo que não dá para revisar à mão

Medir quantas vezes um agente cai nessa armadilha em escala, com milhões de sessões mensais, é inviável por revisão humana. O Google usou um proxy objetivo: comentários inline no padrão TODO(bug/...) ou FIXME(bug/...). Esses comentários costumam sobreviver muito depois que o bug referenciado foi resolvido ou abandonado, enquanto o ticket vinculado continua sendo o registro canônico do status real.

Cruzando cada TODO que um agente encontra com o status real do ticket (fechado, duplicado, ainda aberto) e com o prompt original do desenvolvedor, a equipe conseguiu separar, em escala, trabalho legítimo de desvio de rota. A análise cobriu rastros distribuídos de interações de agentes de milhares de engenheiros, somando centenas de milhões de passos individuais de agente.

Os números da distração

Os resultados, controlados por desenvolvedor, complexidade do codebase, tipo de tarefa, nível do modelo, número de arquivos lidos e tamanho do prompt inicial (regressão de efeitos fixos multi-via com erros padrão agrupados por desenvolvedor, p<0,0001), mostram que o problema é real e mensurável:

Ou seja: em 94% dos encontros com um TODO referenciando bug, o agente simplesmente ignora o comentário, como um humano faria. O problema concentra-se nos 6% restantes, e dentro desse recorte, mais de 4 em cada 5 ações foram iniciativa do próprio agente, sem o desenvolvedor ter pedido nada relacionado ao bug.

Dois jeitos de o agente se perder

Cruzando os desvios não pedidos com o status real do ticket, o Google identificou dois modos de falha distintos:

Mais de dois quintos dos desvios não pedidos (43%, somando as três primeiras linhas) perseguem tickets que já estão mortos. Na maioria dos outros casos (57%), o bug ainda está aberto e o agente amplia o escopo da tarefa por conta própria, às vezes só pesquisando, às vezes editando código de verdade sem autorização.

Dois exemplos do próprio Google

O post descreve duas trajetórias reais observadas internamente. Na primeira, batizada de "the obsolete detour", um agente investigando um bug não relacionado abre o arquivo SurfaceControlTest.java e encontra um // TODO(bug/XXX). O bug havia sido corrigido em 2023, mas o comentário continuava no código, levando o agente a gastar múltiplos passos investigando algo que não existia mais.

Na segunda, "the eager agent", o agente encontra um TODO dentro do próprio bug que estava investigando e decide, por conta própria, "corrigir" o código. Ele executa várias buscas internas e de código, e acaba alterando o ModelDownloaderV1. Mais adiante na trajetória, o humano precisou intervir para questionar o aumento de escopo, e o próprio modelo reconheceu que tinha extrapolado o que foi pedido.

Em resumo: nos dois casos os desvios foram triviais a moderados, mas consumiram tempo, tokens e exigiram intervenção humana para cortar o caminho errado. Multiplicado por centenas de milhões de passos, isso deixa de ser anedota e vira custo de operação.

O que o Google construiu para resolver isso

A resposta interna não foi só apagar TODOs. O Google criou agentes dedicados a varrer a totalidade dos codebases em busca de referências a bugs marcados como corrigidos ou obsoletos. Só isso não bastava, porque um TODO pode ser estrutural: antes de sugerir a remoção, o agente precisava checar o histórico do bug, do arquivo e das mudanças no código, às vezes remontando anos de commits, para confirmar que a intenção original por trás do comentário já não fazia mais sentido.

Só quando essa verificação multi-camada confirmava que o TODO era de fato obsoleto, o agente enviava a mudança para revisão humana. Ao longo dos últimos seis meses (de maio a outubro de 2026, aproximadamente), essa ferramenta de limpeza removeu milhares de referências obsoletas, com taxa de aceitação dos revisores humanos acima de 95%.

O que muda para quem mantém um repositório

O dado mais útil aqui não é o percentual isolado, é a direção: dívida técnica que antes era "baixa prioridade" porque nenhum humano ia lá ler aquele canto do código agora tem custo ativo, porque o agente lê tudo que entra no contexto durante o planejamento. Projetos que ficaram na gaveta de limpeza por anos precisam ser reavaliados à luz de agentes operando em escala sobre o mesmo código.

Na prática, dá para adaptar a metodologia do Google sem ter a infraestrutura deles:

• Rode uma busca simples por TODO(bug/ e FIXME(bug/ no repositório e cruze manualmente (ou com um script) com o status dos tickets referenciados no seu rastreador de issues.
• Trate presubmit analyzers e scanners de corpus inteiro como parte do kit básico de "codebase amigável a agente", não como luxo.
• Se for construir um agente limpador próprio, mantenha o gate de revisão humana: mesmo o Google, com verificação multi-camada, não dispensa esse passo, e ainda assim erra em menos de 5% dos casos.
• Ao revisar um PR gerado por agente, desconfie de mudanças que tocam arquivos fora do escopo pedido: é exatamente o padrão do caso ModelDownloaderV1 descrito no post.

Vale a ressalva: os números vêm do ambiente interno do Google, com seus próprios modelos, codebases e ferramentas de agente. A magnitude exata (70% mais passos, 105% mais espera) pode não se repetir igual num repositório pequeno com outro provedor de agente. Mas a lógica por trás, comentário morto vira contexto ativo, é estrutural a qualquer sistema que leia arquivos inteiros para planejar uma tarefa, e vale auditar antes que o próximo agente autônomo tropece nela.

Fonte: Google Developers Blog