The Future of Junior Software Engineering Roles
71 comments
·May 21, 2025ochronus
palmotea
> Now, all of this combined: the junior --> senior transition takes say, 5+ years on average (I know, depends). If we move on with the "1/2 senior + AI agents" model, how does a company form a new team? When those seniors move away / retire, who's taking their place? What happens to the velocity of the team without mid-levels now?
> If we let this go on for a couple of years before a reckoning of "oh crap" happens, it'll be very hard to come back from this --> certain "muscles" of the aforementioned seniors will have atrophied (e.g. mentoring, growing others), a lot of juniors (and mediors!) will have left the industry.
> I hope companies will recognize this risk in time...
As someone in an org who has some exposure to legacy support, don't underestimate management's ability to stick its head in the sand until it's too late in order to focus on the new shiny.
I think we're down to two mainframe developers, still have a crap-ton of dependencies on it and systems that have been "planned to be decommissioned" for decades, and at least one major ticking-time bomb that has a big mainframe footprint.
hansmayer
>I hope companies will recognize this risk in time... I more than wholeheartedly agree with this great analysis. But we have to ask ourselves, when have most companies (by which I mean mostly those run by the hired CEOs) ever really recognised the risks? And why should we hope for it? Those that dont will hopefully wither away, their place to be filled in by those more, for the lack of a better word, "agile" :)
gloxkiqcza
One more thing to add: AI enhances capabilities of everyone, including juniors. Juniors with LLMs can do more than juniors without them could and therefore their value proposition is greater than before.
rndmio
But they don't learn from that, they turn the crank of the AI tooling and once they have something that works it goes in and they move on. I've seen this directly, you can't shortcut actual understanding.
gloxkiqcza
I disagree. LLM assisted coding is yet another level of abstraction. It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.
Today’s juniors still learn the same core skill, the abstract thinking and formalization of a problem is still there. It’s just done on a higher level of abstraction and in an explicitly formulated natural language instead of a formal one for the first time ever. They’re not even leaving out the formal one completely, because they need to integrate and fine tune the code for it to work as needed.
Does it introduce new problems? Sure. Does it mean that today’s juniors will be less capable compared to today’s seniors once they have the same amount of experience? I really doubt it.
Gud
I disagree. I use LLMs to help me like a teacher would.
askonomm
Indeed. With AI juniors can create horrible software faster, and in bigger quantities. Based on my experience AI really only enhances your existing talent, and if you have none, it enhances the lack of it, since you still need to be able to know how your AI slop fits in the larger system, but if you're a junior you most likely don't know that. Couple that with skipping the step where you must actually understand what you copy and paste from the internet for it to work, you also lengthen the time it takes for a developer to actually level up, since they do much less actual learning.
That's at least my experience working with multiple digital agencies and seeing it all unfold. Most juniors don't last long these days precisely because they skip the part that actually makes them valuable - storing information in their head. And that's concerning, because if to make actually good use of AI you have to be an experienced engineer, but to become an experienced engineer you had to get there without AI doing all your work for you, then how are we going to get new experienced engineers?
gloxkiqcza
I think what you’re describing is caused by the fact that people that would previously pursue law, medicine or some other high paying field now pursue software engineering because it pays well and is a pretty comfortable job overall.
The nerdy tinkerers stay the same and AI empowers them even more. Are they rare? Yes. But this shifts the topic from science/engineering to economics/sociology. Granted, that was the topic of the original submission but for me that’s the less interesting part.
thefz
> AI enhances capabilities of everyone
Wildly debatable
> Juniors with LLMs can do more than juniors without them could
Except that being juniors they lack the critical skills to understand when code produced by AI is trash
ochronus
Very true! But, they are also more prone to just rolling with whatever quality AI throws at them.
gloxkiqcza
Remembering some PRs from before... It was always about how much attention to detail/quality the particular junior dev pays. Often times it’s not much at all which might be harder to notice now.
lawn
Juniors with LLMs can also ruin things much faster than before.
avereveard
but, can they grow?
whstl
With proper guidance, of course.
If Seniors are too busy babysitting the AI, then no.
nsonha
is the assumption "in order to grow you have to fail YOURSELF"?
pydry
The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.
Who would pay for that?
Not a lot of companies, which acts as a filter.
As it turns out, a few companies do because they are super strapped for cash. That's why a lot of junior first experiences are a trial by fire in environments that are on another level of dysfunction working with either no seniors or bottom of the barrel seniors.
This acts as another filter. Some juniors give up at this point.
These filters prevent junior engineers from becoming senior. This is actually pretty good for seniors - being a rare, in demand commodity usually is.
I dont think AI changes this calculus much except insofar as AI amplifies the capacity for juniors to build ever bigger code jenga towers.
ochronus
> The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.
Thankfully, that's not my experience with most juniors. Again, my experience is limited (as all of ours is), but if you filter juniors well during hiring, you can get a wonderful set of high-potential learning machines, who, with the right mentors, grow like crazy.
pydry
Ive worked with a bunch of great juniors too. None of this changes the fact that they cant hit the ground running, they make mistakes which have to be unpicked and mentoring them eats up time.
rcxdude
>The problem the industry faces isnt that juniors dont grow it's that they spend up to 18 months being a drain on productivity after which point they tend to leave.
This is largely a result of the compensation behaviour of the industry. A junior that gets hired and grows does not get a raise in their salary to the market rate, the only way for them to get the compensation commensurate with their new skills is to leave and get hired somewhere else. Companies can avoid this problem by not doing this.
marcus_holmes
When I got into the industry (back in the early 90's), a large minority of new developers didn't study CS at University. We learned to code on the new, fun, microcomputers that were around, and then later just landed jobs as programmers almost by accident because we could already code.
I suspect this will be the future; the vast industry we're in now will shrink (as we're seeing now), and will rely on self-taught programmers more as AI removes the Junior role.
There will always be people who enjoy writing code and will do that for fun, I think. It'll be interesting to see what happens to all the other folks who never wanted to do this in the first place and only got into it because it's a good career.
tialaramex
I think this "self taught coder" approach has two distinct big problems over actual Computer Science graduates writing software
1. Cliffs. There are big swathes of theoretical CS where we know things can't be done, and the self-taught people would smash their faces into such problems forever because they won't even realise it's insoluble in principle rather than merely difficult, whereas with a more principled background you needn't expend this wasted effort.
2. Local Maxima. Without a principled understanding it's easier to mistake a local maximum you've stumbled into for a global maximum. After all, all the small tweaks you tried make it worse, so, how are you expected to guess that a violently different solution would be better? Theory could help but you don't have any.
dgb23
Point 1 sounds interesting but I can't comment on it, because I don't remember ever having encountered it.
Point 2:
One of the most important techniques as a self-taught programmer is to develop an instinct for "foundational solution that wants to get out" so to speak. So you search for the name of the type of problem you're looking at or for the approach you half-way discovered. You don't have a tutor or professor who will tell you where you are, so you need to figure that out yourself, often by assuming that someone else already put a label on the map.
On the other hand, self-taught does not mean "you don't have theory". From my experience getting the raw knowledge is the easy part. There are a lot of excellent resources out there, from book recommendations/compilations to freely available lectures and so on.
The thing that I always missed or were generally harder to come by are far more precious than that: guidance and feedback from teachers/mentors, interaction with peers who are in the same boat and most importantly time.
raddan
These are absolutely spot on. I worked as a programmer having been a self taught coder. There were important things I just did not understand. A good example is how to gauge the runtime complexity of a program. I did not know what I did not know. Looking back at the code I wrote then—eek!
I hit another wall later in my career and that drove me to go to grad school. I met some folks there who clearly leveraged their CS knowledge (eg, people who were solving niche compiler problems “for fun”) and I realized that there was a lot more to CS than the stuff I had learned on my own. So I stuck with CS and never went back.
shivasaxena
What makes you assume that a self taught coder would lack theoretical CS knowledge? Are you confusing bootcamp graduates with self taught coders?
With AI it's infinitely easier, but even before there have been plenty of self taught developers with good CS grounding.
tialaramex
> What makes you assume that a self taught coder would lack theoretical CS knowledge?
Because that's what self taught means. I would not consider myself to be a "self taught coder" for example because I have a CS degree.
zkmon
The big assumption being made here is that the software work involves really coding a lot. Not it doesn't. In my company, actual coding, design, logic etc all are only about 10% the overall work. Software engineers are not employed by technology companies alone. We call these tech companies technology vendors. The situation described in this article might be a bit applicable to these technology vendor companies, but not for non-tech companies who employ the bulk of the global software workforce.
There is hardly any real logic or coding work involved. You would believe me if you work in a non-tech company. Most of your time goes into navigating the company's process, tools, and people. Yes, it is called People-Process-Technology for a reason. Even the word "Technology" here refers to engaging the tech vendors and consultants to get some work done, or just figuring out how to use a legacy software or constant chasing others to get dependencies resolved. Weeks and months pass by, waiting for a dependency to get resolved so that your last code commit could actually finish it's build. Tons of JIRA tickets and INCs would have flown around meanwhile which creates an imaginary realm of huge work and productivity - all resulting in a single line of code change getting tested. It could even be celebrated via huge email thanking every one (100s of people), making it look like a big achievement.
The point is, AI doesn't replace junior engineer roles. Junior engineers are preferred for assigning all dirty drudgery, who can be blamed if things go wrong and who can give away their credit to bosses when things work well and who kind of flexible with good attitude. That's very attractive!
Basically we hire people to own some risk and accountability. Distribution of work is primarily to distribute the risk, blame and accountability, not really to get the work done. Actual work is done by non-employee consultants in India, eastern Europe or Vietnam etc.
For example, we don't use opensource because we can't hold someone accountable. The fact that opensource simply works, doesn't count. However if some vendor offers the same opensource tech with enterprise support or as a managed SaaS, we would buy that.
kazinator
I've never worked in any example of this fictitious organization where seniors are too important and well paid to write the code, so they just wave conductor's batons to orchestrate juniors into doing all the work.
raddan
It is most definitely a thing, and that is how my job worked when I was at Microsoft, in three different roles. All of the senior people I worked for definitely could code (one of them was well-known in the memory management research space), and they would occasionally do so. But largely, they focused on the big picture, and virtually all of my interactions with them was over a whiteboard. I was very surprised when I first got there that they basically never wanted to put eyeballs directly on my code; they preferred to talk to me about it. As a junior person, developing the fluency to have whiteboard conversations was difficult. But when we’d leave the meetings I would have a much clearer idea about what I should do, and perhaps more importantly, what I should not do. In all of those projects, 100% of the code was written by me and other junior people.
airbreather
The skill of breaking down the system to smaller constituant parts was formerly the domain of the Systems Analyst - an occupation now almost extinct by formal title, as the coders reached up into this role.
Presumably this occured because the Systems Analyst was virtually archtecture agnostic, but a computer person could consider both the problem breakdown and the optimal architecture to fit, juggling each a little to optimise that interface between requirements and implementation. This personage then claimed the title of "Architect".
However, I am seeing, in certain areas, a deep lack of specification skills and wonder the Systems Analyst might not partially have a resurgence as a profession.
ggm
I think in hindsight it would have been amazing to have senior students in the team exercises, but really what would have been even more excellent would have been industry placement. Things like not having this is why my 1982 degree failed the bar for BCS chartered engineer status.
I continue to believe the first 12-18 months after graduation are vital. I still can't believe some of the things I thought about s/w before I entered the workforce and I can't believe some of the things I got away with over the years since.
eastbound
I thought Quality Assurance was a thing! The more I fled it, the more I learnt the skills of programming. I think our kids will look at us and the way we thought filling forms was providing any assurance of quality, and perhaps by then it will be all LLM-no-forms.
iLoveOncall
As a senior engineer I'd much rather hand-hold a junior rather than an LLM. Junior roles aren't going anywhere.
The expectation that LLMs will multiply the output of more experienced engineers is simply ridiculous.
I work in a FAANG on one of the main teams using GenAI. The impact from GenAI we've calculated and that senior leadership is taking decision upon is an overall gain of about 5% velocity on CODING tasks, so about 2.5% on overall tasks.
If you feel like GenAI has overall doubled or tripled your productivity I'm sorry but it's a sign that you suck and are working on incredibly simple problems.
dzonga
most computer science programs in the US - are just "applied math". I'm from a 3rd world country but did CS in the US at a state school - you only do programming for the first intro programs like C then OOP that's it.
DataStructures, Databases, Operating Systems, Discreet Math etc are usually done without any programming at all. besides one or two assignments
The rest of the program it's mostly Math stuff. The only other time you do programming is if you choose an elective towards your graduation.
rester324
Interesting. I wouldn't have thought that.
I have an MS in CS from a small Eastern-European state run university, but the curriculum looked very differently: a ton of applied math yes, but also assembly programming, graphics programming, networking, databases, programming intro I-I, advanced programming I-II, project management, artificial intelligence, all kind of specializations, algorithms and data structures I-II, etc.
Is this not how it is in the US?
Edit: and most of those courses had practical lab sections with hands-on programming
hansmayer
Well, thats the reason its called computer science, and not "computer vocational training".
thefz
How can you have mature engineers... with no juniors?
Gud
To be honest, and maybe I’m using LLMs wrong, but are they really _replacing_ juniors?
I use ChatGPT occasionally, as a teacher.
I feed it a query and typically it responds with the correct result.
Wouldn’t this be empowering junior developers and make them more productive?
I use ChatGPT in the same way to learn German.
codr7
Someone with enough money and long term vision could hire them, train them and rent them out for profit.
constantcrying
>I believe that the response of computer science departments should be to refocus themselves on the skill abstract problem-solving.
Absolutely. The value in a CS degree is not in learning this or that language or tool. It is in being able to understand how to solve difficult problems effectively.
There's one angle which most of these arguments miss (totally not in the scope of the article, which is fine). A couple of statements I believe are true (based on my and my network's limited experience):
1. Juniors grow. Most of them grow fast, becoming solid mid-levels in 1-1.5y (in the right environment)
2. The industry depends heavily on a wide pool of mid-levels. These are the folks who can produce decent quality solutions, and don't need hand-holding anymore. They are the “velocity” of the team. Engineers tend to spend a few years there, before they might grow into seniors.
3. Seniors will age out.
4. AI doesn't grow (as it is today), it's stuck on the low-junior level mostly. This might change, but currently there are no signs for this.
5. Seniors would need to spend _a lot_ of time fixing AI's output, and course-correcting.
Now, all of this combined: the junior --> senior transition takes say, 5+ years on average (I know, depends). If we move on with the "1/2 senior + AI agents" model, how does a company form a new team? When those seniors move away / retire, who's taking their place? What happens to the velocity of the team without mid-levels now?
If we let this go on for a couple of years before a reckoning of "oh crap" happens, it'll be very hard to come back from this --> certain "muscles" of the aforementioned seniors will have atrophied (e.g. mentoring, growing others), a lot of juniors (and mediors!) will have left the industry.
I hope companies will recognize this risk in time...