Las empresas con inversión material en stacks frontend legacy se enfrentan a una elección recurrente al añadir features de IA: reescribir, atornillar encima o integrar. Dos de esas respuestas cuestan un año y un presupuesto. La tercera es la que realmente sale a producción — y los patrones que la hacen funcionar sin heredar el desastre.
A las empresas que añaden IA a software legacy normalmente se les ofrece una elección binaria — reescribir o atornillar. Ambas pierden. Las reescrituras se atascan a los dieciocho meses mientras el producto legacy sigue evolucionando; los bolt-on acumulan su propia legacy para el segundo año. La tercera opción — integración estratégica mediante una frontera tipada y deliberada entre el host legacy y los módulos modernos — es lo que los equipos que envían fiablemente realmente eligen.
Casi nunca. Las reescrituras de productos empresariales requieren reconstruir años de comportamiento guiado por clientes, a menudo no documentado, mientras el producto original sigue evolucionando. Las dos cronologías divergen y la reescritura rara vez alcanza. La integración estratégica — mantener el shell legacy e inyectar módulos modernos a través de una frontera tipada — sale más rápido y sobrevive más tiempo.
No. El mecanismo de transporte importa menos que la frontera de integración. Module federation es una opción entre varias. El patrón que funciona consistentemente es un contrato pequeño, diseñado deliberadamente, entre host y módulos, sin importar si federation, single-spa o un loader hecho a mano lo transporta.
Tratar la frontera de integración como una decisión arquitectónica con un dueño nombrado, no como una improvisación por feature. Cada módulo nuevo se integra del mismo modo. Higiene de bundles, versionado y degradación elegante son preocupaciones a nivel de plataforma, no por equipo. La mayoría de los equipos que terminan con legacy bolt-on llegaron ahí saltándose la propiedad de la frontera.