Simon Willison advierte contra reescribir sistemas con deuda técnica desde cero
El desarrollador Simon Willison publicó el 6 de septiembre de 2026 un análisis detallado sobre por qué los proyectos de reescritura total de sistemas raramente funcionan y propone refactorizaciones dirigidas como alternativa más viable.
👁 113 lecturas
El desarrollador Simon Willison publicó el 6 de septiembre de 2026 un comentario en Lobsters argumentando que las reescrituras totales de sistemas con deuda técnica fallan casi siempre, y proponiendo una alternativa más pragmática basada en refactorizaciones incrementales.
- Willison describe un patrón recurrente: al anunciar una reescritura, el sistema viejo sigue en producción como 'blanco móvil' mientras el nuevo acumula código inactivo.
- El resultado habitual es terminar con dos sistemas en producción en lugar de uno, con el riesgo añadido de que las prioridades cambien y el proyecto nuevo quede abandonado.
- Su recomendación concreta es reforzar el sistema existente con pruebas automatizadas y aplicar refactorizaciones dirigidas, citando el artículo 'Migrations: the sole scalable fix to tech debt' de Will Larson.
El análisis identifica un ciclo predecible: se anuncia que el sistema antiguo es irrecuperable, se forma un equipo para reemplazarlo desde cero y el trabajo arranca con buen ritmo porque el entorno es nuevo. Sin embargo, el sistema original sigue ejecutando el negocio principal y requiere cambios continuos, mientras que sus desarrolladores - conscientes de que será reemplazado - aplican el mínimo esfuerzo posible. La deuda técnica sigue acumulándose.
Al mismo tiempo, el equipo del sistema nuevo descubre progresivamente que nadie comprende del todo el alcance y comportamiento de lo que debe reemplazar. Tras meses o incluso años sin entregar valor, la presión obliga a lanzar el nuevo sistema de forma parcial, normalmente para cubrir solo un subconjunto de funciones o para alguna característica nueva que era difícil de construir en el sistema viejo.
«Ahora tienes DOS sistemas en producción: el viejo y destartalado que nadie quiere tocar, y un sistema nuevo que maneja solo unas pocas funciones y tiene un 80% de código inactivo destinado a reemplazar al antiguo, en algún momento.»
Willison recomienda el artículo «Migrations: the sole scalable fix to tech debt» de Will Larson como la mejor guía disponible para completar este proceso de forma responsable. Su prescripción práctica es añadir la mayor cantidad posible de pruebas automatizadas al sistema existente y evaluar si refactorizaciones dirigidas pueden llevarlo a la forma deseada.
Para quienes construyen con herramientas de IA: los asistentes de código generan con facilidad arquitecturas nuevas y completas, lo que puede reforzar la tentación de reescribir en lugar de refactorizar. El patrón descrito por Willison aplica directamente a proyectos acelerados con IA - la velocidad inicial de generación no elimina el riesgo de terminar con dos sistemas a medio hacer. Invertir en tests automatizados antes de cualquier refactor sigue siendo la cobertura más fiable, con o sin IA.
Google · Tus fuentesBrilla más alto en tu Google - con un solo clicAñadir a fuentes preferidas →
More on this from FULGOR
noticias·OpenAI llama ‘RSI’ a su nueva definición de AGI y revela cómo los agentes de código dominan ya la investigación interna