Rethinking the junior developer in the age of AI

One of the most common predictions about AI and software engineering is that junior developers will disappear first. That conclusion often comes from viewing the impact of AI primarily through the lens of code production - if we assume that the role of a junior developer is to take relatively well-defined tasks and turn them into code, then it follows pretty naturally that increasingly capable models put that role under pressure. The larger shift happening is from tactical programming toward strategic programming. As generating code becomes cheaper, more of the value in software engineering moves toward deciding what should be built, structuring systems well, creating the right abstractions, managing context, and understanding how the pieces fit together. When viewed through that lens, I think the role of junior engineers starts to look quite different.

A codebase that works well with AI has many of the same properties as a codebase that works well for junior engineers. It needs to be understandable, have clear boundaries and conventions, and be structured so that context can be discovered without relying on knowledge that exists only in the heads of a handful of senior engineers; Your AI can't read your thoughts (yet) but then again, neither can a junior engineer. Increasingly, those characteristics have a direct impact on the effectiveness and cost of using agents as well - a sprawling repository full of implicit knowledge requires more context, consumes more tokens, and gives an agent more opportunities to misunderstand the system. A repository that a properly onboarded junior engineer can navigate and reason about is likely to be one that an agent can navigate effectively too. Having junior engineers working in a codebase therefore creates a useful forcing function. If they continually need senior engineers to explain hidden assumptions before they can make progress, there is a reasonable chance your agents are paying for those same assumptions through larger context windows, additional prompting, more review cycles, and more mistakes.

There is also a broader question of how much understanding we expect engineers to retain as models become more capable. There's no getting away from the fact we need to understand the logic of the systems we are responsible for and while that does not require being able to explain every function, loop, or piece of syntax, we should understand how the program flows, what talks to what, where state lives, why the important abstractions exist, and where the significant failure modes are. The Feynman technique feels particularly relevant here. Teaching something to someone who does not already understand it is one of the best ways of discovering the gaps in your own understanding. Junior engineers create this pressure naturally because they do not yet share all of the assumptions accumulated by the people who built the system. They ask why a service is separate, why an abstraction exists, why a particular pattern is used, or what happens when something fails. Sometimes the answer transfers important experience to the junior engineer. Sometimes the question reveals that the reasoning behind a decision has been lost, or that an assumption everyone has been carrying for years no longer makes sense.

This new AI era also changes the value of those fresh perspectives because the distance between having an idea and having something tangible enough to evaluate is collapsing. We can increasingly go from an idea to a working prototype in hours or days, which means we can explore a much larger set of ideas than we could when every experiment carried a significant implementation cost. Product development becomes increasingly dependent on the quality and variety of the ideas we choose to explore. Finding product market fit, testing different approaches, and discovering better solutions all benefit from having people who see a problem differently. Someone who has spent ten years working in a particular domain has enormous experience to draw from, but they have also spent ten years learning the conventions of that domain. Someone earlier in their career brings a different set of assumptions and is often more willing to ask why something has to work the way it currently does. When the cost of turning those questions into experiments drops dramatically, that perspective becomes much more valuable.

This also changes how I think about the role of senior engineers. Experience becomes highly leveraged when senior engineers use it to shape systems, recognize failure modes, establish architectural direction, teach others, review decisions, and create the environment in which both people and agents can work effectively. There is an interesting tension here because - historically, perhaps (how true will this continue to be?) - the further we progress in an engineering career, the more likely we are to have developed a strong sense of programming as a craft. There is satisfaction in personally solving a difficult technical problem, finding an elegant implementation, and producing code we are proud of. The shift toward strategic programming asks senior engineers to apply that craft at a different level. Their experience can increasingly be expressed through the architecture, constraints, standards, context, and guidance that allow a much larger amount of implementation to happen successfully. A senior engineer who can make five junior engineers and twenty agents substantially more effective may create far more value than one who remains the best individual programmer on the team.

And then there's the economic argument. I am skeptical that junior engineer salaries are going to be the engineering expense that companies ultimately need to optimize around. AI consumption is becoming a real line item, individual engineers are gaining significantly more productive capacity, and the economics of software development are changing quickly. If a well-structured repository reduces agent context and token consumption, if good mentorship allows less experienced engineers to operate with significantly more leverage, and if a broader set of people can now turn ideas into prototypes quickly, then simply asking which engineering roles AI allows us to eliminate feels like a very narrow optimization.

So, what does the highest-performing engineering team look like as the marginal cost of producing code continues to fall? I suspect the answer involves a deliberately constructed mix of experience levels, perspectives, human judgment, mentorship, and AI. Senior engineers have an increasingly important role in designing the environment in which that combination succeeds, while junior engineers provide fresh thinking, challenge accumulated assumptions, force systems to remain understandable, and develop into the experienced engineers we will need in the future. AI raises the floor for what an individual engineer can produce, and at the same time raises the bar for how well we structure our systems and organizations. The companies that understand that distinction may find themselves investing more deliberately in junior engineers as a result - we certainly are.