Short-term, automated tech debt creation will yield gains.
Long term the craftsperson writing excellent code will win. It is now easier than ever to write excellent code, for those that are able to choose their pace.
Given it's 2025 and companies saddled with tech debt continue to prioritize speed of delivery over quality, I doubt the craftperson will win.
If anything we'll see disposable systems (or parts) and the job of an SE will become even more like a plumber, connecting prebuilt business logic to prebuilt systems libraries. When one of those fails, have AI whip up a brand new one instead of troubleshooting the existing one(s). After all, for business leader it's the output that matters, not the code.
For 20+ years business leaders have been eager to shed the high overhead of developers via any means necessary while ignoring their most expensive employees' input. Anyone remember Dilbert? It was funny as a kid, and is now tragic in its timeless accuracy a generation later.
> it's 2025 and companies saddled with tech debt continue to prioritize speed of delivery over quality
Maybe. I'm seeing the opposite - yes, the big ships take time to turn, but with the rise of ransomware and increasing privacy regulation around the world, companies are putting more and more emphasis on quality and avoiding incidents.
Also, companies are expected to adapt more faster or see their lunch money taken by startups (unless you're in a heavily regulated space). There's a lot of quality opensource software out there, so you don't need much to bootstrap. The tech debt that was ok because you can take your sweet time to deliver some feature is no longer so.
Yes there will be a class of developer like that, but it would only be considered winning if you're satisfied with climbing some artificial institutional hierarchy.
If anything we'll see disposable systems (or parts) and the job of an SE will become even more like a plumber, connecting prebuilt business logic to prebuilt systems libraries. When one of those fails, have AI whip up a brand new one instead of troubleshooting the existing one(s). After all, for business leader it's the output that matters, not the code.
For 20+ years business leaders have been eager to shed the high overhead of developers via any means necessary while ignoring their most expensive employees' input. Anyone remember Dilbert? It was funny as a kid, and is now tragic in its timeless accuracy a generation later.