TL;DR – PMs are shipping code so help them do it safely.
My product managers are shipping code.
This has got me thinking about how software engineering is changing in the world of AI.
Prior to 2026, you could have a career shipping tickets and writing features. As an industry, we’d done a pretty good job of creating a sandbox where engineers could focus on creating business value – memory management abstracted away a lot of toil, cloud computing meant you don’t need to know much about your hardware, DBAs meant you don’t need to know the internals of your persistence layer, CMS systems allowed marketing folks to ship changes without deployments. Hopefully your company had good standards for CI/CD so you didn’t need to think about how to get your code in front of users. This left you free to write code in a sandbox, where most of your bugs were down to errors with your implementation of the business logic rather than nasty things like database queries slowing to a halt – and in those incidents, you could usually call in some experts.
Your expertise in writing that business domain code was what kept you employed. Then 2026 and AI coding tools took off and suddenly PMs are shipping code. The number of people in that safe sandbox has just exploded, and it’s exploded with people who are really incentivised to ship features and probably understand customer needs better than you. Suddenly, your ability to ship features is no longer a USP because if PMs can do it as well as you, then why would they waste time explaining a feature when they can just ship it themselves?
Or to quote Kent Beck:
I’ve spent between 1-2% of my seconds on the planet putting words in a row. For a programmer I’m pretty good at it. The differential value of being better at putting words in a row just dropped to nothing. Anyone can now put words in a row pretty much as well as I can.
So rather than panicking about whether you’re doing to have a job because everybody is shipping features, reframe the question as this: what work needs to be done outside the sandbox, either to make the sandbox safer for people to ship or because it cannot be done inside the sandbox? There are so many interesting problems outside the sandbox! Just a few that come to mind are:
- observability: all that code the PMs are shipping – how is it performing in the real world?
- concurrency: those PMs will want to ship low-latency experiences, and may start using concurrency primitives without deeply understanding what’s going on.
- CI/CD + automated testing: you can make the standards for how code gets deployed quickly and safely
- security: need I say more?
- system design: how will all these features interact? How far can they scale before they break?
It’s a great time to be alive as a software engineer – we’re no longer tied down to all that pesky business logic and we can start dealing with the hard “techy” problems that many of us really enjoy. So get outside the sandbox and have some fun!
Paula Muldoon 