As it is now, they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. The produced code is a black box, and the AI’s development is a black box too. All they know is that running it produces something like what they asked for. They have no idea about failure modes which is a fundamental concept of engineering. The worst part is that AI is covering up their deficiencies. They don’t know what skills they lack. They don’t even know what skills are required because they haven’t put the effort in.
There are obviously good junior engineers that are using AI judiciously and not as a crutch. They’re the ones who still interact with seniors to get help and actually learn. They would have been successful without AI too. These are the ones the author is talking about. In my experience, the momentum is moving towards the worse type of junior the more AI is adopted. Unless that changes, it will erase their value.
This is the biggest issue with AI. It is incredible when in the right hands (Senior devs who know good fundamentals and know how to code) but really bad when in wrong hands (Juniors with no fundamentals but they are made to believe that they know what they are doing).
And if they can do that- could they do it to themselves- going from a junior to a pro conversation?
Not coincidentally, this is exactly how we train our AI.
Edit: but to answer your question, an AI harness can only emulate the best teaching methods. Learning is up to the human.
The same way you wouldn't let a junior electrician near a drill, he gets screwdrivers till he learns to be gentle.
AI should only be for people with existing knowledge of a trade.
That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.
But the value add being marketed is something entirely different, which is where the disconnect is coming in
You still have standups, right?
I'd be questioning why at the very least the team lead/manager isn't questioning the lack of progress during those meetings and immediately requesting a more senior engineer help out.
Even before AI this was how it worked. Unless the junior engineer is being purposely secretive about lack of progress, which would have happened back then too, then this isn't an AI problem, it's a team culture one.
You’re describing a gap between those who would otherwise fail in their jobs sooner, and those who already know what to do. Sounds like there is a new paradigm for management, too.
Yeah this part should not exist anymore. It doesn’t where I work.
When I get a PR I just ask an agent to make the proposed changes. There is absolutely zero incentive for me to give feedback for you to give to an agent when I can give it to an agent myself.
Coding isn’t the job anymore. It’s understanding systems and architecture design, and ownership of what you work on. Being able to design solutions, understand them, deliver them and support them in production is the job now. Engineering is still engineering. End to end ownership is the job.
Remember moving to New England to look for work and all the interesting embedded medical device companies paid like $80k less than a react dev job I got at an ISP.
When I ask an agent to do a code change for a PR, it’s because it’s not something I think the other engineer really should waste their time on. It’s on the same level as nitpicking what lines the braces go on before we had auto-formatters and lint checkers in CI.
Other staff engineers I rarely even see their code. I trust them to be able to review and deliver and support their own code and communicate breaking changes. Knowledge gets disseminated at weekly architecture reviews, in person.
Offshore developers under me have their code gone over with a fine-toothed comb. They don’t own the work. They don’t support it. They can’t even speak to me without using copy pasted Claude responses that are wrong half the time anyway. I have zero qualms with “going over them”.
Agents don't "handle" code review. With no human in the loop, there is no difference between "generating" code and "reviewing" code. Let's not bastardize the word "review". The code is unreviewed. Now, whether that's a dealbreaker or not for your project or company is a different question.
Personally, I've found that unreviewed LLM code unnecessarily explodes in complexity and the credit / token cost per change increases in tandem as the LLM pulls more into its context window. This is especially the case when you let it go wild on test cases. We don't have an unlimited budget for AI, maybe you do, so this is a concern for us. So we've decided to continue to review code and ask LLMs to significantly reduce the complexity of their generated code - which is a task that we're finding they are extremely bad at.
They're probably extremely bad at reducing complexity because the incentive for frontier model providers might be to train models that are capable of one-shotting flappy bird, instead of models that are capable of maintaining mature code bases that already have an implementation of the ad-hoc parsing function it just generated, as well as the newly-generated 50 test cases for it.
The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.
So you already failed the first part of doing your goddamn job as an engineer which is reviewing and owning code. Code review is a vital part of that, because code ownership is a responsibility shared by your entire team. We used to say that cowboy coders were a disaster for your team and now you're saying everyone on your team is effectively a cowboy coder.
If it turns out claude or whatever LLM you're using pulled in a bad package and now your companies data has been exfiltrated are you going to be the one willing to be fired for your blunder?
So you're producing slop that is going to blow up in your faces. That's your organization's right, but not everyone is interested in giving up on producing a quality product like you guys are.
This is an incredibly good and concise articulation of where the role is going. Thank you.
AI just made it obvious.
If you constantly have to push back against the eager puppy jr dev who’s 1000% sure their vibe slop is prod ready and has proudly told the admiring crowd of stake holders it’s ready to go, wtf kind of life is that? Now the senior/lead is the bad guy and is in the no win scenario.
Yuck.
Oh.
You just described my last couple of jobs
I guess that partly explains why I've been miserable and exhausted all the time
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 do their work anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
Now I can fire off agents ona remote box to do the grunt work and open PRs, then just prompt to review/iterate it. No timezone timezone delays or language barriers. Nearly instant feedback.
Coding is solved. Engineering is not. Catch up or be left behind.
I'm pretty certain SOTA is better than you at engineering. It's gonna be a real shock to your system when you finally acknowledge to yourself that you are nothing more than an expensive proxy to an LLM.
The concept of software engineer is so watered down at this point it often barely resembles engineering at all
source: I am licensed.
But I don't call myself an engineer at all. I'm a software developer through and through. My employer calls me an engineer for some reason through
Technical writing is a skill just like any other form of writing and if you’re bad at it that’s on you.
People despise AI slop novels and they also despise AI slop technical documents.
Him placing this at the end of all his statements is just screaming, it takes an engineer to get a nicely engineered product. admitting defeat in his own statements over and over, kinda funny.
> Coding is solved. Engineering is not. Catch up or be left behind.
I'm really grateful for my company's culture. Reading replies like this, I remember how easy it is to forget how atrocious that can be elsewhere. Thanks for the perspective and reminder.
I'm just grateful I don't work with people that say "good riddance" to blanket foreign talent bans, and "catch up or get left behind" to fellow engineers.
That doesn't sound like a nice place to work? Is all I'm saying.
To be clear, I use LLMs every day as part of my work pretty much entirely because my employer wants me to and has encouraged me to make them part of my workflow. They've managed to do that without anyone saying anything as aggressive as the parent commenter.
We prefer to hire on-shore junior engineers now, but their job isn’t just to just bang out grunt work Jira tickets. They own their work end to end and support it at every level. They get mentorship from seniors to move beyond coding and into systems and architecture level thinking. That’s the job now.
> Zero tolerance
> We’re a business not a daycare
Okay man, I'm sure it's great.
I don’t know why I can’t rely to the person below me so I’m editing:
We don’t admonish. It’s a mission statement and an up-front mutual understanding by all parties that you own your work end to end and you are accountable for it. You don’t even get an interview if you don’t agree. People that are offended by it don’t even bother applying. Excellent filter.
This doesn't make sense - AI is to allow unskilled people to produce what was previously only produced by skilled people.
IOW, how does having 2 years of experience using an LLM to generate code beat having 2 months of experience?
The whole point of using the LLM is that very little skill is involved; how does starting earlier with it provide an advantage? If it's as good as it is claimed to be, starting later with it won't make a single iota of difference to the generated results, compared to someone who started earlier.
Yeah, but it's a trivial skill that the people who learned it took maybe a week to learn it.
Unless LLMs never improve, the odds are good that even less time would be needed to get up to speed in a 2030 SOTA.
I mean, the whole reason for LLM usage is to produce something with little to no skill needed. That's literally what they are designing it for.
So it's unlikely that having a headstart using LLMs leads to any advantage.
I developed a system to help prepare for leet coding interviews so I never feel lost under pressure solving a problem again. It is like a debugger that steps through the code showing all the values of all the variables with data visualizations that reflect the logic so I can grok what it is doing. [0]
After I had the Claude build it, I started looking at the values and there were some mistakes. So, again, the coding agent ran all the code, recorded all the values, and made sure that they line up.
Here is the really cool thing about that. The coding agents can't be trusted. By observing the values stepping though, what I really was doing was debugging coding agent code. It is debugging code presented in a way that is extremely simplified.
What I've been thinking about yesterday and today is, can I do the same thing with a pull request? Have the coding agent run the code, capture all the values, and create a console for the reviewer to step through looking at with data visualizations that abstractly represent that code.
Two things. 1. Coding agents can't be trusted and 2. reviewing code is very difficult. But is it possible to use coding agents to make reviewing code easy for humans? I think so.
That would be a great way for junior engineers to be extremely useful. They only have to step through the code and make sure that all the values line up.
Yesterday claude code built a console that steps through algorithms: one shot. There was a bug with a value being incorrect. I thought this would be a great way to automated visualizing and stepping through code during a PR review.
I'm sitting in a room with a computer by myself where I was thinking yesterday about a way that AI can add value to junior engineers. I see a post and discussion about junior engineer's value so I shared what I'm think and working on.
Hopefully I'm contributing to the conversation here and I can get feedback good or bad about how to approach improving junior engineer's value.
If anything will be missing from juniors it will be the ability to run code in their heads if they've only written code via AI.
In a fraction of time it takes me to solve any 20 - 40 line code problem, a coding agent can solve it 10 different ways in python and in TypeScript, inject performance logging, run each in 1,000,000 iterations with as many permutations as inputs, write comments at a 10th grade reading level so I understand what each does quickly, make a clean table with pros / cons and performance results, and I after considering the options choose one.
The problem is that the coding agents are not dependable -- they are reliably incorrect.
In the United States decades ago, a phone utility company was sued because they didn't allow women to be linemen working in the field. They lost and what they did was make changes like using lighter aluminum ladders getting rid of the heavy wooden ones, they replaced the wrenches with ones with longer handles so they had much more leverage, and many other things to make the work less physically punishing. A reporter asked some of the veteran linemen how they feel about working with the changes. The reply was, "why didn't we make these changes sooner?" None of them lost their job and their job got a whole lot easier.
The problem is verifying code quality. The coding agents can't reliably do it. But they as tools, can help both juniors and seniors make their job a whole lot easier.
So, interns can still produce some value. How much value?
> In our product, there was a feature which had been requested for years, but had not been built yet. It wasn’t overly complex, but it was not critical.
Said another way: The feature was of so little value that it was not even worth assigning to a non-AI-assisted intern! This is what most of us mean when we say “AI lowers the value of…”
You're right that pre-AI that feature would not have been given to an intern (because they wouldn't be able to own it). So pre-AI, customers had a problem, we paid the intern, but could not solve the problem. Post-AI, the same problem exist, we pay the same intern. The customer problem is solved.
The article shows that the market value of the intern is lower: Work was not prioritized and given to a higher-cost junior engineer.
> … pre-AI that feature would not have been given to an intern (because they wouldn't be able to own it)…
Meaning, a more-skilled, higher-cost employee would have to do some or all of the work.
Edit: Another meaning of “worth” is a “intrinsic value”. Humans have worth in this sense.
This is it.
Evolving into a developer role was more or less directly proportional to the effort you put in. Before AI I used to ask applicants to the department I oversaw whether they have a GitHub Account with a project to show, and bonus, which they are immensely proud of, no matter what.
You had to grind and hustle, no shortcuts, and no amount of stackoverflow.com copy and paste could save you.
And that leads me to two problems for the disguise of one: effort. This not only means reading and redoing simple exercises to complex projects, but committing to it instead of doom scrolling or TikTok frenzy.
I reserved weekends for certain technical books and was frustrated, that there was so few time and so much book left.
AI gave instant gratification a new dimension. It is horrible until AI gets as good as a perfect project from a prompt or we need to abandon it.
Poor young guys, the joy of tuning out is over either by design or habit.
And make no mistake. I don't blame them. We are all victims and perpetrators at the same time but on a different level.
Getting close to it with my recent test of cursor cloud workflow.
I've spent 300M tokens in a day and it achieved what I wanted. Manually would take me a month instead of day so it's not 2x it's 20x faster but project was quite simple rewrite of 20k lines of C++ and there was reference implementation. It also improved on original implementation perf wise.
The problem is with fuzzy ideas for new development and with catching up with comprehension when working on something new - I guess we need better visualization tools for code. Product manager work seems like bottleneck currently and monitoring because coding can move quite fast.
There is still room for juniors… in fall of 2026. Will there be in fall of 2030? If your thesis rests on LLMs and AI systems not dramatically improving over where they are today, is it worth anything?
Now, you could argue that those were days when people moved jobs a lot less, so a junior was an investment for the company, even if they weren't worth their salary yet. And that's true to at least some degree. Still, that means that what changed isn't the value of juniors, but companies' willingness to invest in the future.
This same work that ai agents already do better. Now only the top juniors are really still worth it, the ones with more nebulous ownership, communication, synthesis, drive skills. And even these I think are on their way to being consumed by ai, unless the curve flattens (totally possible too). I think my only point is that the world is moving so fast that so many “optimistic about the field” posts I see basically assume we’ve reached the end of ai agent and system capabilities. If we have then great. But I find it a really unlikely bet.
They use it like a crutch and are unable to think critically or do tasks manually.
I wouldn't want to hire anyone to my team with that deficiency.
This article is wrong.
I trust junior + claude significantly less than I trusted pre-AI juniors. I do not think it will age well to put so much pressure on juniors to make contributions early and with mostly automated mentorship before they really understand what they are doing and why.
In a world where code can be generated rapidly, it's super critical that you have a core few set of people who really understand the macro design of the codebase and can continue to factor it well and iterate quickly.
Adding more people and contributors just increases the probability that nobody really understands the structure of the codebase, it degrades into DRY and unfactored slop.
The cost of reviewing other people's code is almost too high to be worthwhile now... It's much easier to just cut them out and do it yourself.
A core set of very skilled people can just implement whatever change you are doing, but better, cleaner and faster.
I built a fairly large and complex project with Codex and had to spend about 50% of the time factoring things down as I went into well contained modules, had a full understanding of the architecture at a high level. It would have been pretty difficult to do this if bringing in other contributors.
Too many people comment about AI from the perspective of throwing feature A or B over the wall at the workplace, but anybody who has built a huge project from scratch will see how important good design is in regard to iteration speed and result quality.
That being said, there are still areas where changes should be sized reasonably and human reviewed e.g. foundational or very mature software
Reviewing 100 lines of Junior dev slop was bad enough. Now 1000 lines of misguided jr dev ai slop?
Ugh.
That deserved a real answer, so I wrote this post. Short version: that describes a problem with how the role is structured, not what juniors can do. Push back welcome.
if it's product led - and every engineer no matter the level are supposed to understand the business and the requirements that drive value i.e create their own tickets etc - then yeah the value of the junior engineer stays the same or goes up.
with other orgs - where product managers act like high priests and everything has to go through Jira. then the value of not just junior engineers but engineers in general has been always at an all time low.