One more thing to add: AI enhances capabilities of everyone, including juniors. Juniors with LLMs can do more than juniors without them could and therefore their value proposition is greater than before.
But they don't learn from that, they turn the crank of the AI tooling and once they have something that works it goes in and they move on. I've seen this directly, you can't shortcut actual understanding.
I disagree. LLM assisted coding is yet another level of abstraction. It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.
Today’s juniors still learn the same core skill, the abstract thinking and formalization of a problem is still there. It’s just done on a higher level of abstraction and in an explicitly formulated natural language instead of a formal one for the first time ever. They’re not even leaving out the formal one completely, because they need to integrate and fine tune the code for it to work as needed.
Does it introduce new problems? Sure. Does it mean that today’s juniors will be less capable compared to today’s seniors once they have the same amount of experience? I really doubt it.
>It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.
Not the same. Whether you are writing Assembly or Java, you have to determine and express your intent with high accuracy - that is a learned skill. Providing problem details to an LLM until it produces something that looks correct is not the same type of skill.
If that is the skill that the business world demands in 5 years, so be it, but arguing that it's simply the next step in the Assembly, C, Java progression makes no sense.
> Providing problem details to an LLM until it produces something that looks correct
If you're using LLMs to code like this, you're using them incorrectly. You need to specify your intent precisely from the start which is a skill you learn. You can use other tools like OOP languages incorrectly with "working" results as well, that's why code quality, clean code and best practices are a thing.
I'm sure many junior developers use LLMs the way you described but maybe that's exactly what the universities and seniors need to teach them?
You might, just as ages ago when people were complaining about juniors c+ping stack overflow answers you might have said you used them to learn from.
LLMs are a turbo charged version of the same problem, only now rather than copying a code fragment from stack overflow you can have an LLM spit out a working solution. There is no need to understand what you're doing to be productive, and if you don't understand it you have no model or reasoning to apply in the future to other problems, maybe AI will save you there too for a while, but eventually it won't and you'll find you've built your career on sand.
Or maybe I'm wrong and we're all headed for a future of being prompt engineers.
Generally the understanding happens fairly quickly just by glancing through the code.
I was a sceptic up until recently, where I failed to create a solution myself.
Since I am mostly a hobbyist programmer(for 25 years and counting) I often find I don’t have the time to sit down for prolonged periods to reason about my code.
ChatGPT helps my tired brain from work develop my code 10x quicker, easily, by removing road blocks for me.
Indeed. With AI juniors can create horrible software faster, and in bigger quantities. Based on my experience AI really only enhances your existing talent, and if you have none, it enhances the lack of it, since you still need to be able to know how your AI slop fits in the larger system, but if you're a junior you most likely don't know that. Couple that with skipping the step where you must actually understand what you copy and paste from the internet for it to work, you also lengthen the time it takes for a developer to actually level up, since they do much less actual learning.
That's at least my experience working with multiple digital agencies and seeing it all unfold. Most juniors don't last long these days precisely because they skip the part that actually makes them valuable - storing information in their head. And that's concerning, because if to make actually good use of AI you have to be an experienced engineer, but to become an experienced engineer you had to get there without AI doing all your work for you, then how are we going to get new experienced engineers?
I think what you’re describing is caused by the fact that people that would previously pursue law, medicine or some other high paying field now pursue software engineering because it pays well and is a pretty comfortable job overall.
The nerdy tinkerers stay the same and AI empowers them even more. Are they rare? Yes. But this shifts the topic from
science/engineering to economics/sociology. Granted, that was the topic of the original submission but for me that’s the less interesting part.
Remembering some PRs from before... It was always about how much attention to detail/quality the particular junior dev pays. Often times it’s not much at all which might be harder to notice now.
it seems pretty obvious to me that you grow as a programmer more from "sit down and write code to do a thing" than you do from "sit down, watch an LLM shit out code and give it a pretty cursory review"
I disagree. LLM assisted coding is yet another level of abstraction. It’s the same thing as an assembly programmer saying that OOP programmers don’t learn from OOP coding.
Today’s juniors still learn the same core skill, the abstract thinking and formalization of a problem is still there. It’s just done on a higher level of abstraction and in an explicitly formulated natural language instead of a formal one for the first time ever. They’re not even leaving out the formal one completely because they need to integrate and fine tune the code for it to work as needed.
Does it introduce new problems? Sure. Does it mean that today’s juniors will be less capable compared to today’s seniors once they have the same amount of experience? I really doubt it.
I'm not making any pronouncement about if LLM are good things or not for juniors but your OOP analogy doesn't track.
One can be confident that they wrote correct Java code without knowing what the JVM machine code output is. But you can't know if the code outputted by an LLM is correct without understanding the code itself.
> One can be confident that they wrote correct Java code without knowing what the JVM machine code output is
I'm sure there're some pretty major bugs in production code because someone used some Java functionality intuitively without understanding it fully and in some edge case it behaves differently than anticipated.
Of course this issue is much more prominent in LLM assisted coding but we're back to square one. The higher the level of abstraction provided by the tool, the more room for mistakes it leaves but the higher the productivity is. It's easier to avoid bugs of this type when using assembly vs when using Java.
Idk if I learned more from actually typing code or debugging and looking at the output/logs, sometimes even running code in my mind to figure out the problems. Maybe it's just "cursory".