When you work long enough you'll find it. Places where changing software is risky you can end up waiting for approvals. Places where another company purchased yours or you are getting shutdown soon and there is no new work. Sometimes you end up on a system that they want to replace but they never get around to it.
Being overworked is sometimes better than being underworked. Sometimes the reserve is better. They both have challenges.
None of these are development conquering all goals.
Outside of purchased-and-being-shutdown, these are still frequently "we want to do things but we're scared of breaking things" situations, not "we don't want to do anything." Even if the things they want to do are just "we want to move off this 90s codebase before everyone who knows how it works is dead."
In that sort of high-fear, change-adverse environment "get rid of all the devs and let the AI do it" may not be the most compelling sales pitch to leadership. ("Use it to port the code faster so we can spend more time on the migration plan and manual testing" might have better luck.)