Should we just rewrite our legacy frontend before adding AI features?

Almost never. Rewrites of enterprise products require rebuilding years of customer-driven, often undocumented behaviour while the original product continues to evolve. The two timelines diverge and the rewrite rarely catches up. Strategic integration — keeping the legacy shell and injecting modern modules through a typed boundary — ships faster and survives longer.

Is webpack module federation always the right answer?

No. The transport mechanism matters less than the integration boundary. Module federation is one fit among several. The pattern that consistently works is a small, deliberately designed contract between host and modules, regardless of whether federation, single-spa, or a hand-rolled loader carries it.

How do we avoid the bolt-on AI architecture from becoming its own legacy in two years?

Treat the integration boundary as an architectural decision with a named owner, not as a per-feature improvisation. Every new module integrates the same way. Bundle hygiene, versioning, and graceful degradation are platform-level concerns, not per-team. Most teams that end up with bolt-on legacy got there by skipping ownership of the boundary.

The Trap Every Enterprise Hits When Adding AI to Legacy Software (And the Approach That Avoids It)

body{background:#050510;color:#fff;font-family:system-ui,sans-serif;padding:2rem;max-width:720px;margin:0 auto;line-height:1.6}The Trap Every Enterprise Hits When Adding AI to Legacy Software (And the Approach That Avoids It)Enterprises with material investment in legacy frontend stacks face a recurring choice when adding AI features: rewrite, bolt-on, or integrate. Two of those answers cost a year and a budget. The third is the one that actually ships — and the patterns that make it work without inheriting the mess.Solutions