Last year Mark Russinovich and I wrote a paper on how Software Engineering will redefine the profession, and how early in career engineers may see an “AI Drag,” while seniors will see a significant boost.

@shanselman
Scott, the paper frames the problem well but undersells one angle: the mid-tier. There is a huge population of devs who are not senior by title or years but have deep domain knowledge from living inside a product or industry for a long time. Those people get just as much of a boost as seniors, sometimes more, because they know exactly what to ask for and what to reject. The binary of "senior vs EiC" misses that.
The preceptorship model is solid in theory but I am not sure it addresses the deeper problem. My wife teaches first semester procedural programming and second semester OOP at university level. She switched to an inverse classroom model, students are engaged in lectures, homework comes back looking good, no questions, no pushback. Then exam time hits and the majority fails. My suspicion is that LLM generated homework mimics what a professor would expect closely enough that it does not flag as plagiarism, but the students never actually internalized the material. The cognitive debt from the paper is already showing up in education before these people even enter the workforce.
And from what I see with EiC colleagues who are already working: they use LLMs heavily on a daily basis with the same prompt-and-accept pattern. If that habit is already baked in by the time they start their first job, I am not confident a preceptorship program changes the dynamic. The mentor can explain and guide, but if the junior has no instinct to question AI output because they never built that muscle in school, you are fighting uphill.
The core thesis is right: stop growing juniors and you run out of seniors. But the pipeline problem might start earlier than the paper assumes, at the education level, not the first job.

@shanselman
Following up on the "senior vs EiC" framing: I think domain experts deserve a closer look here. Someone with deep domain knowledge who can produce specs that verify outcomes in a consistent, non-gameable way (think end-to-end acceptance criteria where the testing logic is not leaked to the LLM so it cannot optimize for passing while missing the point) is arguably doing the hardest part of the job. They are defining what correct looks like under real conditions.
That is the exact skill the paper identifies as the bottleneck: verification. But it roots that skill in engineering seniority when in practice it often lives with the person who knows the domain cold. Implementation is what AI is getting good at. Knowing whether the result actually solves the real problem is not an engineering judgment call, it is a domain judgment call.
The concession is that for things like concurrency, security architecture, and systems design, domain knowledge alone is not enough. But for a large share of actual product work, the person who can say "here is what done looks like, prove it without seeing my rubric" is more valuable than the person who can write the code. The paper's hierarchy flips in those contexts.
So the talent model is not a pyramid with seniors at the top and EiCs at the bottom. It is more like a matrix where domain depth and engineering depth are separate axes, and AI compresses the engineering axis while making the domain axis more important than ever.