Reducción de costes y prevención de alucinaciones en agentes múltiples aprendidas del sistema uReview de Uber
Cómo filtrar fragmentos de código innecesarios antes de llamar al LLM mediante análisis AST
Al introducir un diff de Git sin procesar y el código fuente completo en un monolito heredado, se genera una explosión de costes. La plataforma uReview, publicada por Uber en 2025, analizó automáticamente el 90 por ciento de los 65.000 cambios generados cada semana en seis monorepos. Sin embargo, si se expone el modelo sin refinar a bases de código con límites de módulos poco claros, los costes de tokens se multiplican por seis. Un modelo que no comprende las clases factoriales globales provoca alucinaciones exigiendo validaciones de punteros nulos erróneas. En el momento en que se acumulan comentarios inútiles, los desarrolladores desactivan las notificaciones y caen en la insensibilidad a las alertas.
Es necesario crear un motor de preprocesamiento utilizando el módulo estándar ast de Python para extraer únicamente las firmas de funciones modificadas y las variables locales afectadas. Tras refinar los metadatos estáticos, se eliminan mediante comparación de hashes las modificaciones no funcionales ajenas a los cambios. A continuación, se realiza una reinversión de la firma del nodo de función más bajo que contiene la línea modificada y la sentencia de modificación real para crear una carga útil JSON ligera.
Al ejecutar una prueba de rendimiento con 100 módulos heredados, la diferencia es evidente. La inyección de archivos sin procesar consume 42.000 tokens y 0,273 dólares por PR. En cambio, utilizando la compresión JSON con preprocesamiento AST, se reduce a 6.100 tokens y 0,068 dólares por PR. Los costes de API se reducen en un 47,3 por ciento y la tasa de falsos positivos por alucinaciones baja al 9,4 por ciento.
Cómo cortar bucles infinitos entre agentes mediante un esquema de máquina de estados
Agrupar un agente de seguridad y un agente de lógica de negocio en un chat grupal interactivo hace que devuelvan salidas mutuamente y caigan en un bucle de ping-pong infinito. El análisis de una sola PR lleva decenas de minutos y los costes de API se disparan. No se debe permitir que los agentes se comuniquen directamente entre sí. Es necesario construir un marco de máquina de estados finitos utilizando esquemas de Pydantic y LangGraph.
Cada agente especializado recibe únicamente el estado central del canal y devuelve el resultado de su juicio según sus reglas de dominio únicamente en el formato de modelo establecido. Se definen clases de datos mediante Pydantic que fuerzan el identificador, la ruta del archivo, la gravedad y la puntuación de confianza de la salida del agente. Se establecen aristas condicionales para interrumpir forzosamente la máquina de estados cuando el recuento de iteraciones alcanza 2 o la confianza de todos los comentarios converge por encima de 0,85.
De acuerdo con el estándar de convenciones semánticas de OpenTelemetry GenAI, la ejecución de cada agente debe envolverse en un span único y el uso de tokens debe registrarse en un backend de tracing distribuido. Aplicar esta estructura reduce el tiempo de depuración que el tech lead perdía intentando solucionar fallos de los agentes en más de 6 horas semanales.
Cómo lograr una tasa de aceptación del 70 por ciento por parte de los desarrolladores mediante un script de validación de lista blanca
Según los datos operativos de Tricorder, la herramienta de análisis estático interna de Google, por muy precisa que sea la indicación de la herramienta, si los desarrolladores sienten que no vale la pena corregirlo, la animadversión aumenta. Un comprobador con una tasa de falsos positivos útil superior al 5 por ciento es retirado de inmediato. Para lograr que se acepte más del 67 por ciento de los comentarios de revisión automática, es necesario realizar un despliegue gradual que comience por los módulos de menor riesgo.
Se ejecuta durante tres semanas un modo sombra que oculta los comentarios seleccionando capas de validación DTO y capas sin efectos secundarios como las funciones puras. Tras verificar una precisión del 85 por ciento, se despliegan comentarios en línea en el código de backend de tres escuadras de dominio y se realiza un seguimiento de la tasa de aceptación. Recopilando registros de retroalimentación semanalmente, se ejecuta un script de bucle de retroalimentación que elimina automáticamente de la lista blanca las reglas de falsos positivos elevados con una tasa de aceptación inferior al 67 por ciento y las envía a una lista de aislamiento. Al incrustar este script de validación de lista blanca en la tubería, las reglas inútiles que molestan a los desarrolladores se filtran rápidamente, permitiendo alcanzar una tasa de aceptación del sistema de revisión del 70 por ciento dentro del equipo.