La cifra de la que sale todo lo demás
Hay una medición que hace exactamente lo que habría que hacer en estos casos: en vez de ejecutar tests, compara el comportamiento del código original y el transformado con miles de entradas aleatorias. Entre mil y dos mil entradas por programa, como caja negra, con seis modelos distintos.
| Qué se midió | Valor |
|---|---|
| Refactorización funcionalmente incorrecta | 18,6–35 % |
| De eso, en tareas más fáciles | 22,1 % |
| En tareas más difíciles | 32,1 % |
| El mejor modelo | 18,6 % |
| El peor | ~35 % |
| De las refactorizaciones incorrectas, pasaron todos los tests existentes | 21,65 % |
La última fila es lo importante. El problema no es que el modelo se equivoque, sino que más de una quinta parte de sus errores no los atrapa la batería de tests existente.
Calculemos qué significa eso:
refactorización no equivalente: 22,1 %
lo que la batería de tests NO atrapa: 21,65 %
cambia el comportamiento en silencio Y está verde:
0,221 × 0,2165 = 0,0478 -> ~4,8 %
en tareas más difíciles:
0,321 × 0,2165 = 0,0695 -> ~7,0 %
(Cálculo propio; las dos cifras de partida están publicadas. La medición es un preprint.)
Una de cada veinte transformaciones hace en silencio algo distinto de lo que hacía antes. Es el tipo de fallo que no revienta, sino que da un número equivocado — y que sale a la luz semanas después.
La tendencia mejora, pero no llega a cero
También hay un estudio revisado por pares y con muestra mayor: 8.096 versiones refactorizadas a partir de más de mil fragmentos de Java y Python, con cuatro modelos.
El resultado: 928 fragmentos refactorizados mostraron diferencias de comportamiento, 180 de ellos con fallo total. La tendencia, eso sí, es alentadora: con los modelos de 2023 la proporción rondaba el 17 %, con los de 2025 es del 6,06 %.
Y existe además una estrategia de mitigación medida que bajó la proporción de diferencias del 17,17 % al 4,71 % — más de doce puntos porcentuales de mejora.
Seis por ciento es, pues, el punto de partida de hoy. Mejora, pero está lejos de cero — y hablamos justo del tipo de fallo que el usuario no nota, solo la contabilidad.
¿A partir de qué tamaño de diff se estropea?
Para esta pregunta no hay una medición continua — quien te dé un número de umbral se lo está inventando. Sí hay dos puntos bien definidos, y la diferencia entre ambos es elocuente.
- En arreglos pequeños, típicamente de un solo fichero, los mejores sistemas rondan una tasa de resolución del 74 %.
- En diffs grandes — donde un tercio de las tareas toca más de diez ficheros y un tercio cambia más de doscientas líneas — esos mismos modelos llegan al 41,2 %. Los arreglos de referencia de ahí tocan de media 11,4 ficheros y 261,6 líneas; el caso más complejo, 182 ficheros.
Los mismos modelos, más o menos la mitad del resultado.
Lo confirma también un baremo construido expresamente para refactorización: 1.099 transformaciones conservadoras del comportamiento escritas por desarrolladores en dieciocho proyectos Java, separadas en casos atómicos y compuestos. El mejor modelo llegó al 41,6 %, los open-weight se quedaron por debajo del 2 %, y un agent alcanzó apenas el 39,4 % en las transformaciones compuestas. El resumen de los autores: los modelos actuales «siguen siendo eficaces en las ediciones locales y atómicas, pero rinden mal en las transformaciones entre ficheros y compuestas».
El verdadero cuello de botella: encontrar
Aquí hay una distinción pequeña pero importante que deshace muchos malentendidos.
En la medición de un fabricante de herramientas, en una transformación que afectaba a siete ficheros el agent básico modificó dos ficheros. La misma tarea con navegación por símbolos: los siete.
El límite, por tanto, no es la edición, sino el hallazgo. El agent transforma lo que ve — y una parte de los puntos de llamada no los ve. Una refactorización que arregla cinco sitios y deja dos sin tocar es peor que no haberla hecho. Dónde está ese límite lo sitúa el post entender código heredado , con las cifras.
Por qué esto importa justo ahora
Según un estudio que analizó 623 millones de cambios de código entre 2022 y 2026, la refactorización como práctica va en caída libre:
| Indicador | Cambio |
|---|---|
| Código «movido» — el proxy de la refactorización | 21 % (2022) → 3,8 % (2026) |
| Copy/paste entre las líneas modificadas | 9,4 % → 15,7 % |
| Duplicación de bloques | +81 % desde 2023 |
| Acoplamiento entre funciones | −35 % |
| Mantenimiento de código antiguo | −74 % |
| Estructuras que ocultan errores | +47 % |
El resumen de la empresa: hoy los desarrolladores tienen más o menos cuatro veces más probabilidades de copiar que de mover.
(Datos de una empresa comercial de análisis de código, sin revisión por pares; el «código movido» es una heurística, no una medición directa. El tamaño de la muestra y la dirección consistente de la tendencia en varios indicadores sí son serios.)
La lección no es que la IA no sepa refactorizar. Es que escribir algo nuevo parece más barato — y por eso la reordenación no llega nunca. La factura de la duplicación, en cambio, la va a pagar alguien.
El orden de las comprobaciones
Este es el núcleo práctico del post. Seis pasos, y detrás de cada uno están los datos de arriba.
1. PRIMERO EL CHARACTERIZATION TEST.
Un test que no fija LO QUE DEBERÍA HABER, sino LO QUE
HAY. La refactorización es, por definición, conservadora
del comportamiento - o sea, hay que dejar clavado el
comportamiento actual antes de tocar nada.
2. COMPILACIÓN + BATERÍA COMPLETA DE TESTS.
Necesario, pero NO suficiente: deja pasar
el ~21,65 % de las refactorizaciones incorrectas.
3. COMPROBACIÓN A NIVEL DE AST: ¿ocurrió la transformación pedida?
Hay herramientas; en Java identifica qué refactorización
se hizo con un 99 % de precisión y un 94 % de exhaustividad.
Esto es lo que pilla al modelo "mejorando también un poco".
4. MUTATION TESTING.
En refactorización esta señal SÍ tiene sentido - porque puedes
suponer bueno el código de partida. (Depurando, no.)
5. DIFFERENTIAL TESTING / FUZZING.
Mil o dos mil entradas, código viejo y nuevo en paralelo.
Esto es lo que pilla ese ~5 % que los tests no ven.
6. DIFF PEQUEÑO.
No hay umbral concreto. Lo que sabemos: pasados 10 ficheros
y 200 líneas, la tasa de éxito baja del 74 % al 41 %.
En el primer punto hay una conexión bonita que conviene decir en voz alta. Es un fenómeno conocido que, si metes el código existente en el prompt, el modelo escribe la aserción sobre el comportamiento actual — al depurar eso es una catástrofe, porque consolida el fallo. En un characterization test, en cambio, es exactamente lo que quieres. La misma tendencia, con el signo cambiado. Por el lado de la depuración lo desarrolla el post depurar con IA , paso a paso, y por el lado de los tests, el post la red de seguridad de los tests lo continúa.
Malentendidos típicos
- «Los tests están en verde, luego el comportamiento no ha cambiado.» Más de una quinta parte de las refactorizaciones incorrectas pasa la batería de tests existente.
- «Los modelos de hoy ya saben hacer esto.» La proporción de diferencias de comportamiento cayó del 17 % al 6 % en tres años. Seis por ciento no es cero.
- «Se estropea por encima de quinientas líneas.» Para ese umbral no hay datos. Hay dos puntos medidos: ~74 % en arreglos pequeños de un fichero, 41 % por encima de diez ficheros y doscientas líneas.
- «El agent no sabe renombrar en todas partes.» Sabe — si lo encuentra. El límite documentado es el hallazgo, no la edición.
- «Ya saldrá en el code review.» El cambio silencioso de comportamiento es justo lo que no se ve en un diff . Para eso hay que ejecutarlo.
Lo que conviene llevarse
En la refactorización el riesgo no está en el prompt, sino en el orden de las comprobaciones. Primero deja fijado cuál es el comportamiento actual, después deja al modelo entrar — y ten presente que la batería completa de tests, por sí sola, deja pasar una quinta parte de los fallos. Lo que merece la pena añadir encima: una comprobación estructural de que ocurrió de verdad la transformación pedida, y una ejecución diferencial que atrape ese pequeño porcentaje que no atrapa nada más.
Los pasos de la revisión humana del cambio terminado los recorre de principio a fin el post revisar código escrito por IA , con su lista.