It's the little things that make the craft
There's a class of engineering work that every team knows they should do but often deprioritizes. Library upgrades, dependency removals, build optimizations, framework migrations. The tedious work that never seems big enough, but touches a lot of files. It's far more likely to lose out to feature work when priorities are set.
In the past the effort to impact ratio here was more difficult to measure, and trickier to convince people of. The concept of technical debt meant very little to non-technical stakeholders until something went wrong. For example, when a Rails or Angular upgrade requires touching dozens of files across the codebase, the time investment makes it impossible to justify against feature work. It's essentially a question of "medium risk, low reward" vs "medium risk, high reward". You'd have to convince yourself it was worth doing, then convince your team, then convince whoever owns the sprint plan. That's a lot of social and mental energy, and this is why technical debt permeates and grows without ever being resolved. This is how so called "legacy" systems are born.
Begging Forgiveness vs Asking Permission
AI tooling lets you have a bias towards action with this kind of work. You have the freedom to try upgrades or refactors with minimal time investment. You can validate your ideas in code before even talking to anyone. PM is worried about upgrading a framework version? No problem, just do the upgrade and show them that our CI test suite still passes. People are more likely to sign onto things that already exist ("if you build it they will come"). If the upgrade or refactor doesn't work for some reason, no problem. You've learned something concrete about the system related to why it's not an easy change, which will let you advocate for a fix later. In the short term you've lost very little time, nobody even needs to know 😈.
Worst case, you learn that an approach is a dead end and move on. When the cost of being wrong is small, trying becomes easy.