AI Helped Modernize Our Angular App. Then It Helped Fix What Broke.

AI helped us migrate our Angular components to standalone and implement signals.

And when we worked through those regressions, AI helped us fix them too.

“Broken by AI, fixed by AI” is a funny way to describe the experience. But it leaves out the most important question:

How do you know the second set of changes is better than the first?

Our work involved two changes: moving components to standalone and introducing signals.

Standalone components make template dependencies explicit through component imports, rather than relying on NgModule declarations and scopes. Signals introduce a different way to represent reactive state and track its consumers.

Neither change is inherently a problem. But both require attention to how the existing application behaves.

A component does not exist in isolation. It depends on services, templates, other components, and assumptions that may have been in the application for years.

Similarly, introducing signals is not simply replacing one variable declaration with another. It requires understanding how state changes, where derived values come from, and how those changes reach the UI.

The code can look modern while the application no longer behaves as expected.

That was the difficult part of our experience: working through the regressions introduced during the migration.

It would be easy to turn this into a warning about letting AI touch an existing application.

But that would only tell half the story.

AI contributed to the changes that caused problems. It also helped us work through those problems and eventually resolve them.

That makes the experience harder to summarize as a simple success or failure.

An assistant can produce an incorrect change and later help identify what was wrong with it. There is no contradiction there. Generating a migration and investigating a specific failure are different tasks, with different context available.

The danger is treating either answer as correct because it sounds convincing.

An explanation of why a fix should work is useful. It is not the same thing as evidence that the expected behavior has been restored.

The question I would put at the center of any AI-assisted migration is:

What would tell us this change is wrong?

For standalone components, that means looking beyond the edited component. Are its dependencies available? Has provider scope changed? Do the routes and tests that use it still work?

For signals, it means checking behavior rather than just the new API usage. Are updates reaching the right consumers? Is derived state still correct? Have asynchronous interactions changed?

These are examples of checks worth making, not a list of the specific bugs we encountered.

The distinction matters because every application has its own failure modes. A generic checklist helps, but it cannot replace knowing what users expect from your application.

It also matters when AI edits tests. Sometimes tests genuinely need updating after a migration. But changing an assertion until a test passes can hide a regression rather than resolve it.

A passing test is valuable only if it still checks the behavior we intend to preserve.

Based on this experience, these are the principles I would use to structure the next one:

These are recommendations for the next migration, not a claim that our process followed every step perfectly.

We eventually fixed the regressions, with AI helping in that work.

But “AI fixed what AI broke” should not become an excuse to skip validation. Repair work still costs time and attention. Without a comparable migration done another way, I would not claim that the overall process was faster or slower.

What the experience does reinforce is a boundary:

AI can help propose the migration and the repair. The team still needs a trustworthy way to decide whether either is correct.

Modernization is not complete when the code uses newer Angular APIs. It is complete when the intended changes work and the behavior we needed to preserve still holds.

Have you used AI for a framework migration? What caught the problems that the initial changes missed?