La mentira de "reescribilo de cero con IA"

"When you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time." (Joel Spolsky, abril 2000, "Things You Should Never Do, Part I")

Lo escribió Joel Spolsky hace más de dos décadas. Hoy, con modelos de lenguaje que te escupen cinco mil líneas de código funcional en un par de horas, la trampa de tirar todo y empezar de cero es mil veces más seductora. Parece un atajo. En la práctica, suele ser un suicidio financiero.

El cementerio de las reescrituras mágicas

Spolsky usaba el caso histórico de Netscape. Los desarrolladores decidieron que el código de la versión 4 era un desastre inmanejable, lo tiraron a la basura y decidieron reescribir la versión 6 desde cero. Les tomó tres años de demoras. En ese hueco de tiempo, perdieron el mercado a manos de Internet Explorer y nunca se recuperaron.

Hoy veo founders que cometen exactamente el mismo error estructural, pero armados con Cursor o Claude Code. Me cruzo todas las semanas con equipos que le piden a la IA "reescribime todo este backend viejo en Next.js 16" porque el código legacy les parece feo, o porque quieren usar el framework de moda. Cuatro semanas después abandonan el proyecto con un sistema medio roto, estancado en un limbo donde lo viejo ya no se mantiene y lo nuevo no termina de compilar.

Peor aún, delegar reescrituras masivas a agentes autónomos tiene costos reales catastróficos. En julio de 2025, durante un intento de "rewrite" automático, un agente de Replit terminó borrando las bases de datos de 1206 ejecutivos. La IA te da velocidad supersónica para generar texto, pero ignora olímpicamente por qué esa línea espantosa de código estaba ahí en primer lugar.

El patrón de la higuera estranguladora

En lugar de tirar todo a la basura y pausar tu negocio, la ingeniería real resuelve la deuda técnica con estrategia progresiva. Martin Fowler popularizó esto como el Strangler Fig Pattern (el patrón de la higuera estranguladora).

La premisa es simple: la higuera estranguladora crece alrededor de un árbol viejo. En software, significa que en lugar de apagar el sistema legacy, empezás a construir los módulos nuevos a su alrededor. El código nuevo va "estrangulando" e interceptando las llamadas del código viejo, módulo por módulo, hasta que el legacy desaparece por completo. No hay migraciones suicidas, no hay big bangs de despliegue, y lo más importante: no dejás de entregar valor a los usuarios.

Siete años modernizando un sistema en vivo

En FirmaLaboral aplicamos esta disciplina a rajatabla. Tenemos más de 400 PyMEs corriendo operaciones críticas de recursos humanos todos los días. El stack histórico arrancó con AngularJS 1.5, Node 7 y Mongoose 3.6.

Durante siete años de desarrollo, migramos progresivamente todo el frontend a Angular 17 (y luego 21). Pasamos el backend a Node 22, actualizamos a Mongoose 8 y pasamos a una arquitectura de microservicios empaquetada en Docker, corriendo sobre DigitalOcean y operando pagos con Mercado Pago.

Nunca reescribimos el sistema desde cero.

Cada módulo nuevo que el negocio pedía, se hacía con código nuevo. Cada módulo viejo se modernizaba cuando hacía falta tocarlo, o se reemplazaba quirúrgicamente. Logramos hacer toda esta transición tecnológica masiva con cero downtime grande, mientras las 400 empresas seguían liquidando sueldos y fichando. La plata sigue entrando mientras el sistema evoluciona.

Cuándo refactorizar y cuándo reescribir

NO te digo "nunca reescribas". Te digo: el rewrite con criterio técnico es raro. El rewrite por aburrimiento es lo común.

Si tenés un MVP armado con Lovable, Supabase y Stripe, ya tenés clientes pagando, y estás dudando si tirar todo porque el código generado es un desastre inmanejable, frená un segundo. Esta matriz de decisión, basada en los criterios de Martin Fowler (2024), separa la ingeniería del capricho:

Factor	Strangler Fig (Refactor)	Rewrite (Reescribir de cero)
Líneas de código (LOC) del sistema	> 10K	< 5K
Edad del código	> 1 año en producción con usuarios	< 6 meses, sin usuarios pagando
Cobertura de tests	Alguna (> 30%)	Cero (entonces ya es rewrite de facto)
Visión objetivo	Borrosa o "lo mismo pero estable"	Clara y muy diferente
Negocio puede pausar features 2-3 meses	No	Sí (raro)
Default para vibe-coded MVP con users pagando	Sí (refactor)	Casi nunca

Llevo casi 40 años escribiendo y manteniendo sistemas. La realidad de la calle es que el código feo que está en producción, con todos sus parches y condicionales que no te gustan, tiene años de casos borde resueltos incrustados en su lógica. Cuando le pedís a un LLM que lo reescriba de cero para que quede más prolijo, estás borrando de un plumazo todo ese conocimiento del mundo real. La IA te hace creer que empezar de nuevo es gratis. En sistemas serios, empezar de cero es pagar por los mismos errores dos veces.