Two of this year's most-shared pieces on AI's effect on junior software engineers read as direct contradictions.
In What about juniors?, Marc Broo...
For further actions, you may consider blocking this person and/or reporting abuse
Elegant explanation, thank you! ✨️
Thanks Anna!
The "individual vs organizational" framing is spot on, but I'd push it one step further.
From the operational side (I run a development team), the real trap isn't "we forgot to hire juniors." It's subtler: we kept hiring them, but silently removed the conditions where judgment develops.
Code review used to be the single best training ground for junior engineers. Not because reviewing code is hard, but because defending your review against a senior who disagrees is where judgment forms. When AI handles the first pass of review, that friction disappears. And friction was the point.
Same pattern with incident response. The 3 AM page that forces a junior to make a decision with incomplete information, then debrief it the next morning with the team. Replace that with an AI runbook and you've optimized the incident, but eliminated the learning.
The preceptor model Russinovich and Hanselman describe is the right direction. But it only works if organizations explicitly protect the "inefficient" moments that build judgment, instead of optimizing them away in the name of velocity.
Brooker's advice to juniors ("expand scope, carry a pager") is great. But it assumes someone gave them a pager in the first place.
This is one of the reasons why I'm really reluctant when it comes to automating code reviews.
While many organizations perceive this practice as a pure quality assurance step that - now that code is cheap - has become a bottleneck, it is so much more.
It helps every individual on the team develop and share knowledge, judgement, taste, and intuition - about the system they're building, the challenges and constraints based on the business context, the design and architecture decisions, etc. And it ultimately helps them carry what they learned forward, to the next team, to the next project, or product.
Exactly. And there's a second-order effect that rarely gets discussed: code review is one of the few moments where implicit knowledge becomes explicit.
A senior who "just knows" that a certain pattern will cause problems at scale is forced to articulate why during a review. That articulation is where institutional knowledge actually forms. Without it, the knowledge stays locked in one person's head (or worse, gets replaced by whatever the AI suggests).
The irony is that the teams most eager to automate code review are often the ones that already have a knowledge-sharing problem. They're optimizing away the one practice that was quietly compensating for it.
AI is the opportunity given to the developer to elevate out of coding and into designing. Spend more time designing solutions that works for your customer, review the result and redesign better.
This opportunity did exist in the past too. But now it is a forced opportunity that you take or you break.
Having said that, I would also be interested in how things would look 5 or 10 years later. With fewer developers coming in to the system, fewer new thoughts coming in, will AI continue to improve without the inputs to learn ?
Interesting question. We're already seeing a convergence towards stacks and patterns the AI "knows" well. It may become harder for new ideas, frameworks, languages, or tools to reach the amount of adoption required for becoming significant enough to influence the established model weights...
The distinction between individual outcome and cohort outcome is the key insight here. Brooker and Russinovich aren't arguing about the same thing — they're measuring at different levels of analysis, which is why both can be right simultaneously.
What this implies for hiring decisions: the organizations that will have strong senior engineers five years from now are the ones giving junior developers scope that includes judgment calls today, not just execution and verification. The question isn't "should we hire juniors?" — it's "what kind of work are they actually doing?" A junior dev who spends two years reviewing AI output without ever making an architectural decision isn't developing the judgment that makes a strong senior. They're developing review skills on someone else's decisions.
The org-chart framing nails it. The follow-on question I keep watching: who absorbs the verification cost as code volume scales? "Reads the diff" used to be junior. The role didn't disappear — it concentrated.
The CNC-to-accounting historical pattern you traced is the part that most takes on this topic skip. Execution gets cheap, professions reorganize around judgment. That framing changed how I approached the same topic.
I wrote about the talent pipeline angle a few days ago. We're removing the environment where developers learn to read code they didn't write and debug systems they don't understand. Teams lose that over a 5-10 year horizon, and quarterly velocity metrics won't show the damage until the senior engineers who carry institutional knowledge start leaving.
Your point about code review as judgment development stuck with me. Companies automating code review are optimizing for speed on a process that exists so a junior can watch a senior think through trade-offs. A linter or an LLM summary does a different job.
I'd push back on one thing: telling juniors to "expand scope into business context" assumes their organization gives them access to that context. A junior developer two levels below the decision making layer can't decide to carry a pager or sit in on architecture reviews. That takes the intentional org design you described, which puts the burden back on the same leaders making the hiring decisions.
You're absolutely right. Many developers - and especially early-career developers - aren't in a position that provides access to the required context...
Reminds me of a system I developed years ago. It was for an accounting firm, starting off with cutting out the need for juniors, by building a scanner-database pipeline for data ingest. Before the days of actually useful AI, it was manual coding and the result was an elegant spline driven OCR engine that ran 700k characters a second. Technological marvel (stuck behind a paid contract, so no open sourcing...), but it was so useful, they asked me to optimize the rest of their workflows, starting with the basic accounting... Then Reports... Then Billing... Then Forecasts... By the time I was done, nobody at the firm was necessary anymore except who? The junior... The person feeding the scanner... So heads up everyone, you think you're automating out the juniors, but by the time you're done, you're out of job too (eg. a software developer developing an autonomous software foundry, that takes a prompt and turns it into a tested, AI-native, self-patching app).
AI is changing how junior developers work, but it’s not replacing the value of learning, creativity, and problem-solving.
The real issue is that many companies now expect fewer entry-level roles while demanding higher productivity through AI tools. Junior developers who adapt, learn AI workflows, and improve communication skills will still stay valuable in the industry.
At AQVA Marketing, we see AI as a tool that improves efficiency, not a replacement for human talent and innovation.