It largely depends on the person. We have several junior engineers who cannot solve a problem without AI. When AI can’t solve it, they just keep trying and failing. And I mean weeks to months late. Then rinse and repeat on the next task. It used to be that they would have been forced to seek help from a senior engineer. Combine the teaching with a real struggle is what makes them better.
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 direction many engineers (seniors included) are facing if they mostly rely on AI. You lose your skills, you become detached. We will all become 'architects'.
It largely depends on the person. We have several junior programmers who cannot solve a problem without FORTRAN. When the compiler can't produce efficient code, they just keep recompiling and failing. And I mean weeks to months late. Then rinse and repeat on the next routine. It used to be that they would have been forced to seek help from a senior programmer who knew the machine. Combining the teaching with a real struggle at the console is what made them better.
As it is now, they aren't being taught, and they're not learning from what the compiler is producing because they don't understand it. The emitted object code is a black box, and the compiler itself is a black box too. All they know is that running it produces something like what they asked for. They have no idea about register allocation or instruction timing, which is a fundamental concept of programming. The worst part is that automatic programming is covering up their deficiencies. They don't know what skills they lack. They don't even know octal exists, because they haven't put the effort in.
There are obviously good junior programmers who use FORTRAN judiciously and still read their core dumps. They're the ones who still interact with the senior operators and actually learn the machine. They would have been successful with a plugboard too. In my experience, the momentum is moving toward the worse type of junior the more automatic programming is adopted. Unless that changes, it will erase their value.
> The junior engineer executes it, which nowadays means prompting it to an AI tool, and creating a pull request (PR).
The PR receives feedback from more senior engineers. The junior engineer gets the feedback and takes it to the AI tool again, proposing changes.
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.
Making changes to someone else’s PR (other than extremely trivial ones) feels like they don’t have much ownership. People often have a reason for doing things the way they did and skipping over them seems like a mistake.
We do architecture reviews now. Code reviews are going away because agents handle it.
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”.
Even if AI does the coding, I cannot understand the architecture of a change unless you split it in individual tasks that are "as small as possible but no smaller". And even if AI does the code review, the architecture review falls onto me.
Ownership of the delivered code. This takes authorship out of the equation -- doesn't matter who wrote it, only matters who owns it and can be blamed for it. Not having written it doesn't absolve blame when something goes bad.
This is something I've been thinking about the last couple days: how to get junior engineers to be valuable.
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.
Is this just an ad for the product? How is this connected specifically to junior engineers? Is it implying that they cannot debug code without this kind of tool while more experienced people can?
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.
I've dreamt about pernosco (rr) style traces being available for tests in PRs. Imagine a DST setup where the PR shows diffs of deterministic test execution traces (I have no idea what these diffs would look like)
I think it is less about junior/mid 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 do their work anyway.
Good riddance. Worked with many offshored firms before, from all over the world. The work was subpar before and it’s even worse now.
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.
Yes it is. It'll write a better doc at any level for any task you may do. If you're not able to see that, you just don't know how to give the context right.
> 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.
I basically only use Fable and no it isn’t. Might I suggest that if you think it is you’re just projecting your own insecurity on others. Coding isn’t engineering.
> 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.
You misunderstood my reply. I'm talking about culture, not engineering or coding.
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.
I don't think this is related to culture, it's just the internet nowadays. You need hot takes for engagement. That user probably runs with that mindset always on
Something not being the primary reason I'm paid does not imply that it's "solved". Personally, I enjoy working at a company where people have intellectual curiosity about varying viewpoints to ambiguous questions like "is coding solved?" rather than scolding people who don't adhere to the dogma as being "left behind".
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.
My company has excellent culture. Zero tolerance for slop, top to bottom. With or without AI, you own your work and you are accountable for it. We’re a business not a daycare for foreign contractors without useful skills.
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.
You’d be suprised how often people rise to the occasion when you don’t treat them like children.
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.
Treating people like adults means not admonishing them by saying things like "we're a business, not a daycare". Adults don't need to be informed that they're working a job because they already are aware. Talking down to people by saying things like that is pretty much the opposite of treating them like adults.
Every single time I see an article like this come out on hacker news I have the same reaction “sure, this year”.
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?
I'll take the other side of that. Was there room for juniors in 2020? In 1950? What was the value of a junior in a world where programming was done in assembly? How much reliable work - how much value - could you get from them? Probably less than their salary.
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 summer, we assigned the problem to an intern (that’s less tenure than a junior engineer). The intern led the development of this feature. They talked to the product manager to understand the problem and requirements. They wrote the design document on how to approach it, aligned with the team, and built it. Of course they did that with the help of AI, and the team they were working with.
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…”
Thanks. How do you think that lowers the value of an intern, can you explain it?
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.
> If the assumption is that AI is going to radically simplify the technical portion of the role, then the people who have started their careers with AI will be in the best spot once they have acquired the experience.
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.
I think it’s an oversimplification to say that using AI for se dev is a trivial skill. You can see it even now with some people chatting with Claude and others running multiple agents in a loop. There’s skill in that.
But I agree that now it’s something people can catch up. The point is that I think it will make a difference if you’re someone that never coded manually vs someone that is (un)learning after having a full career pre-AI. Is not much different that people who started working with computers and others who had to learn how to deal with them late in their career.
I'd say I'm in a better position by mostly ignoring AI so far - I haven't wasted any time or effort working out the current week's fashion in AI prompting methods that will be out of date by next week.
Sort of like how there's a running joke, "this meeting could have been an email"; I think that for all the substance I found in this "4 minutes to read" blog post, it could have been a one-sentence comment in some discussion thread somewhere instead.
When AI learns to only use concise, meaningful words instead of words for the sake of vomiting out more tokens, I suspect we’ll have finally achieved proper AGI.
If the task is simple enough that you can throw AI at it with an intern and get it solved, then it should've been solved already in the first place. I'd argue in more mature organizations all the things that are "backlog todos" are such because there is inherent complexity that can not be solved simply by throwing tokens at it or there are too many unknown unknowns.
I couldn't disagree more. Juniors have very poor design sense and can't guide the AI to land in the right spot. Consistently on my team the developers who are the most reliant on AI are causing me the most trouble. They produce a lot of code but constantly make the same mistakes and can't seem to learn and improve their own design skills, or are doing it at a snail's pace.
Author here. My last post on this reached the front page, and the main objection was that after AI, the junior's marginal value is gone: if a junior just passes specs to an AI tool and PRs back, why pay the salary?
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.
my take from this article - there's a point you miss. is the organization product driven ? because usually that changes how engineers solve or approach problems. a few organizations are product driven.
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.
If an intern can do the work of a technical lead, architect, software designer, or project manager, why do we need such expensive resources? Just fire all the seniors (including the CxOs) and let the interns run the company as lowest-paid temporary contractors, with the help of AI. /s
It largely depends on the person. We have several junior engineers who cannot solve a problem without AI. When AI can’t solve it, they just keep trying and failing. And I mean weeks to months late. Then rinse and repeat on the next task. It used to be that they would have been forced to seek help from a senior engineer. Combine the teaching with a real struggle is what makes them better.
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 direction many engineers (seniors included) are facing if they mostly rely on AI. You lose your skills, you become detached. We will all become 'architects'.
It largely depends on the person. We have several junior programmers who cannot solve a problem without FORTRAN. When the compiler can't produce efficient code, they just keep recompiling and failing. And I mean weeks to months late. Then rinse and repeat on the next routine. It used to be that they would have been forced to seek help from a senior programmer who knew the machine. Combining the teaching with a real struggle at the console is what made them better.
As it is now, they aren't being taught, and they're not learning from what the compiler is producing because they don't understand it. The emitted object code is a black box, and the compiler itself is a black box too. All they know is that running it produces something like what they asked for. They have no idea about register allocation or instruction timing, which is a fundamental concept of programming. The worst part is that automatic programming is covering up their deficiencies. They don't know what skills they lack. They don't even know octal exists, because they haven't put the effort in.
There are obviously good junior programmers who use FORTRAN judiciously and still read their core dumps. They're the ones who still interact with the senior operators and actually learn the machine. They would have been successful with a plugboard too. In my experience, the momentum is moving toward the worse type of junior the more automatic programming is adopted. Unless that changes, it will erase their value.
LLMs are not even remotely comparable to compilers. This attempt at analogy is neither humorous nor insightful.
> The junior engineer executes it, which nowadays means prompting it to an AI tool, and creating a pull request (PR). The PR receives feedback from more senior engineers. The junior engineer gets the feedback and takes it to the AI tool again, proposing changes.
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.
Making changes to someone else’s PR (other than extremely trivial ones) feels like they don’t have much ownership. People often have a reason for doing things the way they did and skipping over them seems like a mistake.
We do architecture reviews now. Code reviews are going away because agents handle it.
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”.
I agree. Although I think that was never the job. Even without AI, the practice of subdividing work into coding tasks was not a good one.
AI just made it obvious.
Even if AI does the coding, I cannot understand the architecture of a change unless you split it in individual tasks that are "as small as possible but no smaller". And even if AI does the code review, the architecture review falls onto me.
Ownership of what then?
Ownership of the delivered code. This takes authorship out of the equation -- doesn't matter who wrote it, only matters who owns it and can be blamed for it. Not having written it doesn't absolve blame when something goes bad.
[dead]
This is something I've been thinking about the last couple days: how to get junior engineers to be valuable.
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.
[0] https://adamsohn.com/algoviz/
Is this just an ad for the product? How is this connected specifically to junior engineers? Is it implying that they cannot debug code without this kind of tool while more experienced people can?
There is no product!
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.
I think this is good in general for being able to see what happens in the code of a PR, but probably more so to seniors.
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.
I've dreamt about pernosco (rr) style traces being available for tests in PRs. Imagine a DST setup where the PR shows diffs of deterministic test execution traces (I have no idea what these diffs would look like)
I think it is less about junior/mid 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 do their work anyway.
[0] https://thefederal.com/category/news/h1b-visa-indian-tech-wo...
Good riddance. Worked with many offshored firms before, from all over the world. The work was subpar before and it’s even worse now.
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.
Your boss isn't shortly going to say the same about you? Fable is better than you at engineering.
I basically only use Fable, and no it isn’t. Coding isn’t engineering.
Yes it is. It'll write a better doc at any level for any task you may do. If you're not able to see that, you just don't know how to give the context right.
Claude writes technical word salad that people hate reading. It’s writing docs nobody looks at and nobody cares about.
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.
"Software Engineer" is a thing.
Do you think software engineers just write code or something?
> 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.
I basically only use Fable and no it isn’t. Might I suggest that if you think it is you’re just projecting your own insecurity on others. Coding isn’t engineering.
> Good riddance.
> 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.
how do you mean? surely you're paid for delivering product not coding? if it is the latter, I too would love to be paid for recreational coding
You misunderstood my reply. I'm talking about culture, not engineering or coding.
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.
I don't think this is related to culture, it's just the internet nowadays. You need hot takes for engagement. That user probably runs with that mindset always on
That's fair. My internet bubble is intentionally very small.
Something not being the primary reason I'm paid does not imply that it's "solved". Personally, I enjoy working at a company where people have intellectual curiosity about varying viewpoints to ambiguous questions like "is coding solved?" rather than scolding people who don't adhere to the dogma as being "left behind".
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.
My company has excellent culture. Zero tolerance for slop, top to bottom. With or without AI, you own your work and you are accountable for it. We’re a business not a daycare for foreign contractors without useful skills.
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.
> My company has excellent culture.
> Zero tolerance
> We’re a business not a daycare
Okay man, I'm sure it's great.
You’d be suprised how often people rise to the occasion when you don’t treat them like children.
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.
Treating people like adults means not admonishing them by saying things like "we're a business, not a daycare". Adults don't need to be informed that they're working a job because they already are aware. Talking down to people by saying things like that is pretty much the opposite of treating them like adults.
Sure bud
is it your business? do you own it?
I was already far ahead so I didn't need to catch up. "left behind" lmao stick your head in a woodchipper pls
> created 5 minutes ago
lol
Every single time I see an article like this come out on hacker news I have the same reaction “sure, this year”.
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?
I'll take the other side of that. Was there room for juniors in 2020? In 1950? What was the value of a junior in a world where programming was done in assembly? How much reliable work - how much value - could you get from them? Probably less than their salary.
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 summer, we assigned the problem to an intern (that’s less tenure than a junior engineer). The intern led the development of this feature. They talked to the product manager to understand the problem and requirements. They wrote the design document on how to approach it, aligned with the team, and built it. Of course they did that with the help of AI, and the team they were working with.
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…”
Thanks. How do you think that lowers the value of an intern, can you explain it?
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.
> . How do you think that lowers the value of an intern
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.
> If the assumption is that AI is going to radically simplify the technical portion of the role, then the people who have started their careers with AI will be in the best spot once they have acquired the experience.
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.
I think it’s an oversimplification to say that using AI for se dev is a trivial skill. You can see it even now with some people chatting with Claude and others running multiple agents in a loop. There’s skill in that.
> There’s skill in that.
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.
But I agree that now it’s something people can catch up. The point is that I think it will make a difference if you’re someone that never coded manually vs someone that is (un)learning after having a full career pre-AI. Is not much different that people who started working with computers and others who had to learn how to deal with them late in their career.
I'd say I'm in a better position by mostly ignoring AI so far - I haven't wasted any time or effort working out the current week's fashion in AI prompting methods that will be out of date by next week.
Sort of like how there's a running joke, "this meeting could have been an email"; I think that for all the substance I found in this "4 minutes to read" blog post, it could have been a one-sentence comment in some discussion thread somewhere instead.
When AI learns to only use concise, meaningful words instead of words for the sake of vomiting out more tokens, I suspect we’ll have finally achieved proper AGI.
If the task is simple enough that you can throw AI at it with an intern and get it solved, then it should've been solved already in the first place. I'd argue in more mature organizations all the things that are "backlog todos" are such because there is inherent complexity that can not be solved simply by throwing tokens at it or there are too many unknown unknowns.
AI didn't X, it Y. Where Y is write this post.
I find it kinda funny how everyone has such divergent opinions of who AI benefits.
I couldn't disagree more. Juniors have very poor design sense and can't guide the AI to land in the right spot. Consistently on my team the developers who are the most reliant on AI are causing me the most trouble. They produce a lot of code but constantly make the same mistakes and can't seem to learn and improve their own design skills, or are doing it at a snail's pace.
I agree with the sentiment. But is that exclusive to junior engineers? Curious if you think that the same problem exists with senior engineers or not.
We still need the good junior engineers.
Such profound thought. Almost on the level of Hegel.
Author here. My last post on this reached the front page, and the main objection was that after AI, the junior's marginal value is gone: if a junior just passes specs to an AI tool and PRs back, why pay the salary?
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.
my take from this article - there's a point you miss. is the organization product driven ? because usually that changes how engineers solve or approach problems. a few organizations are product driven.
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.
That’s a good point. My whole career has been in product/tech led companies.
If an intern can do the work of a technical lead, architect, software designer, or project manager, why do we need such expensive resources? Just fire all the seniors (including the CxOs) and let the interns run the company as lowest-paid temporary contractors, with the help of AI. /s
They surely cannot. But they can own simple problems end to end.