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.
"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."
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).
It's a catch-22 because juniors need AI to be competitive, but you need to do the grunt work yourself for a few years before you really build the skills necessary to advance. I can't imagine learning how to do math by simply reading a solution book.
You cannot speed run human learning. Investing time to read and absorb the material, repeatedly exercising and expanding your understanding, is the only path.
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.
I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.
"Understanding" someone else's solution is not comparable to solving it on your own, even if you can answer some questions about it. It builds extremely fragile surface-level understanding.
That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.
Yes, all learning takes practice, it's the core of how our brain learns things. Any tool that eliminates the practice part means suboptimal, or zero, learning. Practice isn't just for physical tasks like riding a bike. All skills take practice, meaning repeated cycles of failures over a long time horizon.
>It used to be that they would have been forced to seek help from a senior engineer
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.
Yeah, I can’t imagine having something “weeks or months” late without intervention. That isn’t a failing of AI or the junior, that’s a failing on the team processes/manager/everyone else on the team.
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'.
I once (before ai) had a junior waste two months trying and failing to make a relatively simple change. As it turns out she it never occurred to her that she might want to copy the newly compiled executable ("it's the thing visual studio builds for you when you press build!" I had to explain this) to the server she was trying to run it on. So she never once managed to execute her changed code, which kept degrading as more and more changes accumulated trying to "fix" it
> “…they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. […] the ones who still interact with seniors to get help and actually learn.”
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.
The only time you really need to look at core dumps of a FORTRAN compiler is when you think the compiler has a bug. Apart from that, the abstraction doesn't leak. You don't need to know any details of the CPU to debug what is going on, every compilation you do is deterministic and has a predictable outcome. When you make a change, you should be able to predict the exact outcome. Don't like it? Reverse the change, and you're exactly where you were before. I've coded on a few machines I've never bother to learn what the metal does. It is always like this, and it's fine.
LLMs are nothing like that. Like FORTRAN the LLMs make you feel like they've abstracted you from the code. But you can't get by exclusively feeding instructions to an LLM. The OP made was making that point when he said "When AI can’t solve it, they just keep trying and failing". When your only undo is to say "fix the mess you just created", you can't replay instructions you gave yesterday to give you the same result, and you can't even say "explain what you did" and expect to get a reliable answer, there is no out. You have to look at the code.
When the abstractions leak badly, you have to learn both the abstraction and the thing it's trying to simplify. They are little better than macros that save you typing. An LLM is a very leaky abstraction.
This analogy only works if you’re ready to commit _only prompts_ and have those prompts do a clean “compile” of your production runtime everytime you pull.
It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt.
FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code.
Mutating the docs then leads to mutations in the code.
Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet?), and ymmv. Everyone is still figuring out the best practices I think.
Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P
The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there"
The interesting thing in all of this to me is what must happen for the same spec to be deterministically certain to generate the same software. Could you delete the code, regenerate from docs alone, and trust the result? And obviously.... not yet. In practice, workflows drift, sometimes you patch the code directly because it's faster, and now code and docs have not been properly updated.
But the entire flow and concept of: [Spec] -> [AI/Harness] -> [Finished software], and how we increasing determinism in that flow, is just immensely interesting to me.
But what’s interesting now is that the degree of determinism is increasing, as the community as a whole keeps refining the individual parts. The importance of spec becomes more obvious when the feedback loop speeds up, from spec to running software. That already made a huge difference in how many think about spec. There are multiple GitHub projects that are "spec only," where the goal is to spec it out in such a way that the software one wants is the inevitable result, if you just input the spec into a AI/harnes.
And the AI gets better, and the harnesses get better. So at some point we probably live in a reality where we can say: "If you spec out the software you want in this specific way, and add in these guidelines in AGENTS.md, and use X AI with Y harness, you almost certainly get identical software out the other end".
And yes "almost" is faaaaar from "always identical output". But the fact that we are even in the game of increasing determinism, in the Spec->AI->Software flow, is just mind-blowingly cool to me.
That is a detour from my main point, though, that on one specific level of analysis (can we move up one level of abstraction and lose some detail understanding, but gain more in productivity), AI, compiler, software frameworks, are all examples of the answer being: Yes.
And I do agree that we need to mitigate the damage that people with less experience can do because they don't know what pitfalls to avoid. But I would rather we focus on fixing that by improving the AI and harness, than the people that just keep saying that "AI is bad". In the same way I would rather make a tractor safer to use, not just complain that it's dangerous because someone drove it into the lake. Because the goal is not to make the perfect deterministic output from a compiler. that's just a step towards the real goal, which should, in my mind, be to help other people solve problems and do useful stuff. In the same way that the goal of the tractor is not to just plow the field, but to plow the field as fast and efficiently as possible so we can feed ourselves.
Wall of text because this topic has been bothering me for a while now, and Im using this thread to sort out my own thinking on it.
> you almost certainly get identical software out the other end
I think you'd get a set of convergent solutions, where the actual implementations might be very different.
This also explains why you might want to keep more artifacts than just the design. There might be different performance overall, or interesting properties/side effects on axes that were not defined in the spec.
Possibly -at the limit- a theoretically 'perfect' spec would be 100% deterministic (eg. by defining the final object code down to the bit) but that wouldn't be a useful operation I don't think?
The other approach to getting bit-perfect output would be to aim for deterministic model runs. But this has numerous issues including making the model less "creative" or "smart" and anyway might not be the thing you actually want (to wit: a working artifact) .
I think your FORTRAN analogy depends on the assertion that a design doc is some kind of technical abstraction, like a compiler or a for-loop. And there's a lot of disagreement with that premise. :)
See my response to the other comment if you don't understand that analogy is not the same as "identical".
And to state that "This analogy only works if ...." is just PATENTLY wrong. The analogy works fine if you say that it compares analogous situations. Like if we focus on some encumbrance complaining that "kids these days are too stupid because they don't understand the fundamentals like I do" or "These new tools that make it easier for stupid people, not smart people like me, to make stuff is dangerous because they don't know what they are doing". That's just a few of MANY analogous observations we can make for the two situations. But I guess you think that only the thing you care about is the only thing that exists.
And in the end, everybody who complains like this is just going to be shown to be just as mistaken as all the people who complained that "people who don't code in assembly are dangerous!" And it's just marvelous to watch it play out slowly over the last couple of years. And we are just a couple of years in. I'm just making a note of everybody who is mistaken, as a study in denial and biased thinking. The end for all of this was obvious after Opus 4.6 hit. And it's just getting more and more obvious with each model release and harness improvement. This is a gold mine for studying flawed thinking.
Many folks that publish papers on SIGPLAN, ACM and IEEE have a different opinion, you can find several papers on the use of machine learning on compilers, and direct machine code generation research.
It depends on the level of analysis. Both change the abstraction level one works at. So if you can't decode the message, I can do it for you. People believed that something important was lost by moving up one abstraction layer, because knowing the lower-level details was important, more so than having the possibility of doing more because complexities have been abstracted away for you.
And almost every time in history this conflict has arisen, the stubborn people who want to stick to the "everybody should stay at the level of abstraction that I want to stay at!" have been proven wrong.
So if you don't see the comparison, you lack imagination. It's the same comparison Torvald Linus made, and even though all the rabid anti-AI people try to deny that it's a valid comparison by willfully misunderstanding the comparison, it's perfectly valid.
And I find both the article and the comment I responded to either ignorant of history, and worse than uninsightful, because they are just patently, historically, logically, and empirically wrong.
And I'm getting tired of the arrogant senior devs, that are not a fraction as useful as they think they are, whining and complaining at younger people who are creating imperfect but useful work with AI.
While the tools for AI coding are just exploding. How can you people say stuff like "They learn nothing" with a straight face is beyond me. I see people daily who use AI to solve problems and learn something in the process.
I am having such a blast over the last couple of years seeing how AI development just relentlessly disproves the claims from bitter old developers who don't want to be forced to do anything useful. And when the transition is complete, the gatekeepers will be gone, and we will be left with people trying to solve real problems.
Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall.
While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?”
Edit insertion for clarification: The compiler, framework usage, AI usage, are all tools and patterns for generating code. And they all stay neatly inside the technology, and more specifically the dimention of "creating code".
Not relevant to the topic I was responding to tho. And project management is usually way harder than coding, with or without AI. At least if you measure it by how few people are able to do each well.
> 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.
I think the fear is that the "higher" paying webdev jobs will be drying up while those traditional industries you mentioned still have the need for developers but auto, medical, and weapon industries never paid well.
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.
Nope, whatever the customer hires us for, webdev, distributed systems, desktop, mobile, consulting on architecture, whatever makes them happy and gets us a contract.
I'm in Medical Devices and while AI is at best a small part of development right now, rest assured that we are actively investigating how to make it an approved part of our process. Then again, coding was only ever a small part of our job.
Of course not, but consider the size of the field if the “webdev” stuff goes away. Competition for the remaining positions in other domains become more competitive and you may find the floor rising faster than you can? Or you’ll find that weak, but cheap heuristics will throw you out with the chaff.
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”.
> Code reviews are going away because agents handle it.
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.
Every additional level of abstraction in computers has resulted in bloat that makes software less efficient and more bloated. AI is merely continuing to accelerate the tread.
The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.
> We do architecture reviews now. Code reviews are going away because agents handle it.
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?
Jesus, this rant is so eerily similar to one I read 25 years ago when someone explained why they stopped using C and started using C++ that I wouldn't be surprised to find that you are the same one who was complaining back then.
> Code reviews are going away because agents handle it.
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.
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.
Ownership of something you have little control over is a great way to burn yourself out.
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.
> 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
Oh.
You just described my last couple of jobs
I guess that partly explains why I've been miserable and exhausted all the time
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.
> 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.
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.
I can't imagine what level of monkeys you've been working with when you can't even imagine a human writing better docs than Claude. Disturbing, frankly.
> You just don't know how to harness it with the right context maybe.
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.
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.
> 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.
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'm having a hard time justifying writing any code today.
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.
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)
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.
> 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.
"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."
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.
> It is horrible until AI gets as good as a perfect project from a prompt or we need to abandon it.
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.
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?
The real value of a junior engineer is that they will become a senior. That's really always been the case IME. Juniors in the first year or two of their career are routinely a net negative, maybe break even. But the thing is, unless you're making the bet that LLMs are going to _entirely_ replace human SWE, we as an industry have to maintain a pipeline to take in juniors and level them up. If we don't, we're going to be in real trouble in about 10 years.
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.
In 2020 they could code to decent feature specs and handle simple features end to end. They could maintain the dashboard as features shipped and fix specific valuable but straightforward bugs. At least, the ones hired at any company I’ve worked for.
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.
Not sure about that, I have seen hiring frozen, as smaller teams can deliver more, and most of the tasks one could give juniors like cleaning up code, documentation, unit tests, and co, are now basically automated.
I think reducing junior value to something like time to first merge is playing with fire. Semblance of value is not value, and the value increase here, if there is any, is from the AI.
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.
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.
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
That makes sense from an engineering perspective, but from a business perspective you don't want the understanding to live in the heads of a small team of people. Companies own the codebase, they don't own their employees. If losing a single employee means losing the understanding for a significant chunk of the codebase, that's a serious risk. With the senior/junior model where you have a senior engineer architecting the system and a small team implementing that architecture, the understanding lives in the senior engineer's head, but it also lives in the head of the person who implemented it, and their teammates who implemented the parts that interact with it and were present for the discussions probably have enough knowledge to figure it out pretty quickly, so as long as the company doesn't lose the whole team all at once they're okay. If you make the team more productive with AI tools you can have the team do more, which still cuts down the total headcount, if to a lesser degree, but preserves the redundant understanding.
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.
"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."
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).
It's a catch-22 because juniors need AI to be competitive, but you need to do the grunt work yourself for a few years before you really build the skills necessary to advance. I can't imagine learning how to do math by simply reading a solution book.
So how do you design a harness that tries to grow the user? As in quiz the prompter in a way that forces them to reflect and improve?
And if they can do that- could they do it to themselves- going from a junior to a pro conversation?
You cannot speed run human learning. Investing time to read and absorb the material, repeatedly exercising and expanding your understanding, is the only path.
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.
You don't understand math with a calculator; you use paper to understand math.
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.
My grandfather used to say 'any power tool can be a sander, if you use it wrong'.
you revoke their claude/chatgpt/copilot license
You can't, as that removes the main value add of the AI.
I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.
"Understanding" someone else's solution is not comparable to solving it on your own, even if you can answer some questions about it. It builds extremely fragile surface-level understanding.
That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.
Yes, all learning takes practice, it's the core of how our brain learns things. Any tool that eliminates the practice part means suboptimal, or zero, learning. Practice isn't just for physical tasks like riding a bike. All skills take practice, meaning repeated cycles of failures over a long time horizon.
We're way too far down this current UIUX disaster to pretend "sane defaults" is a nice-to-have.
From what I can tell, the value add for AI seems to be this behavior you're describing
But the value add being marketed is something entirely different, which is where the disconnect is coming in
>It used to be that they would have been forced to seek help from a senior engineer
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.
Yeah, I can’t imagine having something “weeks or months” late without intervention. That isn’t a failing of AI or the junior, that’s a failing on the team processes/manager/everyone else on the team.
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'.
I once (before ai) had a junior waste two months trying and failing to make a relatively simple change. As it turns out she it never occurred to her that she might want to copy the newly compiled executable ("it's the thing visual studio builds for you when you press build!" I had to explain this) to the server she was trying to run it on. So she never once managed to execute her changed code, which kept degrading as more and more changes accumulated trying to "fix" it
> “…they aren’t being taught and they’re not learning from what the AI is producing because they don’t understand it. […] the ones who still interact with seniors to get help and actually learn.”
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.
I work at a workplace where the seniors use AI, and I am chastised for asking questions. I end up using the AI as a learning tool instead.
[flagged]
You are equating n LLM's output with FORTRAN?
The only time you really need to look at core dumps of a FORTRAN compiler is when you think the compiler has a bug. Apart from that, the abstraction doesn't leak. You don't need to know any details of the CPU to debug what is going on, every compilation you do is deterministic and has a predictable outcome. When you make a change, you should be able to predict the exact outcome. Don't like it? Reverse the change, and you're exactly where you were before. I've coded on a few machines I've never bother to learn what the metal does. It is always like this, and it's fine.
LLMs are nothing like that. Like FORTRAN the LLMs make you feel like they've abstracted you from the code. But you can't get by exclusively feeding instructions to an LLM. The OP made was making that point when he said "When AI can’t solve it, they just keep trying and failing". When your only undo is to say "fix the mess you just created", you can't replay instructions you gave yesterday to give you the same result, and you can't even say "explain what you did" and expect to get a reliable answer, there is no out. You have to look at the code.
When the abstractions leak badly, you have to learn both the abstraction and the thing it's trying to simplify. They are little better than macros that save you typing. An LLM is a very leaky abstraction.
This analogy only works if you’re ready to commit _only prompts_ and have those prompts do a clean “compile” of your production runtime everytime you pull.
Are you ready to do that?
It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt.
FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code.
Mutating the docs then leads to mutations in the code.
Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet?), and ymmv. Everyone is still figuring out the best practices I think.
Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P
The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there"
The interesting thing in all of this to me is what must happen for the same spec to be deterministically certain to generate the same software. Could you delete the code, regenerate from docs alone, and trust the result? And obviously.... not yet. In practice, workflows drift, sometimes you patch the code directly because it's faster, and now code and docs have not been properly updated.
But the entire flow and concept of: [Spec] -> [AI/Harness] -> [Finished software], and how we increasing determinism in that flow, is just immensely interesting to me.
Right, but hasn't generating the perfect spec always been the _exact_ problem of software development, regardless of language / LLM interface?
Yes, I agree with this fully.
But what’s interesting now is that the degree of determinism is increasing, as the community as a whole keeps refining the individual parts. The importance of spec becomes more obvious when the feedback loop speeds up, from spec to running software. That already made a huge difference in how many think about spec. There are multiple GitHub projects that are "spec only," where the goal is to spec it out in such a way that the software one wants is the inevitable result, if you just input the spec into a AI/harnes.
And the AI gets better, and the harnesses get better. So at some point we probably live in a reality where we can say: "If you spec out the software you want in this specific way, and add in these guidelines in AGENTS.md, and use X AI with Y harness, you almost certainly get identical software out the other end".
And yes "almost" is faaaaar from "always identical output". But the fact that we are even in the game of increasing determinism, in the Spec->AI->Software flow, is just mind-blowingly cool to me.
That is a detour from my main point, though, that on one specific level of analysis (can we move up one level of abstraction and lose some detail understanding, but gain more in productivity), AI, compiler, software frameworks, are all examples of the answer being: Yes.
And I do agree that we need to mitigate the damage that people with less experience can do because they don't know what pitfalls to avoid. But I would rather we focus on fixing that by improving the AI and harness, than the people that just keep saying that "AI is bad". In the same way I would rather make a tractor safer to use, not just complain that it's dangerous because someone drove it into the lake. Because the goal is not to make the perfect deterministic output from a compiler. that's just a step towards the real goal, which should, in my mind, be to help other people solve problems and do useful stuff. In the same way that the goal of the tractor is not to just plow the field, but to plow the field as fast and efficiently as possible so we can feed ourselves.
Wall of text because this topic has been bothering me for a while now, and Im using this thread to sort out my own thinking on it.
> you almost certainly get identical software out the other end
I think you'd get a set of convergent solutions, where the actual implementations might be very different.
This also explains why you might want to keep more artifacts than just the design. There might be different performance overall, or interesting properties/side effects on axes that were not defined in the spec.
Possibly -at the limit- a theoretically 'perfect' spec would be 100% deterministic (eg. by defining the final object code down to the bit) but that wouldn't be a useful operation I don't think?
The other approach to getting bit-perfect output would be to aim for deterministic model runs. But this has numerous issues including making the model less "creative" or "smart" and anyway might not be the thing you actually want (to wit: a working artifact) .
I think your FORTRAN analogy depends on the assertion that a design doc is some kind of technical abstraction, like a compiler or a for-loop. And there's a lot of disagreement with that premise. :)
See my response to the other comment if you don't understand that analogy is not the same as "identical".
And to state that "This analogy only works if ...." is just PATENTLY wrong. The analogy works fine if you say that it compares analogous situations. Like if we focus on some encumbrance complaining that "kids these days are too stupid because they don't understand the fundamentals like I do" or "These new tools that make it easier for stupid people, not smart people like me, to make stuff is dangerous because they don't know what they are doing". That's just a few of MANY analogous observations we can make for the two situations. But I guess you think that only the thing you care about is the only thing that exists.
And in the end, everybody who complains like this is just going to be shown to be just as mistaken as all the people who complained that "people who don't code in assembly are dangerous!" And it's just marvelous to watch it play out slowly over the last couple of years. And we are just a couple of years in. I'm just making a note of everybody who is mistaken, as a study in denial and biased thinking. The end for all of this was obvious after Opus 4.6 hit. And it's just getting more and more obvious with each model release and harness improvement. This is a gold mine for studying flawed thinking.
LLMs are not even remotely comparable to compilers. This attempt at analogy is neither humorous nor insightful.
Many folks that publish papers on SIGPLAN, ACM and IEEE have a different opinion, you can find several papers on the use of machine learning on compilers, and direct machine code generation research.
It depends on the level of analysis. Both change the abstraction level one works at. So if you can't decode the message, I can do it for you. People believed that something important was lost by moving up one abstraction layer, because knowing the lower-level details was important, more so than having the possibility of doing more because complexities have been abstracted away for you.
And almost every time in history this conflict has arisen, the stubborn people who want to stick to the "everybody should stay at the level of abstraction that I want to stay at!" have been proven wrong.
So if you don't see the comparison, you lack imagination. It's the same comparison Torvald Linus made, and even though all the rabid anti-AI people try to deny that it's a valid comparison by willfully misunderstanding the comparison, it's perfectly valid.
And I find both the article and the comment I responded to either ignorant of history, and worse than uninsightful, because they are just patently, historically, logically, and empirically wrong.
And I'm getting tired of the arrogant senior devs, that are not a fraction as useful as they think they are, whining and complaining at younger people who are creating imperfect but useful work with AI.
While the tools for AI coding are just exploding. How can you people say stuff like "They learn nothing" with a straight face is beyond me. I see people daily who use AI to solve problems and learn something in the process.
I am having such a blast over the last couple of years seeing how AI development just relentlessly disproves the claims from bitter old developers who don't want to be forced to do anything useful. And when the transition is complete, the gatekeepers will be gone, and we will be left with people trying to solve real problems.
Do you feel that layers of abstraction in project management and layers of abstraction in the technology being managed are the same thing?
Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall.
While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?”
Edit insertion for clarification: The compiler, framework usage, AI usage, are all tools and patterns for generating code. And they all stay neatly inside the technology, and more specifically the dimention of "creating code".
Not relevant to the topic I was responding to tho. And project management is usually way harder than coding, with or without AI. At least if you measure it by how few people are able to do each well.
> While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?”
Those sound dangerously close to project management decisions. What about tech layers closer to coding?
I don't see that at all. These look like typical decisions that a technical team lead would make and then inform project management of the decision.
So correct me if I'm wrong, but it seems like you're saying the abstraction layers are asking these lines:
Assembly->C->LLM, used by tech lead
[dead]
> 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.
Is all of hackernews webdev only? I can’t imagine “coding not being a job anymore” in fields like automotive, medical, military, robotics, and HPC
I think the fear is that the "higher" paying webdev jobs will be drying up while those traditional industries you mentioned still have the need for developers but auto, medical, and weapon industries never paid well.
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.
Nope, whatever the customer hires us for, webdev, distributed systems, desktop, mobile, consulting on architecture, whatever makes them happy and gets us a contract.
I'm in Medical Devices and while AI is at best a small part of development right now, rest assured that we are actively investigating how to make it an approved part of our process. Then again, coding was only ever a small part of our job.
Of course not, but consider the size of the field if the “webdev” stuff goes away. Competition for the remaining positions in other domains become more competitive and you may find the floor rising faster than you can? Or you’ll find that weak, but cheap heuristics will throw you out with the chaff.
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”.
> Code reviews are going away because agents handle it.
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.
Every additional level of abstraction in computers has resulted in bloat that makes software less efficient and more bloated. AI is merely continuing to accelerate the tread.
The real issue at hand is that humans need to decide to start resource constraining AI before it consumes the entire world.
> We do architecture reviews now. Code reviews are going away because agents handle it.
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?
Jesus, this rant is so eerily similar to one I read 25 years ago when someone explained why they stopped using C and started using C++ that I wouldn't be surprised to find that you are the same one who was complaining back then.
Then does the original author own the changes you made to their PR, e2e? Do you get their signoff on them if that's the case?
> Code reviews are going away because agents handle it.
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.
"End to end ownership is the job."
This is an incredibly good and concise articulation of where the role is going. Thank you.
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.
Ideally, but we know that LLMs will get the blame because of course they will.
Only if the owner thinks that's a viable strategy. Such an owner may not be employed long.
Ownership of something you have little control over is a great way to burn yourself out.
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.
> 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
Oh.
You just described my last couple of jobs
I guess that partly explains why I've been miserable and exhausted all the time
[dead]
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.
> 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.
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.
"Software Engineer" is a thing.
Not here in Canada, nor many places where Engineer is a protected term.
Yes here in Canada, plenty of Software Engineers, P.Eng
Do you think software engineers just write code or something?
I would bet good money that the vast majority of people who have some variety of "software engineer" as their job title mostly just write code, yes
The concept of software engineer is so watered down at this point it often barely resembles engineering at all
In Canada engineering is a regulated term and if you aren’t licensed you can get in serious trouble calling yourself one.
source: I am licensed.
Yeah. My job title at work is technically Software Engineer and it makes me a little uneasy because I am not 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
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.
And even with that fable would be more capable than you. You just don't know how to harness it with the right context maybe.
I can't imagine what level of monkeys you've been working with when you can't even imagine a human writing better docs than Claude. Disturbing, frankly.
You need to take a step back from the "it's always better than you" because you're making objectively false statements based on delusion.
> You just don't know how to harness it with the right context maybe.
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.
Honestly it sounds like you don't know what you're talking about.
> 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.
Or, you know, just plain ol’ racism
TIL I’m (a Polish-Canadian) being racist because I don’t like the quality of the work Polish offshore developers my boss hired on the cheap.
Yeah, exactly.
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.
is it your business? do you own it?
Sure bud
[flagged]
You're far enough behind that you had to create a burner account to tell someone to self-harm.
is that supposed to be an insult or random angry words inspired by the labor of clicking a profile link
> created 5 minutes ago
lol
> 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.
The paradox of AI. The better it is the less benefit there is to being an early adopter.
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'm having a hard time justifying writing any code today.
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.
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)
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.
> 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.
"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."
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.
> It is horrible until AI gets as good as a perfect project from a prompt or we need to abandon it.
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.
AI didn't X, it Y. Where Y is write this post.
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?
The real value of a junior engineer is that they will become a senior. That's really always been the case IME. Juniors in the first year or two of their career are routinely a net negative, maybe break even. But the thing is, unless you're making the bet that LLMs are going to _entirely_ replace human SWE, we as an industry have to maintain a pipeline to take in juniors and level them up. If we don't, we're going to be in real trouble in about 10 years.
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.
In 2020 they could code to decent feature specs and handle simple features end to end. They could maintain the dashboard as features shipped and fix specific valuable but straightforward bugs. At least, the ones hired at any company I’ve worked for.
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.
Not sure about that, I have seen hiring frozen, as smaller teams can deliver more, and most of the tasks one could give juniors like cleaning up code, documentation, unit tests, and co, are now basically automated.
It's setting them up for absolute failure.
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 think reducing junior value to something like time to first merge is playing with fire. Semblance of value is not value, and the value increase here, if there is any, is from the AI.
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.
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.
So surely there's more demand to hire junior engineers and their salaries have gone up?
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.
This seems to point to a future crash where we run out of people with the skills to do the work.
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.
Such profound thought. Almost on the level of Hegel.
I see the complete opposite becoming the case.
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
That makes sense from an engineering perspective, but from a business perspective you don't want the understanding to live in the heads of a small team of people. Companies own the codebase, they don't own their employees. If losing a single employee means losing the understanding for a significant chunk of the codebase, that's a serious risk. With the senior/junior model where you have a senior engineer architecting the system and a small team implementing that architecture, the understanding lives in the senior engineer's head, but it also lives in the head of the person who implemented it, and their teammates who implemented the parts that interact with it and were present for the discussions probably have enough knowledge to figure it out pretty quickly, so as long as the company doesn't lose the whole team all at once they're okay. If you make the team more productive with AI tools you can have the team do more, which still cuts down the total headcount, if to a lesser degree, but preserves the redundant understanding.
We still need the good junior engineers.
And then the senior engineer burns the f#ck out.
Reviewing 100 lines of Junior dev slop was bad enough. Now 1000 lines of misguided jr dev ai slop?
Ugh.
Just have claude review it.
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.
I'm tired of being told what things aren't or what they don't do.