{"slug": "ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke", "title": "AI Helped Modernize Our Angular App. Then It Helped Fix What Broke.", "summary": "An engineering team used AI to migrate its Angular application to standalone components and signals, but the assistant introduced regressions that the team then worked through with AI's help. The team concluded that AI can propose both migrations and repairs, but developers still need independent verification—such as checking provider scope, routes, tests, and derived state—to decide whether either change is correct, warning that editing assertions until tests pass can mask regressions.", "body_md": "AI helped us migrate our Angular components to standalone and implement signals.\n\nIt also introduced regressions.\n\nAnd when we worked through those regressions, AI helped us fix them too.\n\n“Broken by AI, fixed by AI” is a funny way to describe the experience. But it leaves out the most important question:\n\n**How do you know the second set of changes is better than the first?**\n\nOur work involved two changes: moving components to standalone and introducing signals.\n\nStandalone 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.\n\nNeither change is inherently a problem. But both require attention to how the existing application behaves.\n\nA component does not exist in isolation. It depends on services, templates, other components, and assumptions that may have been in the application for years.\n\nSimilarly, 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.\n\n**The code can look modern while the application no longer behaves as expected.**\n\nThat was the difficult part of our experience: working through the regressions introduced during the migration.\n\nIt would be easy to turn this into a warning about letting AI touch an existing application.\n\nBut that would only tell half the story.\n\nAI contributed to the changes that caused problems. It also helped us work through those problems and eventually resolve them.\n\nThat makes the experience harder to summarize as a simple success or failure.\n\nAn 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.\n\nThe danger is treating either answer as correct because it sounds convincing.\n\nAn explanation of why a fix should work is useful. It is not the same thing as evidence that the expected behavior has been restored.\n\nThe question I would put at the center of any AI-assisted migration is:\n\n**What would tell us this change is wrong?**\n\nFor 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?\n\nFor 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?\n\nThese are examples of checks worth making, not a list of the specific bugs we encountered.\n\nThe 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.\n\nIt 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.\n\nA passing test is valuable only if it still checks the behavior we intend to preserve.\n\nBased on this experience, these are the principles I would use to structure the next one:\n\nThese are recommendations for the next migration, not a claim that our process followed every step perfectly.\n\nWe eventually fixed the regressions, with AI helping in that work.\n\nBut “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.\n\nWhat the experience does reinforce is a boundary:\n\n**AI can help propose the migration and the repair. The team still needs a trustworthy way to decide whether either is correct.**\n\nModernization 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.\n\nHave you used AI for a framework migration? What caught the problems that the initial changes missed?", "url": "https://wpnews.pro/news/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke", "canonical_source": "https://dev.to/harishbuilds/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke-1ip9", "published_at": "2026-10-19 11:32:04+00:00", "updated_at": "2026-10-19 11:44:45.308365+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Angular"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke", "markdown": "https://wpnews.pro/news/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke.md", "text": "https://wpnews.pro/news/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke.txt", "jsonld": "https://wpnews.pro/news/ai-helped-modernize-our-angular-app-then-it-helped-fix-what-broke.jsonld"}}