So, what happens to programmers? Hello, unemployed friends.
I picked up another idea from a book called Reshuffle, which tries to understand what happens to work with the arrival of artificial intelligence. The author starts from an interesting premise: don’t look at AI purely in terms of task automation. Instead, look at the system as a whole. In particular, he invites us to analyze work as the resolution of a constraint - the solving of some kind of bottleneck.
Where the bottleneck used to be
Take programming. Until now, the bottleneck - the thing that has fed us for the last few decades - was the simple fact that writing code was hard. It was the scarce resource:
- Skilled people were expensive and took a long time to train.
- Requirements analysis was slow.
- Iterations on the code were far slower than iterations on ideation or design.
We resolved that bottleneck with programming ability. The cost sat there, so the money sat there, so the big constraint sat there.
What happens when the constraint loosens
Now that constraint is being relaxed. Producing software is much faster, much easier, and can be done in abundance.
And, as we’ve said many times on this channel - I was talking about it just the other day with Giuseppe in a live stream - once that happens, the constraint moves. Once software becomes abundant, creating software is no longer the bottleneck. The new bottlenecks become:
- Which software do you build?
- Once you’ve built it, how do you validate it?
- How can you be sure it’s safe, that it carries no risk?
So the constraints shift there, and the money shifts onto those things.
The work moves upstream
For months now I’ve been saying in my corporate courses - my flagship course for companies is called Reskill - that this is exactly where the value goes. (If you’re interested, get in touch: we cover AI agents, agentic coding, and everything about technical AI and its impact on technical work.)
This pushes us to spend less time writing code and more time:
- Validating it.
- Selecting it.
- Understanding what should be done and what shouldn’t.
We move onto a more architectural plane - a plane of validation. And now it’s starting to become clearer.
Risk analysis, reframed as constraint analysis
I’ve been talking about risk and risk analysis for a long time. I found a confirmation of that in this book, but with a sharper framing. I had only framed it as risk analysis. The author talks about risk too, but he also talks about constraint analysis - and that might be the real key to reading the situation.
Analyzing the job market in terms of the constraints we resolve by working, rather than in terms of task automation, helps you see the whole picture. Even if you’re not a programmer and do something else entirely, ask yourself: what bottleneck does your work actually solve? When AI loosens it, where does your value move next?
Let me know what you think, and whether it applies to your own work. In my opinion, it’s a lens that helps a lot.