Suelte un modelo de lenguaje sobre código que ya funciona y, con cierta regularidad, lo romperá. Un nuevo informe publicado en arXiv le pone aritmética a esa intuición: en una de las configuraciones probadas, un bucle de reparación automática dañó programas correctos alrededor del 26% de las veces, mientras que reparó los realmente defectuosos en torno al 2,3% — una proporción de más de diez a uno en la dirección equivocada.
Claves
- Medido sobre envíos de programación competitiva, un bucle de reparación con LLM dañó código funcional a una tasa de 0,261 y solo corrigió código defectuoso a una tasa de 0,023.
- Dejados iterar, los modelos cayeron en ciclos de pseudocorrección: añadían y quitaban la misma edición indefinidamente, y las ediciones por búsqueda y reemplazo generaron más ciclos que la reescritura de archivos completos.
- El sondeo halló una dirección interna que predice la propensión a editar con separación casi perfecta hacia la capa 19; suprimirla detuvo por completo el bucle destructivo, y también todas las reparaciones reales.
La medición
El artículo If It's Not Buggy, Don't Fix It, firmado por Xietao Wang-Lin, Anton Isopoussu y Louis Mahon, examina lo que los autores llaman uso iterativo ciego: entregar un programa al modelo, aceptar la edición que devuelva y repetir. Es una descripción bastante fiel de cómo un número creciente de equipos conecta los bots de reparación a la revisión de código.
El banco de pruebas fue CodeContests+ — 20 problemas, 40 envíos en C++ por problema y una media de 23 casos de prueba — ejecutado contra Gemini 2.5 Flash-Lite de Google y Qwen2.5-7B-Instruct de Alibaba. Con decodificación voraz y edición por búsqueda y reemplazo, la tasa de reparación de Gemini fue de 0,023 ± 0,002 frente a una tasa de daño de 0,261 ± 0,032; una segunda configuración situó el daño en 0,293 ± 0,011. El resumen de los autores no da rodeos: la tasa de daño puede terminar siendo muy superior a la de reparación.
Dos salvedades acompañan a esas cifras. Los modelos evaluados son pequeños y rápidos, no sistemas de frontera, y los envíos de programación competitiva no son una base de código en producción con su propia batería de pruebas, sus filtros de revisión y su integración continua. El benchmark mide un bucle sin condición de parada y sin nadie supervisándolo, que es justamente el punto, pero no equivale a medir una canalización de reparación bien instrumentada.
El bucle que no se asienta
El hallazgo más inquietante aparece cuando se deja correr el proceso. En lugar de converger hacia una versión estable, los modelos entraban con frecuencia en lo que el artículo llama ciclo de pseudocorrección: el mismo cambio se introduce, se elimina y se vuelve a introducir, con el programa oscilando entre estados que pasan y que fallan. Los bloques de búsqueda y reemplazo produjeron bastantes más ciclos, y más largos, que las ediciones de archivo completo.
Esto importa en la operación diaria porque un agente que cicla parece ocupado. Genera diffs, reporta actividad, consume tokens; y, sin un oráculo de pruebas conectado al bucle, nada en su salida indica que está oscilando en vez de avanzar.
Una dirección interna para "esto parece defectuoso"
La sección mecanicista es donde el trabajo se vuelve realmente interesante. Sondeando las activaciones del modelo, los autores construyeron un vector de dirección que sigue la propensión a editar, con una separación que sube desde un AUC de 0,7–0,8 en las capas iniciales hasta cerca de 1,0 alrededor de la capa 19. La implicación es que el modelo alberga una representación interna de "código con errores" y que esa representación se dispara en falso sobre programas que están perfectamente bien: una alucinación con dirección concreta dentro de la red.
Dirigir el modelo en contra de ese vector con γ = -0,5 apagó por completo el bucle destructivo y preservó todos los envíos correctos. También dejó de arreglar cualquier cosa. Más que una perilla lista para desplegar, es una demostración limpia de que la disposición a editar y la capacidad de reparar están, en estos modelos, enredadas: no se pueden bajar los falsos positivos y conservar los verdaderos.
Qué cambia para los equipos que operan bots de reparación
La lectura práctica no es que la reparación automática sea inútil, sino que la condición de parada es el producto. Una herramienta de reparación sin un oráculo fiable para determinar que "aquí no hay nada que arreglar" gastará la mayoría de sus ediciones en código que no las necesitaba, y la aritmética anterior sugiere que esas ediciones salen en negativo.
También refuerza una tendencia arquitectónica ya visible en productos en circulación. Los patrones de revisar y corregir que colocan a un crítico independiente entre el borrador y el árbol de trabajo — incluido el paso de crítica entre familias de modelos en la nueva capa de orquestación que GitHub presentó en vista previa, y que cubrimos en nuestro informe sobre Project HydraFusion — existen precisamente para interrumpir el bucle ciego que este trabajo mide. La iteración acotada, los revisores sin herramientas y la aplicación de parches a prueba de fallos dejan de ser decisiones conservadoras cuando el daño supera a la reparación por un orden de magnitud.
Perspectiva
Si estas proporciones se mantienen con modelos de frontera sobre repositorios reales es la continuación evidente, y nada aquí lo resuelve. Lo que el informe sí establece es que el modo de fallo es estructural y no accidental: la propensión a editar está representada internamente, se activa sobre código sano y la iteración la amplifica en lugar de diluirla. Quien esté construyendo reparación totalmente autónoma haría bien en diseñar contando con eso, en vez de esperar a que el próximo modelo lo haga desaparecer.
Preguntas frecuentes
¿Qué modelos se probaron en el estudio?
Gemini 2.5 Flash-Lite y Qwen2.5-7B-Instruct. Ambos son modelos pequeños y económicos, no sistemas de frontera, de modo que las tasas reportadas no deben leerse como una medición de lo que hacen los mayores modelos de programación.
¿Significa esto que las herramientas de revisión de código con IA empeoran el código?
Por sí solo, no. El estudio mide iteración ciega sin condición de parada ni revisión humana, que es el peor caso y no el despliegue habitual. Su relevancia crece en proporción a cuánta autonomía se le concede a la herramienta de reparación.
¿Se puede desactivar sin más la detección errónea de errores?
No de forma limpia. Los autores hallaron un vector de dirección que elimina el bucle de edición destructiva, pero aplicarlo eliminó también todas las reparaciones exitosas, lo que sugiere que la misma representación interna impulsa ambos comportamientos.
