Google presenta Auto-Diagnose, un sistema de IA que encuentra la causa de los fallos en pruebas de integración

Google ha presentado Auto-Diagnose, un sistema interno basado en LLM que analiza los logs de las pruebas de integración fallidas, extrae por sí solo las líneas clave y publica un diagnóstico directamente en la revisión de código. Para los grandes equipos de ingeniería, es un intento de eliminar uno de los costes ocultos más caros del desarrollo: las horas, y a veces los días, que se pierden buscando a mano la causa de un fallo entre decenas de archivos de log.

El problema es medible en Google. En una encuesta interna a 6059 desarrolladores, el diagnóstico de fallos en pruebas de integración entró en el top 5 de quejas más frecuentes sobre herramientas de ingeniería. Una encuesta adicional a 116 ingenieros mostró que el 38,4% de estos fallos tarda más de una hora en resolverse y el 8,9%, más de un día. Para las pruebas unitarias, las cifras fueron del 2,7% y el 0%, respectivamente.

La razón es clara: una prueba de integración casi nunca falla en un único punto evidente. Un caso típico incluye un test driver aparte, un conjunto de servicios dentro del system under test, logs repartidos entre distintos componentes y una gran cantidad de advertencias y errores que nada tienen que ver con la causa raíz. En la investigación de Google, la prueba fallida mediana contenía 16 archivos de log y 2801 líneas de log.

Auto-Diagnose se integra en el flujo de desarrollo existente. Cuando falla una prueba de integración, el sistema recibe el evento automáticamente, recopila los logs del test driver y de los componentes del SUT de nivel INFO o superior, los fusiona en un único flujo y los ordena por tiempo. Después envía todo ello, junto con los metadatos de los componentes, a Gemini 2.5 Flash.

El modelo funciona sin ajuste fino con logs específicos de Google: la apuesta no es el fine-tuning, sino un prompt estricto y la integración en el proceso. El prompt obliga al modelo a avanzar paso a paso: encontrar las secciones de logs, identificar el componente donde ocurrió el fallo, comprobar el contexto y solo entonces formular una conclusión.

La clave es la prohibición de conjeturar. Si en los logs no hay líneas del componente exacto que no arrancó o no pasó a estado healthy, el modelo no debe inventar, sino responder claramente que faltan datos. Después, la respuesta se convierte a un formato estándar y se publica en Critique, el sistema interno de revisión de código de Google, donde el desarrollador ve de inmediato la conclusión, los pasos de la investigación y las líneas de log más relevantes.

Por las cifras, el sistema parece menos un prototipo de laboratorio y más una herramienta interna realmente rodada. En una revisión manual de 71 fallos reales de 39 equipos, Auto-Diagnose identificó correctamente la causa raíz en 64 casos, es decir, con una precisión del 90,14%. Después, Google lo desplegó para todos los fallos de integración en cambios de código de toda la compañía, desde mayo de 2025. En ese tiempo el sistema ha trabajado sobre 52 635 pruebas únicas, 224 782 ejecuciones, 91 130 cambios de código y 22 962 autores.

El tiempo mediano de publicación del diagnóstico en la revisión de código fue de 56 segundos y el percentil 90, de 346 segundos, de modo que el resultado suele aparecer antes de que el ingeniero se haya pasado del todo a otra tarea. De media, cada ejecución consume 110 617 tokens de entrada y genera 5962 de salida.

La respuesta de los usuarios también es buena: de 517 valoraciones de 437 desarrolladores, la proporción de marcas Not helpful fue del 5,8%, por debajo del umbral interno de Google del 10% para este tipo de herramientas, y en utilidad Auto-Diagnose ocupó el puesto 14 de 370 sistemas que publican hallazgos en Critique.

Hay además un beneficio colateral importante. Siete errores de la evaluación manual no resultaron ser un fallo del modelo como tal, sino problemas de la infraestructura de logging: en unos casos no se guardaban los logs del test driver tras un crash; en otros, los del propio componente caído. Respuestas similares del tipo «hacen falta más datos» ayudaron después a detectar unos 20 problemas de infraestructura más.

Por eso, la importancia de Auto-Diagnose no radica solo en que Google acelere el análisis de fallos de pruebas. La compañía muestra un patrón más práctico de uso de los LLM en desarrollo: no pedir al modelo que arregle código a ciegas, sino integrarlo en un cuello de botella del proceso, darle reglas estrictas para no conjeturar y devolver el resultado justo donde el ingeniero ya trabaja. Para los grandes equipos, quizá sea un escenario más valioso que otro «asistente de programación con IA», porque reduce el tiempo hasta entender la causa del fallo, que es lo que con más frecuencia frena una versión.