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.
What if 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 intentionally?"
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.
Top comments (13)
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.