Last year my LinkedIn feed had a genre. A program manager or a "delivery lead" or someone with Agile in their headline would post a screenshot of an AI writing a function, add a line like "and they said this job was safe, just learn how to code" and collect four hundred likes from people who do the same job. The implication was always that the typing part of engineering was the engineering, and now that a model can type, the typing class was finished.
I think they read the org chart upside down. And I'm glad they're finding out
Here is the thing nobody on that side of the feed says out loud. AI is not very good at the load-bearing part of building, which is deciding what the system should do, knowing why the last three attempts failed, and being able to tell when the model just confidently handed you something broken. It is genuinely, embarrassingly good at the other part. The status rollup. The release notes nobody reads. The feature catalog that goes stale in a week. The test plan that is mostly a reformatting of the acceptance criteria. The weekly update that summarizes the standup that summarized the Slack thread. That is not the work AI struggles with. That is the work AI was born to do.
So look at who sits where. The supporting layer exists, by design, to do the parts the engineers did not want to do. Keep the project tracker updated. Chase people for updates. Turn an engineer's two sentences into a paragraph for the VP. Turn an engineer's paragraph into two sentences for the VP. Maintain the doc. Run the meeting where everyone says what they said in writing yesterday. I am not being cruel about this. These tasks were real and they were tedious and somebody had to do them, which is the whole reason the roles got funded. The problem is that "produce a clean summary of inputs other people generated" is the exact shape of what a language model does best, and "produce the inputs" is the part it still can't do alone.
And here is the asymmetry that the obsolescence posters skipped. To use AI well you have to be able to check it. You have to read the diff and know it's wrong. You have to look at the generated migration and notice it has no rollback. The builder already has that. It is the same skill that made them a builder. The coordination layer, on the other hand, was hired on the explicit understanding that they would not need to read the code, and now the tool that is supposed to save them produces output that can only be trusted by someone who can read the code. They got handed a chainsaw and the manual is in a language they were told they'd never have to learn.
A good program manager is not a status-update machine.
Yes, I know. But out of ~40 I met so far in my career maybe 2 were. 38 were definitely status-update machines. The actual job, the one worth paying for, is judgment about what gets cut, the political cover when a launch slips, knowing which executive's "quick question" is a threat, and getting six teams who hate each other to commit to one date. AI does none of that. It cannot absorb blame in a room. It cannot decide that the technically correct sequencing is the politically suicidal one. Reducing the whole function to "keeps the Confluence page warm" is the coder's oldest fantasy and it has always been wrong about the best people in the role. I know.
The judgment-and-shielding job was never the whole headcount. Under every one of those genuinely good program managers there was a layer of people whose actual day was the artifact maintenance, the rollup, the catalog, the deck that restated the deck.
The "engineers are finished" crowd had it backwards because they confused who produces value with who is loudest about producing it. The person who can tell a good answer from a confident wrong one is the person AI makes more valuable, not less. That person was usually building. It was rarely the one posting the screenshot.