[gloxkiqcza]

Copying my comment from above:

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.

[tym0]

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.

[gloxkiqcza]

> 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.