Refactor asistido por IA: cuándo confiar y cuándo verificar manualmente

Si ya usás un LLM para refactorizar código, sabés que a veces el resultado es impresionante y a veces es una catástrofe silenciosa. El problema no es la IA: es saber en qué tipos de cambios confiarle el volante y en cuáles tenés que ir con las manos en el tablero.

Este post no es teoría. Es el mapa que uso para no romper producción.

Los refactors donde la IA es genuinamente buena

1. Renombrar con consistencia global

Renombrar una variable, función o clase en 40 archivos es exactamente el tipo de tarea mecánica donde los LLMs brillan. El riesgo de error humano (olvidarse un archivo, capitalización inconsistente) es mayor que el riesgo de que la IA meta la pata.

Cuándo confiar: el símbolo aparece muchas veces, el nombre nuevo es claro, los tests siguen pasando después del cambio.

Cuándo verificar igual: si el nombre nuevo colisiona con algo del framework o librería, o si hay reflexión/strings dinámicos que buscan el nombre antiguo.

2. Extracción de métodos y funciones helper

"Tomá este bloque de 80 líneas y convertilo en 3 funciones con nombres descriptivos" es un prompt que funciona muy bien. La IA es buena identificando responsabilidades, nombrando y reorganizando sin cambiar la lógica.

Cuándo confiar: el bloque original es lineal, no tiene side effects complejos, los inputs y outputs son claros.

Cuándo verificar: si el bloque modifica estado global, tiene early returns importantes, o hay closures con variables capturadas del scope exterior.

3. Reorganizar imports y limpiar dependencias no usadas

Eliminar imports muertos, ordenar por convención, separar los de terceros de los internos. Tarea perfecta para un LLM: baja semántica, alta consistencia.

Cuándo confiar: siempre, con un lint/compile check al final.

4. Convertir patrones repetitivos

Cambiar callbacks a async/await en 20 funciones, migrar var a const/let, convertir clases a hooks en React, unificar manejo de errores. El LLM puede hacer esto en lote con muy baja tasa de error si el patrón es consistente.

Cuándo confiar: el patrón es uniforme y el cambio es sintáctico más que semántico.

Cuándo verificar: si hay casos especiales mezclados (un callback que captura this de una manera particular, por ejemplo).

Los refactors donde la IA es peligrosa

1. Cambios de control flow

Cualquier cosa que modifique el orden de ejecución, las condiciones de un if, o la lógica de bucles es terreno minado. La IA puede producir código que parece equivalente pero tiene comportamiento diferente en edge cases.

Ejemplo clásico: invertir una condición para simplificarla. if (!isValid) return error vs if (isValid) { ... } else { return error } parece lo mismo, pero en contextos de short-circuit evaluation o con side effects en isValid, puede no serlo.

Regla: cualquier cambio de control flow necesita tests antes y después, y diff manual línea por línea.

2. Optimización de queries y acceso a datos

"Optimizá esta query" es uno de los prompts más peligrosos que existen. El LLM puede producir una query que devuelve los mismos resultados en el dataset de prueba y resultados distintos en producción con datos reales.

Los problemas típicos: cambiar LEFT JOIN por INNER JOIN silenciosamente, eliminar una condición de filtro que parece redundante pero no lo es, reordenar operaciones que cambian el resultado con NULLs.

Regla: nunca aceptar optimizaciones de queries sin ejecutarlas contra datos reales y comparar los result sets, no solo el plan de ejecución.

3. Modificación de side effects

Si el código tiene efectos secundarios — llamadas a APIs externas, escritura a archivos, envío de emails, actualización de caché — el LLM puede reorganizarlo de manera que los side effects ocurran en un orden diferente o en condiciones distintas.

Regla: cuando hay side effects, leer el diff con el foco puesto específicamente en cuándo y bajo qué condición ocurre cada efecto. La IA no siempre entiende la intención original.

4. Cambios "de paso" no pedidos

El LLM tiene tendencia a "mejorar" cosas que no le pediste. Estás extrayendo una función y de repente aparecen 3 variables renombradas y un early return que no existía. Cada cambio no pedido es un vector de riesgo.

Regla: si el diff contiene más cambios de los que esperabas, preguntá o revertí lo extra antes de mergear.

La red de seguridad que no podés saltear

Tests antes del refactor, no después

Si no tenés tests cubriendo el comportamiento que vas a cambiar, el refactor asistido por IA es un experimento ciego. Los tests no son para el proceso de revisión: son para que vos sepas que el comportamiento original está capturado.

Si no existen, escribilos primero. Sí, antes de refactorizar. Es el costo de entrada para operar con seguridad.

El diff es tu herramienta más importante

Aceptar un PR de IA sin leer el diff línea por línea es lo mismo que mergear código de un desarrollador sin revisarlo. El LLM no tiene contexto de tu sistema — vos sí.

Lecturas rápidas del diff son una trampa: el cerebro tiende a asumir que si "se ve bien" está bien. Leé con intención de encontrar el error.

Cambios atómicos, no en lote

Un refactor asistido por IA debería ser un commit por tipo de cambio: primero el rename, luego la extracción, luego la limpieza de imports. Si algo falla en CI o en runtime, sabés exactamente qué cambio fue.

Un commit de "refactor general asistido por IA" que toca 30 archivos con cambios mezclados es un regalo para la arqueología de bugs futuros.

El flujo que funciona

1. Identificar el tipo de refactor — ¿Es mecánico y uniforme? ¿O toca lógica y control flow?
2. Escribir los tests si no existen — mínimos, pero representativos del comportamiento clave.
3. Hacer el prompt específico — cuanto más acotado el scope, mejor el resultado.
4. Leer el diff con intención — no buscar que esté "bien", buscar activamente el error.
5. Ejecutar tests — si algo falla, no parches el test: entendé por qué falló.
6. Commit atómico — un tipo de cambio por commit.
7. No aceptar extras — si el LLM tocó algo que no pediste, sacalo del commit o pedile que lo revierta.

Conclusión

La IA como asistente de refactor es una herramienta real, no un hype. Pero como cualquier herramienta, el resultado depende de saber cuándo usarla. Usarla bien requiere entender sus puntos ciegos: la IA optimiza para código que parece correcto, no para código que se comporta correctamente en todos los casos posibles.

El criterio más útil que encontré: si no entendés exactamente qué cambió y por qué, no está listo para producción.