Refactorizar legacy con IA: por qué falla 80% del tiempo
El codebase de 15 años no es lo que la IA entrena. Tres patterns donde sí funciona y siete donde te quema.
Una promesa común en ventas de AI coding: “vamos a modernizar tu legacy en semanas, no años”. Demos impresionantes en repos greenfield, slides de Stripe y Shopify, números 10x. El CTO firma.
Tres meses después, la realidad: el agente generó 40,000 líneas de “refactor” en el sistema bancario de 15 años, el QA encontró bugs raros en producción que no estaban antes, y nadie en el equipo entiende exactamente qué cambió. Reversión cara.
¿Por qué falla? No es porque la IA sea mala. Es porque el legacy real no es lo que la IA entrena.
Lo que la IA entrena
Los modelos top de 2026 se entrenaron principalmente con:
- Open source moderno (último 5-7 años)
- Stacks populares: React, FastAPI, Django, Rails, Spring Boot
- Patterns documentados online (StackOverflow, blog posts)
- Repos con tests, CI, naming consistente
Tu legacy real probablemente es:
- 12-20 años de edad
- Stack que combina 3 generaciones (jQuery + Angular 1 + React 14)
- Patterns inventados por el ex-arquitecto que se fue en 2018
- Tests escasos, naming inconsistente, magic numbers
- Lógica de negocio crítica enredada con boilerplate UI
El delta entre el modelo y tu codebase real es lo que produce el 80% de fallos.
Tres patterns donde SÍ funciona
1. Migración de framework con tests sólidos. Tienes Angular 12, quieres React 19. Tests E2E que validan el comportamiento user-visible. El agente refactoriza componente por componente, los tests validan que no rompiste nada. Funciona — porque el agente tiene contracts claros que respetar.
2. Lift-and-shift de funciones puras. Funciones sin side effects, sin dependencias raras, bien tipadas. El agente las mueve a TypeScript, las moderniza, ajusta imports. Bajo riesgo, alto retorno.
3. Eliminación de código muerto. “Estos 200 endpoints no se llaman desde 2021” — el agente verifica, los marca, los elimina con confidence. Excelente caso de uso, especialmente en monorepos viejos.
Siete patterns donde te quema
1. Refactor de lógica de negocio crítica. El agente no entiende los edge cases que el ex-arquitecto codificó en silencio. Cambias el código, pasa los tests (que no cubrían el edge case), rompe en producción.
2. Migración de DB con datos legacy. El agente asume schemas
limpios. Tu tabla users tiene tres columnas con el mismo email
en diferentes formatos por bugs históricos. El agente normaliza —
y rompe joins en otras 14 tablas.
3. Reescritura de queries SQL viejos. Esa query de 200 líneas con CTEs anidados está como está porque optimizaste para el query planner específico de tu Postgres 9.6. El agente la “refactoriza” y tarda 30x más en producción.
4. Cambio de framework con tests débiles. Sin contratos, el agente improvisa. Los tests pasan porque cubrían 30% del comportamiento. El 70% restante se rompe silenciosamente.
5. Limpieza de “código feo”. El feo a veces tiene razón. Esa función de 400 líneas con 18 if-else hace exactamente lo que el regulador pidió en 2019. El agente la “limpia” y omite un caso.
6. Modernización de auth. Sistemas de auth legacy tienen parches de seguridad históricos. El agente los reemplaza con la “versión moderna” — y rompe un patch que cerraba un CVE específico de tu app.
7. Refactor cross-team sin coordinación. El agente toca código de tres equipos a la vez. Ningún equipo revisa lo que tocó del otro. Slop ×3.
Cómo hacerlo bien cuando es necesario
Lo que vemos funcionar en clientes con legacy real:
- Empezar por characterization tests: ANTES de tocar nada, pedir al agente escribir tests que capturen el comportamiento actual (incluyendo los edge cases raros). Esos son tu contrato.
- Refactor incremental, no big-bang: módulo por módulo, con feature flags para reversibilidad.
- Pareo humano-agente: senior que conoce el código histórico
- agente. El humano hace memoria, el agente hace volume.
- Métricas de regresión obligatorias: latencia, error rate, business KPIs antes y después de cada deploy.
- Reversión designed-in: cada migración tiene plan de rollback documentado y testeado.
La pregunta para tu equipo
¿Tu plan de modernización con IA pasa por el escenario “el código está mal, refactor automático”, o pasa por “el código encapsula 15 años de aprendizajes que nadie documentó”?
Si es el primero, vas a quemar producción. Si es el segundo, necesitas un equipo distinto al que está vendiendo el proyecto.
Si están planeando modernización de legacy con IA y quieren discutir dónde tiene sentido y dónde no, conversemos — el chat está abierto.