Does the Job Survive the Decade?
I get asked weekly. I finally sat down and answered.
The question comes from three directions now.
Clients ask it on calls, usually near the end, in a tone that is trying very hard to sound casual. My family asks it at lunch, in a gentler way, which is somehow worse. And juniors ask it, except they are not really asking. You can hear in how they say it that they have already decided the answer is no and they want me to argue them out of it.
I do not know. Nobody knows. Anyone telling you they know what this job looks like in 2030 is selling a course, and the course costs more than the answer is worth.
But I spend most of my week building things with these tools now, and a view from inside the work is worth more than another round of confident nothing.
Here is what already left my week and is not coming back. The typing. Not the programming, the typing. The part where I know exactly what I want and then spend forty minutes producing the characters. Boilerplate, the fifteen similar files, the migration, tests for code that already works. I used to think of that as the job. It was never the job. It was the toll you paid to get to the job.
I do not miss it and I am not going to pretend I do.
Something else left too, and that one stings a little. Knowing things by heart used to be worth money. I spent years building that, the way everyone in this field does. Lifecycle hooks in order, in two languages, half asleep. It is worth close to nothing now. I do not say that bitterly. I say it as someone who paid for it.
What has not moved at all is the part where someone tells you what they want and they are wrong about it.
That is still most of the job. A client describes a feature and the feature is not the problem. You sit with them, you watch them work, you notice the thing they never mention because it is too obvious to say out loud, and then you build something they did not ask for and they say yes, that, that is what I meant. No model has done that for me. I do not see how it would. It requires being in the room and caring what happens after.
Knowing what good looks like has not moved either. A model will happily hand you something that runs. Whether it should exist, whether it will still make sense in two years, whether the abstraction earns what it costs, whether anyone can find the button. Somebody has to hold all of that, and the only way to hold it is to have been wrong about it before, in production, with people waiting.
And when it breaks at three in the morning a person gets the call. Nobody has automated being responsible.
So the split I see coming is not developers against AI. It is developers against developers.
On one side, people who can describe a system precisely. What it does, what it must never do, where the edges are, what happens when it is wrong. Those people are about to have the best years of their careers, because the thing that used to limit them was how fast they could type and now it is not.
On the other side, people whose value was producing the code after someone else made the decisions. That value is compressing fast and everyone standing there can feel it.
The part I actually worry about is that the second side is where all of us started.
We built this whole industry on juniors learning by doing the mechanical work under supervision. The mechanical work is exactly what got automated. I came up by writing bad code, having someone senior take it apart in review, and writing it again, and I do not know what replaces that. I have asked people I respect and none of them know either. Telling juniors to get better at prompting is not an answer. It is a way of changing the subject.
What I do about it is write more specifications and fewer files. I spend my attention on what the thing should be and whether it can be trusted, because that part is still mine. I work in places where the hard part is not the code. Industrial data, 3D, spatial things, where being wrong is expensive and being fast is not enough.
And I am careful about where a model sits in what I build. It can choose, it never computes. It reads what someone wants and picks from options I defined, and every number a user sees comes out of code I can test.
There is a real chance I am wrong about some of this. I was completely sure about several things in 2021 that are embarrassing to remember now.
But yes, I think the job survives. It survives the way it always has, by becoming a different job and keeping the same name. That is not the part that worries me.
What worries me is the road in.