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 Brooker (VP, Distinguished Engineer at AWS) argues that junior developers have a structural advantage. Their accumulated heuristics haven't calcified into reflex yet, so they don't have to unlearn anything. The field, he says, is "more powerful than ever" for someone willing to expand their scope.
Around the same time, Mark Russinovich (CTO, Deputy CISO at Microsoft Azure) and Scott Hanselman (VP, Member of Technical Staff at Microsoft) published Redefining the Software Engineering Profession for AI, a paper arguing the exact opposite: AI imposes a "drag" on early-career developers. Juniors must steer, verify, and integrate AI output before they have an opportunity to develop the judgment required to do it well. If organizations focus only on short-term efficiency, they "risk hollowing out the next generation of technical leaders."
Both papers were widely discussed, both were treated as the definitive take, and they appear to flatly disagree.
They don't.
What if both sides are right about AI and junior developers?
Brooker is describing what individual junior developers can do. The person who arrives without wrong heuristics, who's comfortable expanding scope into business context and system ownership, who carries a pager and learns economics alongside code. That person will thrive. The absence of accumulated assumptions becomes an advantage when the assumptions are expiring anyway.
Russinovich and Hanselman are describing what happens to the cohort of junior developers. When companies stop hiring juniors, or hire them and pair them with AI agents instead of experienced engineers, or measure only short-term output velocity, the organizational pipeline dries out, because the structure fundamental to developing judgment has been removed.
Both claims are true, operating at different scales. Brooker is talking about individual disposition. Russinovich and Hanselman are talking about organizational design. The apparent contradiction doesn't exist, they're just zooming into different levels.
Which means the question worth asking isn't "will AI hurt or help junior developers?" but "who is making that decision, and are we making it on purpose?"
How automation has reorganized professions before
Arthur M. Wellington, a 19th century railroad engineer known for his work on infrastructure economics, defined engineering as "the art of doing well with one dollar what any bungler can do with two after a fashion."
The "art" in his example is the art of building economically. When execution becomes cheap, the profession reorganizes around judgment, trade-offs, and constraint management.
And this is a pattern, not a prediction.
The clearest quantitative example comes from manufacturing. When CNC machines automated metalworking through the 1970s and onward, operators running hand-operated tools were displaced. But the profession didn't shrink. In Computerized Machine Tools and the Transformation of US Manufacturing, a 2022 NBER study tracking four decades of data, the research team found that employment for college graduates in affected industries rose 86% from a low base, while losses hit high school graduates at 7-8%. The tasks that grew in demand were, in the researchers' words, "more conceptual and socially connected, and require more training, preparation, and learning" than the ones that declined.
Execution became programmable, and the profession reorganized around judgment, customization, and system-level thinking.
You probably already heard the spreadsheet version of this story. After Excel's introduction, bookkeepers and clerks shrank from 2 million to 1.5 million, but accountants, auditors, and financial managers surged. When the ledger work got cheap, the profession moved upstream into analysis and advisory.
The most structurally similar case, though, is playing out in a different discipline right now: large law firms are shrinking junior ranks as discovery and contract review are being automated.
The human center shifts to narrative construction, litigation strategy, and client counseling. But moving professions upstream isn't that easy: Discovery was historically where junior lawyers developed judgment. The grind of reviewing thousands of documents taught pattern recognition, relevance filtering, and adversarial thinking. Automating the execution layer removed the drudgery - along with the training ground.
Sound familiar?
The pattern is consistent: when execution gets cheap, professions reorganize around judgment. The question that varies, case by case, is whether the reorganization includes the next generation, or discards them.
The hiring decisions you're already making - whether you're aware or not
Every company that chose not to open a junior headcount this quarter made this decision. Every team that paired a senior engineer with an AI coding agent instead of an early-career developer made it too. Every manager who measures output velocity without accounting for the mentorship that isn't happening anymore makes it by default.
These are decisions being made today. Mostly unintentionally.
The complication that makes this harder than "just hire juniors and pair them up": Brooker's other essay from around the same time, My heuristics are wrong. What now?, describes an "extinction-level event for rules of thumb." Seniors are simultaneously revising their own heuristics while being asked to transmit judgment. The experienced engineer's mental model of system maintainability, code costs, API design, and service boundary assumptions is actively being invalidated in near-real time.
This is why Russinovich and Hanselman's preceptor model (structured mentoring through paired practice) specifies a year-long pairing as equals, not a senior dispensing wisdom to an intern. The model works because both parties are learning together. The senior contributes pattern recognition and system context. The junior contributes comfort with AI tooling and freedom from heuristics that no longer apply. Neither is the teacher. Both are learning.
Your choice, if you're hiring, is between making this structural decision consciously or letting it happen unintentionally - having a hundred headcount conversations without ever considering your pipeline.
If you're a junior: How to build judgment without waiting for your org
Everything above is about forces acting on you. Forces you can't change, like organizational decisions, cohort dynamics, and pipeline economics.
But you can still optimize, regardless of which way your company chooses.
Brooker's prescription is straightforward: expand scope. Engage with business context, customer needs, economics, and trade-offs. Own systems. Carry a pager. Don't wait for the structure to develop your judgment. Build it yourself by going where the ambiguity is.
Albert Zhao, a fellow AWS engineer, made this concrete in a recent video: rather than "learn to code better," the path is "learn to make decisions about systems": understand why a service boundary exists where it does, why a particular trade-off was chosen, and what the second-order effects are when requirements change.
The organizational design question is one you can't control. What you can control is whether you're building the kind of judgment that matters on either side of the decision.