I'm not sure I understand the logic that we wouldn't hire Juniors because now we have AI.
What jobs are Juniors doing that AI can now do? I don't get juniors to build me entire web sites or implement complicated agentic pieces of work. Most of the time, we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months. If we think that we don't need to refill the pool now because of AI, then that is daft although I can understand a period where companies are deciding whether they still need 50 Developers instead of 20 + AI.
For me, the worst change for Juniors is remote working. I don't want the experience of newly qualified engineer being sitting in their bedroom all day chatting to people on Teams and not knowing when they can interrupt and when they can't. We used to have an office so we could at least do 2 days per week together but we don't any more. The banter, the office, the observation, the overhearing things is a critical part of both learning engineering and learning how to be part of a workplace.
I think it is less about junior engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to generate code anyway.
I agree with you about juniors and remote work - but like everything else: just figure it out.
Your customers aren't sitting next to you several times a week, yet they have no problem paying you and expecting you to get your job done. Sure, you might need to meet in person a couple of times a year but if you're smart enough to use a computer you can figure out how to work with someone in a different location. The issue is probably not the distance.
I guess a lot of this depends on whether you consider juniors to be part of your talent pool. Unless you are retaining them, it is just subsidizing industry at large to train them.
I stayed less than a year at my first two jobs. They bet wrong.
This is standard because after a year of experience, a fresh junior dev is worth roughly twice as much on the open market. Most companies won't give a 100% raise because it would upset the apple cart with other employees wanting similar raises. So the junior dev has to move on to get paid what they're worth.
I don't understand when he says "the job has changed to using agents but human judgement is still required" and then goes on with that assumption will remain true for our lifetimes basically. But the elephant in the room is that's going away very soon right?
Think back to 2024 and how your job has changed over the last two years. It went from science fiction to reality. And as engineers surely we understand the concept of expotential growth. It's not just us outsiders using claude to make our code but internal anthropic engineers are using it to make claude itself better. (Probably they also use openai and gemini to double check stuff!) And that's the expotential loop. Does anyone really believe in 2028 human judgement will still be the thing?
Pre-AI juniors were valuable because on many tasks, it was faster for me (senior eng) to write a quick spec have a conversation with a junior, and have them go off for a few hours or a few days and write the code, and then come back with it for review. I could do that with several junior engineers and pretty reasonably paralellize the work.
Now a junior takes my spec, drops it into Claude, and submits a PR a few minutes later. So I'm back to being the bottleneck -- there's constant pressure to provide specs and review code, and ultimately that process is just me having an indirect conversation with Claude (em dash is mine).
The junior is probably providing negative value, since it would be more efficient for me just to talk to Claude, and they're not learning anything, because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I'm not sure what the solution to this is, I still think we need to train junior engineers. I think my best advice to juniors right now is stop using Claude so much. Use it to plan and answer questions, but you should still be writing code even it's slower. Because that's the only way they're going to learn enough to effectively guide AI and review output and get past being a net negative.
I'm not sure what the article actually has to say about the topic it presents. It seems to want to be something about not hiring junior talent (something by the way not restricted to the tech industry) but instead it ends up more a critique about people wanting to use a waterfall pipeline.
I'm just staring at the title, wondering how this offensive, double-and-a-half-negative phrase made it all the way to the frontpage. I'm going to skip this one for that obvious reason.
I agree with the sibling comment and also don't understand how the title is "offensive". I literally can't think of anything that could be offensive about any term in the title or the title as a whole.
I would have liked the article to address more specifically what skills will be needed in the future and how engineers of all levels will learn them. Senior engineers in my circle feel their own brainrot, and at the same time feel like super wizards combining our deep software knowledge with the amazing AI dev tools. How will the AI native engineers learn the things, do they need to learn the things, what does anybody need to learn anyway? Let’s talk about it.
Wouldn't the logic to only hire Junior engineers if AI could do the work, what do you need the Senior salary for if they're both just asking AI to do things.
This is obviously assuming the ideology of an organization that would consider something like "We shouldn't be hiring engineers anymore" in the first place so they obviously have absolute trust in AI.
There are too many new grads and the quality bar outside of target programs has dropped nor never existed to begin with.
And the target programs graduate around 15-20k EECS adjacent majors a year.
It's hard to justify hiring a (choosing random college) CS@Ouachita Baptist University
grad for $140K TC (50th percentile for an entry level SWE) let alone $100K TC [0] (25th percentile for an entry level SWE) unless they are truly an outlier.
For example, back in college I had a buddy who really didn't want to take our OS class because it was hard, so he used transferology and found an OS class offered by some random Christian university in Texas where the class assignments were either writing biblical analogies for system programming concepts like memory management or basic fizzbuzz level assignments. My alma mater's CS program ended up blacklisting that college when admin was working on transferring the credits for that class and began reviewing the class's curriculum.
While that is an extreme example, outside of target programs, the quality bar drops dramatically, and an entire generation of grads are truly unemployable at the current prevailing wages.
Well, this is the thing. I was talking to someone a few days back, someone in Academia, and the conversation around the table was about how can we make it so we don't have to resort to increasingly more sophisticated ways to surveil students so they don't AI slop their entire degrees.
The problem is that universities, seemingly on a global scale, decided to run on economic incentives instead of academic ones. There are way too many people just doing degrees they have no interesting in learning about because university is just a way to a better job, and guess what, that "better job" no longer exists... and yet, year after year we have more and more people that have no clue what their credentials claim they should know by heart.
This blogpost didn't really address the elephant in the room that increasingly the bottleneck is no longer the part that jr devs could help out with.
Every startup I know that hired some level of jr's and encouraged them to use AI found themselves in a code review bottleneck for basic code quality and architecture decisions. Many startups I know are largely forgoing jr devs.
Code quality regarding evolvability, reliability, maintainability is still part of the development process. All of the people who claimed src code is just assembly on Twitter some months ago have started chiming in that they were wrong.
I do wonder what this does to the talent pipeline like mentioned in the post.
There’s an irony too, in that junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow. It’s what’s happening at my company and it feels silly since certain projects are way behind and constantly hiring because the very senior lead refuses to use AI
Seniors don’t use SO anymore, it virtually died if you look at traffic. The reason the market is so tough for juniors isn’t because seniors are bad at chat or agent workflows, it’s quite the opposite of what you say.
Did they ever? SO wasn't around during my junior days so I never got to experience it from that angle, but it looked like it would have been an incredible resource for those who juniored in its heyday. However, I never found it to be successful in delivering to the problems I encountered as a senior.
Hiring seniors is a waste of money. You need someone who knows the jargon well enough to drive LLMs, but not too much more. The LLMs are good enough to do the debugging, the coding, and a big part of the design work and system architecture.
Most of the work today is manual testing and feeding the bugs back into the LLMs.
I've been programming for 15 years, but I've never really taken the plunge into 3D work. Always wanted to. So I figure, now that coding agents are so powerful, let's see if I can make something!
I've tried 3 experiments so far, and have given it serious effort. They're all terrible.
The reason they're terrible is that it's a skill issue. I don't have 3D skills. I don't know the lingo, I don't know how to describe my problems, and I don't know when the agent is shooting itself in the foot.
Yeah, you need to learn the jargon, and then use that to ask the agent to debug its own output. Sometimes you can get away by asking the agent to do the web searches and get it to figure out the stuff on its own. Again, it's not zero effort, but it's no longer skilled work.
It's lived experience. My management is a lot happier when I move too fast to really pay attention to the problems and use my expertise, and the output is good enough that nobody really complains. Building most software is no longer skilled work; it takes minimal training. The industry just hasn't caught up yet.
Well. I own my business and I really hate this attitude that some startups executives have. I want quality. Not blind speed. I want speed to be a by product of a well built product and a system that builds it. Not a bunch of slop thrown over the wall that I have to then debug and fix.
I'm not sure I understand the logic that we wouldn't hire Juniors because now we have AI.
What jobs are Juniors doing that AI can now do? I don't get juniors to build me entire web sites or implement complicated agentic pieces of work. Most of the time, we hire Juniors to help fill the talent pool with the hope that they will be productive in a few months. If we think that we don't need to refill the pool now because of AI, then that is daft although I can understand a period where companies are deciding whether they still need 50 Developers instead of 20 + AI.
For me, the worst change for Juniors is remote working. I don't want the experience of newly qualified engineer being sitting in their bedroom all day chatting to people on Teams and not knowing when they can interrupt and when they can't. We used to have an office so we could at least do 2 days per week together but we don't any more. The banter, the office, the observation, the overhearing things is a critical part of both learning engineering and learning how to be part of a workplace.
I think it is less about junior engineers, and more just about the kinds of work inexperienced/cheap developers are often doing: assembly line, JIRA-ticket-taker type development.
This is especially impacting Indian tech workers in the US [0] since these are often the types of roles that InfoSys and other foreign tech consulting firms are staffing. The new $100,000 fee to sponsor an H1B visa has made it difficult to justify hiring foreign tech workers when most of the time they are just going to be using American LLMs to generate code anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
I agree with you about juniors and remote work - but like everything else: just figure it out.
Your customers aren't sitting next to you several times a week, yet they have no problem paying you and expecting you to get your job done. Sure, you might need to meet in person a couple of times a year but if you're smart enough to use a computer you can figure out how to work with someone in a different location. The issue is probably not the distance.
Totally agree about remote work for juniors. Even as a senior I feel like it's diminished some of my skills, in spite of all the benefits it brings.
Agreed wfh to me is just generally bad for any creative work but for a new person it must be taking aways years of development.
The goal is prevent homegrown talent, and give a reason to import H2B of offshore.
I guess a lot of this depends on whether you consider juniors to be part of your talent pool. Unless you are retaining them, it is just subsidizing industry at large to train them.
I stayed less than a year at my first two jobs. They bet wrong.
This is standard because after a year of experience, a fresh junior dev is worth roughly twice as much on the open market. Most companies won't give a 100% raise because it would upset the apple cart with other employees wanting similar raises. So the junior dev has to move on to get paid what they're worth.
You win some, you lose some. Maybe your coworker juniors became seniors and didn't negotiate higher pay.
You’re in a whirlwind of propaganda at the moment. The talking points and takes are mostly planted. Even the title has an inner circle nod to it.
what does this mean? can you explain? legit question not rhetorical
I don't understand when he says "the job has changed to using agents but human judgement is still required" and then goes on with that assumption will remain true for our lifetimes basically. But the elephant in the room is that's going away very soon right?
Think back to 2024 and how your job has changed over the last two years. It went from science fiction to reality. And as engineers surely we understand the concept of expotential growth. It's not just us outsiders using claude to make our code but internal anthropic engineers are using it to make claude itself better. (Probably they also use openai and gemini to double check stuff!) And that's the expotential loop. Does anyone really believe in 2028 human judgement will still be the thing?
Pre-AI juniors were valuable because on many tasks, it was faster for me (senior eng) to write a quick spec have a conversation with a junior, and have them go off for a few hours or a few days and write the code, and then come back with it for review. I could do that with several junior engineers and pretty reasonably paralellize the work.
Now a junior takes my spec, drops it into Claude, and submits a PR a few minutes later. So I'm back to being the bottleneck -- there's constant pressure to provide specs and review code, and ultimately that process is just me having an indirect conversation with Claude (em dash is mine).
The junior is probably providing negative value, since it would be more efficient for me just to talk to Claude, and they're not learning anything, because it's really hard to learn anything by skimming code that's being pooped out by Claude.
I'm not sure what the solution to this is, I still think we need to train junior engineers. I think my best advice to juniors right now is stop using Claude so much. Use it to plan and answer questions, but you should still be writing code even it's slower. Because that's the only way they're going to learn enough to effectively guide AI and review output and get past being a net negative.
I'm not sure what the article actually has to say about the topic it presents. It seems to want to be something about not hiring junior talent (something by the way not restricted to the tech industry) but instead it ends up more a critique about people wanting to use a waterfall pipeline.
Double negative title implies clickbait :)
I'm just staring at the title, wondering how this offensive, double-and-a-half-negative phrase made it all the way to the frontpage. I'm going to skip this one for that obvious reason.
I agree with the sibling comment and also don't understand how the title is "offensive". I literally can't think of anything that could be offensive about any term in the title or the title as a whole.
It's not really a double negative as the negations are in different clauses. If you remove both negations, you get a completely different statement:
> Hiring junior engineers will solve the problem you think you have.
I would have liked the article to address more specifically what skills will be needed in the future and how engineers of all levels will learn them. Senior engineers in my circle feel their own brainrot, and at the same time feel like super wizards combining our deep software knowledge with the amazing AI dev tools. How will the AI native engineers learn the things, do they need to learn the things, what does anybody need to learn anyway? Let’s talk about it.
Wouldn't the logic to only hire Junior engineers if AI could do the work, what do you need the Senior salary for if they're both just asking AI to do things.
This is obviously assuming the ideology of an organization that would consider something like "We shouldn't be hiring engineers anymore" in the first place so they obviously have absolute trust in AI.
very hard for junior engineers out there now.
There are too many new grads and the quality bar outside of target programs has dropped nor never existed to begin with.
And the target programs graduate around 15-20k EECS adjacent majors a year.
It's hard to justify hiring a (choosing random college) CS@Ouachita Baptist University grad for $140K TC (50th percentile for an entry level SWE) let alone $100K TC [0] (25th percentile for an entry level SWE) unless they are truly an outlier.
For example, back in college I had a buddy who really didn't want to take our OS class because it was hard, so he used transferology and found an OS class offered by some random Christian university in Texas where the class assignments were either writing biblical analogies for system programming concepts like memory management or basic fizzbuzz level assignments. My alma mater's CS program ended up blacklisting that college when admin was working on transferring the credits for that class and began reviewing the class's curriculum.
While that is an extreme example, outside of target programs, the quality bar drops dramatically, and an entire generation of grads are truly unemployable at the current prevailing wages.
[0] - https://www.levels.fyi/t/software-engineer/levels/entry-leve...
Well, this is the thing. I was talking to someone a few days back, someone in Academia, and the conversation around the table was about how can we make it so we don't have to resort to increasingly more sophisticated ways to surveil students so they don't AI slop their entire degrees.
The problem is that universities, seemingly on a global scale, decided to run on economic incentives instead of academic ones. There are way too many people just doing degrees they have no interesting in learning about because university is just a way to a better job, and guess what, that "better job" no longer exists... and yet, year after year we have more and more people that have no clue what their credentials claim they should know by heart.
> The AI version of this argument is not a new insight. It’s an old (and mistaken) preference, wearing new clothes.
Everything sounds like AI now when you squint just a bit.
This blogpost didn't really address the elephant in the room that increasingly the bottleneck is no longer the part that jr devs could help out with.
Every startup I know that hired some level of jr's and encouraged them to use AI found themselves in a code review bottleneck for basic code quality and architecture decisions. Many startups I know are largely forgoing jr devs.
Code quality regarding evolvability, reliability, maintainability is still part of the development process. All of the people who claimed src code is just assembly on Twitter some months ago have started chiming in that they were wrong.
I do wonder what this does to the talent pipeline like mentioned in the post.
There’s an irony too, in that junior engineers are more likely to understand and use AI tools, and quickly become more performant than their senior engineers asking questions on stack overflow. It’s what’s happening at my company and it feels silly since certain projects are way behind and constantly hiring because the very senior lead refuses to use AI
Seniors don’t use SO anymore, it virtually died if you look at traffic. The reason the market is so tough for juniors isn’t because seniors are bad at chat or agent workflows, it’s quite the opposite of what you say.
> Seniors don’t use SO anymore
Did they ever? SO wasn't around during my junior days so I never got to experience it from that angle, but it looked like it would have been an incredible resource for those who juniored in its heyday. However, I never found it to be successful in delivering to the problems I encountered as a senior.
Hiring seniors is a waste of money. You need someone who knows the jargon well enough to drive LLMs, but not too much more. The LLMs are good enough to do the debugging, the coding, and a big part of the design work and system architecture.
Most of the work today is manual testing and feeding the bugs back into the LLMs.
I've been programming for 15 years, but I've never really taken the plunge into 3D work. Always wanted to. So I figure, now that coding agents are so powerful, let's see if I can make something!
I've tried 3 experiments so far, and have given it serious effort. They're all terrible.
The reason they're terrible is that it's a skill issue. I don't have 3D skills. I don't know the lingo, I don't know how to describe my problems, and I don't know when the agent is shooting itself in the foot.
Yeah, you need to learn the jargon, and then use that to ask the agent to debug its own output. Sometimes you can get away by asking the agent to do the web searches and get it to figure out the stuff on its own. Again, it's not zero effort, but it's no longer skilled work.
Is this a poorly instructed llm? Or a poorly constructed thought?
It's lived experience. My management is a lot happier when I move too fast to really pay attention to the problems and use my expertise, and the output is good enough that nobody really complains. Building most software is no longer skilled work; it takes minimal training. The industry just hasn't caught up yet.
Well. I own my business and I really hate this attitude that some startups executives have. I want quality. Not blind speed. I want speed to be a by product of a well built product and a system that builds it. Not a bunch of slop thrown over the wall that I have to then debug and fix.