AI Won't Kill Junior Devs – But Your Hiring Strategy Might
78 comments
·May 18, 2025siliconc0w
haiku2077
The problem you proposed would be a mid level or senior dev type problem on most organizations' job role descriptions. In most organizations junior devs are not expected to design solutions for open ended problems on their own.
siliconc0w
For Junior, problem is already triaged/scoped, low criticality, solutions to this kind of problem are provided but may need judgement or extension to identify the best approach. Design and implementation should be based on requirements gathering from immediate known stakeholders. May need low-level supervision/guidance.
For mid-level, they are capable doing more of the problem triaging/classification and can handle vaguer, larger scoped problems. They can identify the correct stakeholders to engage with and, ideally, influence. Can identify the most likely best approach amongst a set of possible approaches. Guidance is high level- like a weekly or bi-weekly 1:1. Better design taste as far as how to measure outcomes or rollout changes safely.
For senior you're ideally solving classes of problems rather than specific problems. You're charting a longer term roadmap that generates work and exerts influence amongst number of teams to drive long-term business outcomes. You are mentoring juniors/mid-levels so they're setup for success and have the right work at the right level of guidance at the right time to grow in their careers.
AdieuToLogic
While I would not have used the descriptor "dependencies", substitute that with the term "partners":
Our service occasionally gets especially expensive requests
that amplify to our partners, one of those partners have
started complaining that our bursts of traffic are
impacting other users, talk to them and propose a solution
that aligns with our different requirements.
With the clarification above, I believe a junior dev could perform this task, even if the proposed solution is known to be a learning exercise.
The immediate value to the team is the collection of partner concerns.
conro1108
In my experience, the problems given to juniors are often open ended “improve this” or “fix this” type projects, but smaller scope or lower priority things that more senior devs would just never get to.
I will say though, needing to socialize across other teams to understand the problem and drive the correct solution does strike me as more mid/senior level work.
t-writescode
In my experience, those are the worst sorts of jobs to give juniors if you want actually throughout though. They need direction, releasable pieces, etc. they don’t know how to break something apart into small, releasable parts yet. That’s a major thing more experienced devs can teach them.
azemetre
Why not? How else do you get these skills without doing it?
jlawer
Job / Position description means something more... It means that your expected to do the task and perform well at it or you will be let go.
Generally you don't put those skills in a Junior PD, but you would expect a Junior to take on these tasks if they hope to progress. The Mid level PD would have it listed and as the junior shows they can meet each and every additional skill, the option of a promotion becomes available.
haiku2077
Note the words "on their own". They would be paired with a more experienced dev to collaborate with.
com2kid
My first job out of coll, task 1 was improved query perf on our test result database. job 2 was "get performance tests working again."
Both 100 % open ended problems.
decGetAc
That task seems perfect for a junior dev. It's open ended but low risk and not interacting with multiple teams as directly
It's different from the one described above
> talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.
I'm sure some junior devs could do this but the majority wouldnt be able to
null
comrade1234
Hiring a junior dev is a luxury for big companies that can afford to tie up senior devs tandem coding with a junior for months, then giving easy projects to the junior dev with extensive code review and hand-holding for another year.
I don’t think anyone has the budget for that anymore - not even the big companies. It’s two years of negative $ output for the $ you put in and after those two years the junior dev leaves anyway for a more senior position.
t-writescode
There’s a lot to be said about this comment, but I’ll stick to two things.
1) it’s a waste of resources for seniors to be doing the work that the juniors and 2s can do. Hunting down infrequent or low priority bugs, fixing small layout issues, etc. they’re perfect for someone paid less and growing and learning the codebase.
There is *always* plenty of junior-ready work and the day a week of work to schedule, prep and help those juniors to do it pays dividends.
2) a Junior leaving because you won’t pay them, have a toxic culture or won’t give them a promotion when it’s time speaks more about a broken company culture and one of a style that’s rampant in the tech industry and business at large than it does about loyalty and willingness for the employee to stay at the company.
Good leadership and skilled organizers can easily solve the problems you’ve listed; and, even better, create a culture of longevity for all the employees at a company, not just the juniors.
Speaking as someone that has worked for companies that give a shit about their workers and who helped raise me up from a low SDE.
lolinder
> it’s a waste of resources for seniors to be doing the work that the juniors and 2s can do. Hunting down infrequent or low priority bugs, fixing small layout issues, etc.
These are tasks that in the current environment often get pushed back for "later" indefinitely. These tasks aren't un-resourced because the company isn't hiring juniors, the company isn't hiring juniors because they no longer have the funds for small fixes.
jiggawatts
As a customer of these types of businesses: yes, we can tell. We do care, and we are ready to drop the shitty products of these bad companies at the first opportunity.
Libcat99
The issue is not that companies don't have the funds to chase these bugs (which will impact future trust/revenue), it's that they don't want to spend it chasing these bugs. Next quarter thinking leads to bad software.
adgjlsfhk1
The problem with this idea is that being bug free and jank free is the moat that a mature app needs. Software lives on user trust. If everyone can see that the simple things aren't being done right, why will they have faith that the complex things are?
mjr00
IMO you're way overestimating how much hand-holding juniors need. Juniors coming out of college have a decent grasp of basic tooling like git, IDEs, debuggers, and yes AI coding assistants. We just hired two recent graduates and they were both getting meaningful work done independently within 2 weeks. They still need code review and guidance, but it's not like they need a senior watching over their shoulder telling them how to write a function in python.
You're going to have to teach them about the unique frameworks and processes at your company, but you have to teach seniors about those things too. Unless you're doing something really unique, juniors don't need to tie up senior devs "for months". Remember they can help each other, too.
ritcgab
Are the two recent graduate average fresh grads, or top ones?
robofanatic
This isn’t a new phenomenon and not limited to software development. Companies know that people get trained and leave all the time. Most companies have plans for that.
rtkwe
The answer used to be pensions, reasonable reliable raises, and promotion from within. Workers are responding to the signals sent by companies, the way to make the best money is bouncing around every few years to get actual raises, so that's what a lot of people do.
soco
This answer feels like right out of the MBA coursebook. If you ever hate your phone performance, your reservations app, your airline booking page, your... then know that this answer is the reason why.
laidoffengineer
i'm a laid off senior engineer (or at least that was my level when i was employed). i apply to junior roles all the time and get rejected without interview. feel like there are other senior engineers out there in the same boat.
this could be an amazing time for companies to pick up more experienced engineers at junior position/salary. but they aren't biting.
somerandomqaguy
>As Camille Fournier bluntly put it, many tech managers who shifted to "senior-only" hiring are asking for trouble: "How do people ever become 'senior engineers' if they don't start out as junior ones?"
If I were a betting man, I would wager that those managers either don't care, or are gambling that by the time senior engineers are in short supply, AI will be good enough to replace them as well.
throw234234234
It is a low likelihood and low severity risk for an individual manager/actor in any event with some potential mitigations (i.e. pay a little more if the time comes). Going by this and other forum's posts lately the mood seems to be that the tech industry is in structural decline due to AI - so as a manager who may buy into that I won't take this risk all that seriously.
Anyway as an average single company anything you do won't move the needle much - those people you train can move on anyway so that isn't a good way to cover that risk. Even if I have to pay more later, which is an unlikely outcome potentially given AI, that's tomorrow's problem and it affects my competitors and other companies as well most probably so I'm not at a relative disadvantage. Unless I'm a very big employer of tech I'm not going to affect future market dynamics either way as a single team.
However if the market is in structural decline and jobs will whittle away - maybe its better we don't hire juniors? They may thank us when they settle in another career with better long term prospects if what many posts are starting to say - that AI will kill the industry slowly. Better the hiring pool shrink to adjust to future expected demand than have higher unemployment and worse issues later.
bigfatkitten
The legal industry has already figured out that LLMs can draft routine documents (and make massive mistakes) as well as a graduate lawyer, but that’s not the point.
That industry has properly recognised that this is where people learn the skills to do more complex, higher value work.
bogzz
Maybe because law firms aren't managed by MBAs.
neilv
Also, a law firm partner worked all their way up as as a lawyer, but a tech company CEO probably didn't work all their way up as a software engineer (and may have never been one)?
(Understanding of the role, empathy for it, and a bit invested in thinking of the role as valuable.)
bigfatkitten
They are run by partners laser focused on making money, just over a longer time horizon than private equity would be. Equity partners have most of their own wealth tied to the firm.
Grads are cheap. Partners can dangle the future senior associate/partner carrot over the head of a hopeful junior for many years while that junior brings in money that goes into the partners’ pockets. The junior brings in more money as they grow professionally.
RhysabOweyn
For now... some states are beginning to change their laws to allow non-lawyers to own law firms.
https://www.wsj.com/articles/kpmg-wants-to-be-the-first-acco...
echelon
Why shouldn't a law firm be owned by non-lawyers? That limitation seems ridiculous.
Hospitals are owned by non-doctors. Engineering firms are owned by non-engineers. Sometimes it works, sometimes it doesn't. Sometimes the ones that fail are owned by the practitioners and the ones that succeed are led by former outsiders.
Toymaking companies are owned by adults, gynecology practices can be owned by men, wheelchair companies can be owned by those who can walk, record labels can be owned by non-vocalists, etc. Most sports teams...
Why should lawyers get special treatment?
If someone is a good operator, that's orthogonal.
Most ICs are not good at leadership, logistics, product, long term vision, etc. or at least not everything that a well-rounded CEO or owner might be. While hiring leadership from within the ranks works, it's not a necessary condition for success.
hengheng
Or because bad légal documents become obvious immediately, while bad code has a 2-3 year incubation period.
bigfatkitten
Not always. Contracts for example sometimes contain landmines that lay undiscovered for a decade or more.
A key difference is that law is an actual profession. It has qualification, continuing professional development and licensing requirements, and personal consequences for getting it wrong. None of these things are true for software development.
CPLX
I’m pretty fluent in both worlds and they are actually highly equivalent on this one specific point.
In both cases it looks perfect and it works right up until it doesn’t, usually for the same reason, entering an unanticipated state.
margalabargala
I would argue they are pretty similar. It's not hard for a bad clause in a contract to get overlooked at first and then become a problem years later. Example:
https://www.nbcnews.com/news/us-news/think-commas-don-t-matt...
rsynnott
Unfortunately that's not always the case. Bad _arguments in a case_, sure, but bad contracts? I'd fully expect that in 30 years some unfortunate lawyer will be attempting to untangle nonsense drafted by a 2020s LLM.
(Actually, it only just occurred to me, lots of laypeople are going to use these to draft _wills_, aren't they? That should be entertaining.)
i_am_jl
I am not understanding the joke.
kristianc
> Indeed, companies that try to staff only with experienced devs face a pipeline problem. Without juniors today, there are no seniors tomorrow.
This one seems like a classic Prisoner's Dilemma. Defecting (hiring only seniors) is rational in isolation, but if everyone defects, everyone loses. What incentive for a smaller company to hire and invest in training the junior if in two years they'll leave for a larger company anyway.
tiew9Vii
Provide an environment and incentives so that people enjoy working for your company and don’t want to leave.
null
hamandcheese
> if in two years they'll leave for a larger company anyway.
But if companies aren't hiring juniors like they used to, shouldn't retention be a lot easier?
kunzhi
> What incentive for a smaller company to hire and invest in training the junior if in two years they'll leave for a larger company anyway.
I find these statements so damning and self-incriminating. It's an open admission that the junior should expect to be treated poorly.
theshrike79
This is the way.
Our company hires a bunch of juniors from different fields every year, we keep the best ones and let the others off with recommendations (if warranted and in most cases they are).
matt_s
This aligns with my thinking that juniors can leverage AI to become seniors much faster than people without AI but there are important concepts about learning debugging, learning how the underlying technologies work, etc. that is crucial to becoming a senior dev. Just using AI to pump out code without knowing the details of how it works will not end up going well for the long haul.
latentsea
Seniors can also leverage AI to become juniors too.
aspenmayer
Dogfooding is encouraged for our top dogs, underdogs, and even random strays we find. In our vision of the future on the internet, everyone is a dog.
matt_s
I know you kid, or at least that gave me a chuckle, but this might be why seniors don’t find a lot of usefulness with AI, because we see blatant issues immediately and think it’s a waste of time sometimes.
latentsea
I sort of kid, I sort of don't. There's a process seniors go through when approaching problems that vibe coding short circuits by removing some of the elements that act as triggers to the critical thinking process. Without those cues, less critical thinking winds up happening.
Personally, I think it's more a matter of remapping those triggers onto this new process, but for now I think it's a real phenomenon.
riatin
> Traditionally, new developers cut their teeth on small, repetitive tasks – fixing simple bugs, writing unit tests, churning through minor feature tweaks. These tasks were mundane but crucial for skill-building. Now, a lot of that grunt work can be handled by generative AI.
To me, this is the salient point. There are more juniors coming through now who aren't learning the fundamentals, because there is a ready shortcut around the mundane tedious work. Which means they're trying to move onto higher value, higher risk areas without understanding the foundations
rsynnott
I'm curious just how much of this "senior only hiring" stuff is a _narrative_ thing vs an actual reality.
Many small startups _never_ really hired junior people, preferring to only take people who had some experience. To some extent, taking juniors and _turning them into_ seniors has always been more of a big-company thing than a small-company thing (which makes _sense_; it's expensive). I'd be curious whether there's actual data showing a shift, or if it's just vibes.
disgruntledphd2
I feel like I've worked with (and heard about) more companies trying the senior only thing in the last few years (Covid and beyond).
That could be a bias in my sampling of people I know and work with though.
I do think hiring only seniors is generally a bad idea unless you want only seniors who are content cranking out tickets and code. That, to my mind, isn't what you want a senior for, but apparently much of the market disagrees with me.
codr7
Using AI certainly isn't expected in any teams I'm leading; not that I'm going to forbid anyone to use a tool, but I will warn everyone about depending on it and the requirement for verification/understanding.
coryvirok
This has led me to wonder if this is the last generation of "senior" devs. The thinking goes, if it takes a couple of years to educate and train a junior dev on average and LLMs can increasingly replace junior devs... There is no need for a company to hire junior devs, starving the ecosystem of talent that would have otherwise gone onto becoming senior.
In a world where the average work is the first to be displaced (due to training data availability), the last to be replaced are the ones furthest from distribution mean...
jbmsf
We have one junior dev in a team about a dozen. They have had other roles with us, both at the current job and previous ones. We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.
But it's hard to imagine committing to the training without the history.
ramesh31
>We know they are smart, reliable, and motivated. It's a no brainer to spend time on training because, combined with the skills from other roles, they are likely to have a lot of leverage.
This is the problem, early career devs are extremely bimodal in skill distribution.
You can luck out and land the 1 in 10 who just gets it and has the knack and has been coding since they were 12. But 9/10 times you end up with someone who has trouble even making a commit or with writing basic syntax, who just "picked" software as a career at some point in college for the salary. This has been my experience anywhere that doesnt have FAANG level cash to be hiring the top graduates at 150k+.
platevoltage
>You can luck out and land the 1 in 10 who just gets it and has the knack and has been coding since they were 12. But 9/10 times you end up with someone who has trouble even making a commit or with writing basic syntax, who just "picked" software as a career at some point in college for the salary. This has been my experience anywhere that doesnt have FAANG level cash to be hiring the top graduates at 150k+.
This is crazy to hear as someone who has been coding in one form or another since 14, and was driven into becoming a scrappy freelancer because no one would give me the time of day. Where are these kids who can't make a commit, or know basic syntax even coming from?
wonger_
Maybe they played the interview game well? Or knew the right people at the right time?
gokhan
I find it quite naive that senior devs think this will stop with juniors. TFA says "No juniors today means no seniors tomorrow ... juniors must focus on higher-level skills like debugging, system design, and effective collaboration" and yet he believes AI won’t be doing all of that by the time those juniors somehow upskill on their own.
I was just testing the newly released Copilot Agent Mode in VS, and it already looks quite capable of debugging things independently (actually, it's not much different from VS Code Agent Mode, which came out a couple of weeks earlier).
System design? Not all seniors need Google-scale design skills. Most systems designed by seniors are either overdesigned, badly designed, or copied from an article or a case study anyway. There are plenty of seniors whose only real qualification is the number of years they've been working.
The author is from Google. I’m not sure if effective collaboration is something given there, but in many companies, especially outside of tech, it's not something you see often. And it's usually inversely proportional to the company’s age.
What seniors learned by doing is now written down and available to LLMs, often in multiple sources, explained by some of the best minds in the field. Any given senior likely knows only a fraction of a domain, and even less when you start combining domains. LLMs probably already there for some of the seniors, only they never checked.
mjr00
> What seniors learned by doing is now written down and available to LLMs, often in multiple sources, explained by some of the best minds in the field.
It may shock you to learn that this was true before LLMs. There was a website called "Google" which acted as a front-end for almost all recorded knowledge in human history, and putting a phrase like "best design patterns for web APIs" as a search query (the primitive name for prompts) would give you hundreds, if not thousands of real-life examples and explanations of how to accomplish your goal.
Somehow senior developers kept their jobs despite the existence of this almighty oracle. LLMs do a better job of filtering and customizing the information, but seniors will still keep their jobs.
Only non-engineers listening to VC-hype on podcasts think that AI can replace fully junior engineers. Here is a problem I recently asked a junior dev to solve:
Our service occasionally gets especially expensive requests that amplify to our dependencies, one of those dependencies have started complaining that our bursts of traffic are impacting other users, talk to them and propose a solution that aligns with our different requirements. Possible directions are X, Y, Z.
AI is pretty far from able to do this. A cracked out vibe coder maybe could have just added a one-off naive rate limit algorithm pulled from stack overflow or maybe pulled in an unmaintained 3rd party 'rate-limit' package and called it a day. And that would be fine for a MVP but in large organizations figuring out what to build, how to build it, and getting agreement with stakeholders is way, way more work that doing than actual implementation (which still rarely can be one-shotted and needs a lot of hand-holding and iteration to get decent solutions).