Стоит ли просто переписать наш legacy-фронт перед добавлением AI-фич?

Почти никогда. Переписывания enterprise-продуктов требуют пересборки лет customer-driven, часто недокументированного поведения, пока изначальный продукт продолжает эволюционировать. Два таймлайна расходятся, и переписывание редко догоняет. Стратегическая интеграция — оставить legacy-shell и инжектить современные модули через типизированную границу — доставляется быстрее и живёт дольше.

Webpack module federation — всегда правильный ответ?

Нет. Транспортный механизм значит меньше, чем интеграционная граница. Module federation — один вариант из нескольких. Паттерн, который стабильно работает — маленький, осознанно спроектированный контракт между host и модулями, независимо от того, federation, single-spa или самописный loader его несёт.

Как избежать того, чтобы bolt-on AI-архитектура не стала собственной legacy через два года?

Относитесь к интеграционной границе как к архитектурному решению с именованным владельцем, а не per-feature импровизации. Каждый новый модуль интегрируется одинаково. Bundle-гигиена, версионирование и graceful degradation — заботы платформенного уровня, не per-team. Большинство команд, оказавшихся с bolt-on legacy, попали туда, пропустив ownership границы.

Ловушка, в которую попадает каждый enterprise при добавлении AI в legacy-софт (и подход, позволяющий её избежать)

body{background:#050510;color:#fff;font-family:system-ui,sans-serif;padding:2rem;max-width:720px;margin:0 auto;line-height:1.6}Ловушка, в которую попадает каждый enterprise при добавлении AI в legacy-софт (и подход, позволяющий её избежать)Enterprise-команды с серьёзными инвестициями в legacy-фронтенд стек сталкиваются с повторяющимся выбором при добавлении AI-фич: переписать, прикрутить сбоку или интегрировать. Два из этих ответов стоят года и бюджета. Третий — тот, что реально доставляется — и паттерны, делающие его рабочим без наследования бардака.Continue