Google presentó Auto-Diagnose — un sistema de IA para encontrar causas de fallos en pruebas de integración

Google presentó Auto-Diagnose, un sistema interno basado en LLM que analiza los registros de pruebas de integración fallidas, extrae automáticamente líneas clave y publica diagnósticos directamente en la revisión de código. Para grandes equipos de ingeniería, esto representa un intento de eliminar uno de los costos ocultos más caros del desarrollo: las horas, y a veces días, que se gastan buscando manualmente la causa de un fallo en decenas de archivos de registro. El problema de Google es bastante medible.

En una encuesta interna de 6059 desarrolladores, el diagnóstico de fallos de pruebas de integración entró en el top 5 de quejas más frecuentes sobre herramientas de ingeniería. Una encuesta de seguimiento de 116 ingenieros mostró que el 38,4% de tales fallos tardaban más de una hora en diagnosticarse, y el 8,9% tardaban más de un día. Para pruebas unitarias, estas cifras fueron del 2,7% y 0% respectivamente.

La razón es clara: una prueba de integración casi nunca falla en un único lugar obvio. En un caso típico, hay un controlador de prueba separado, un conjunto de servicios dentro del sistema bajo prueba, registros distribuidos entre diferentes componentes, una cantidad de advertencias y errores que no están relacionados con la causa raíz. En la investigación de Google, la prueba fallida mediana contenía 16 archivos de registro y 2801 líneas de registros.

Auto-Diagnose se integra en el flujo de trabajo de desarrollo existente. Cuando una prueba de integración falla, el sistema automáticamente recibe un evento, recopila registros del controlador de prueba y componentes SUT en nivel INFO y superior, los consolida en un único flujo y los ordena por tiempo. Luego, junto con los metadatos de componentes, todo esto se envía a Gemini 2.

5 Flash. El modelo funciona sin ajuste fino en registros especiales de Google: la apuesta se hace no en ajuste fino, sino en un mensaje codificado de forma rígida e integración en el proceso. En el mensaje, se obliga al modelo a seguir pasos: encontrar secciones de registros, identificar el componente donde ocurrió el fallo, verificar el contexto y solo entonces formular una conclusión.

El punto clave es la prohibición de adivinar. Si los registros no contienen líneas del componente exacto que no se inició o no se volvió saludable, el modelo no debe especular, sino responder directamente que los datos son insuficientes. Después de esto, la respuesta se formatea a un formato estándar y se publica en Critique, el sistema interno de revisión de código de Google, donde el desarrollador inmediatamente ve la conclusión, los pasos de investigación y las líneas de registro más relevantes.

Por los números, el sistema parece no un prototipo de laboratorio, sino una herramienta interna realmente probada. En la verificación manual en 71 fallos reales de 39 equipos, Auto-Diagnose identificó correctamente la causa raíz en 64 casos, una precisión del 90,14%. Después de esto, Google lo lanzó a todos los fallos de integración en cambios de código en toda la empresa, comenzando en mayo de 2025.

Durante este tiempo, el sistema operó en 52.635 pruebas únicas, 224.782 ejecuciones, 91.

130 cambios de código y 22.962 autores. El tiempo medio para publicar un diagnóstico en la revisión de código fue de 56 segundos, y el percentil 90 fue de 346 segundos, lo que significa que el resultado generalmente aparece antes de que el ingeniero se cambie completamente a otra tarea.

En promedio, una ejecución consume 110.617 tokens de entrada y genera 5.962 tokens de salida.

La retroalimentación también se ve bien: de 517 reseñas de 437 desarrolladores, la proporción de marcas "No útil" fue del 5,8%, por debajo del umbral interno de Google del 10% para tales herramientas, y en términos de utilidad, Auto-Diagnose se ubicó en el lugar 14 de 370 sistemas que publican hallazgos en Critique. También hay un beneficio secundario importante. Siete errores de la evaluación manual resultaron ser no una falla del modelo en sí, sino problemas con la infraestructura de registro: en algunos casos, los registros del controlador de prueba no se guardaron después de un fallo, en otros, faltaban los registros del componente que falló.

Respuestas similares en el espíritu de "necesitamos más datos" más tarde ayudaron a identificar alrededor de 20 problemas de infraestructura adicionales. Por lo tanto, el significado principal de Auto-Diagnose no es solo que Google está acelerando la investigación de fallos de prueba. La empresa está demostrando un patrón más práctico para usar LLMs en el desarrollo: no pedir al modelo que corrija código a ciegas, sino integrarlo en un punto estrecho del proceso, dándole reglas estrictas para rechazar especulación y devolviendo resultados directamente a donde el ingeniero ya está trabajando.

Para equipos grandes, este es tal vez un escenario más valioso que otro "asistente de codificación AI", porque reduce el tiempo para entender la causa del fallo, y eso es precisamente lo que más frecuentemente retrasa el lanzamiento.