Google apresenta o Auto-Diagnose, sistema de IA que encontra a causa de falhas em testes de integração

O Google apresentou o Auto-Diagnose, um sistema interno baseado em LLM que analisa os logs de testes de integração que falharam, extrai sozinho as linhas-chave e publica um diagnóstico direto no code review. Para grandes equipes de engenharia, é uma tentativa de eliminar um dos custos ocultos mais caros do desenvolvimento: as horas, e às vezes dias, gastas na busca manual pela causa de uma falha em dezenas de arquivos de log.

O problema é mensurável no Google. Em uma pesquisa interna com 6059 desenvolvedores, o diagnóstico de falhas em testes de integração entrou no top 5 das reclamações mais frequentes sobre ferramentas de engenharia. Uma pesquisa adicional com 116 engenheiros mostrou que 38,4% dessas falhas levam mais de uma hora para ser resolvidas e 8,9%, mais de um dia. Para testes unitários, os números foram 2,7% e 0%, respectivamente.

A razão é clara: um teste de integração quase nunca falha em um único ponto óbvio. O caso típico envolve um test driver separado, um conjunto de serviços dentro do system under test, logs espalhados por diferentes componentes e uma enorme quantidade de avisos e erros sem relação com a causa raiz. Na pesquisa do Google, o teste com falha mediano tinha 16 arquivos de log e 2801 linhas de log.

O Auto-Diagnose se encaixa no fluxo de desenvolvimento existente. Quando um teste de integração falha, o sistema recebe o evento automaticamente, coleta os logs do test driver e dos componentes do SUT de nível INFO ou superior, une tudo em um único fluxo e ordena por tempo. Depois envia o conjunto, junto com os metadados dos componentes, ao Gemini 2.5 Flash.

O modelo funciona sem ajuste fino com logs específicos do Google: a aposta não é em fine-tuning, mas em um prompt rígido e na integração ao processo. O prompt obriga o modelo a seguir etapas: encontrar as seções de logs, identificar o componente em que ocorreu a falha, verificar o contexto e só então formular a conclusão.

O ponto central é a proibição de adivinhar. Se nos logs não há linhas do componente exato que não subiu ou não ficou healthy, o modelo não deve inventar, e sim responder claramente que faltam dados. Depois, a resposta é convertida para um formato padrão e publicada no Critique, o sistema interno de code review do Google, onde o desenvolvedor vê de imediato a conclusão, os passos da investigação e as linhas de log mais relevantes.

Pelos números, o sistema parece menos um protótipo de laboratório e mais uma ferramenta interna realmente testada em campo. Em uma verificação manual de 71 falhas reais de 39 equipes, o Auto-Diagnose identificou corretamente a causa raiz em 64 casos, ou seja, com precisão de 90,14%. Em seguida, o Google o lançou para todas as falhas de integração em mudanças de código em toda a empresa, a partir de maio de 2025. Nesse período, o sistema atuou em 52.635 testes únicos, 224.782 execuções, 91.130 mudanças de código e 22.962 autores.

O tempo mediano para publicar o diagnóstico no code review foi de 56 segundos, e o percentil 90, de 346 segundos, ou seja, o resultado costuma aparecer antes de o engenheiro mudar de vez para outra tarefa. Em média, cada execução consome 110.617 tokens de entrada e gera 5962 de saída.

O feedback também é bom: de 517 avaliações de 437 desenvolvedores, a parcela de marcações Not helpful foi de 5,8%, abaixo do limite interno do Google de 10% para essas ferramentas, e em utilidade o Auto-Diagnose ficou em 14º lugar entre 370 sistemas que publicam findings no Critique.

Há ainda um benefício colateral importante. Sete erros da avaliação manual não eram falhas do modelo em si, mas problemas na infraestrutura de logging: em alguns casos os logs do test driver não eram salvos após um crash; em outros, os do próprio componente que falhou. Respostas parecidas, do tipo "são necessários mais dados", ajudaram depois a identificar cerca de 20 outros problemas de infraestrutura.

Por isso, a principal importância do Auto-Diagnose não é apenas que o Google acelera a análise de falhas de testes. A empresa mostra um padrão mais prático de uso de LLMs no desenvolvimento: não pedir ao modelo que conserte código às cegas, mas encaixá-lo em um gargalo do processo, dar a ele regras rígidas contra adivinhação e devolver o resultado exatamente onde o engenheiro já trabalha. Para grandes equipes, talvez seja um cenário mais valioso do que mais um "assistente de programação com IA", porque reduz o tempo até entender a causa da falha, e é isso que mais frequentemente trava um release.