Hacker News new | ask | show | jobs
by yellow_lead 491 days ago
Todays junior dev that is copying AI code without understanding it, is the same as the junior dev several years ago who did the same with stack overflow code.

This is a mindset, and I don't think AI code is changing the number of people with this mindset. What it may be doing though, is letting them get away with it for longer.

3 comments

This comparison of coding assistants to Stack Overflow comes up a lot so I feel like it needs to be addressed.

It is SIMILAR - it is not the same. There's a minimal element of interaction by virtue of the fact that SO code is usually not completely bespoke for the developer's requirements. They'll need to do things like change variable names, re-arrange some parts of it, etc.

The junior dev using an integrated LLMs (like with Cursor) has to do NONE of this. They simply hit the Tab key to accept and move on with their day.

There's a far larger danger of induced passivity.

Also, Stack Overflow regularly came with multiple solutions and comments on each solution discussing drawbacks and alternatives. I've learned a lot from those.
And a lot more likely to (often correctly) say "you should not do this thing".
I wrote another much longer comment but you summarized it nicely, there becomes a sort of learned helplessness that even experienced engineers will start experiencing, as I had when I used Cursor, because it's just much easier to continue pressing tab than to actually review every single change thoroughly, and that is where the danger lies, especially with subtle hallucination-induced bugs.
Since the StackOverflow code was not an identical perfect fit for the problem you had in mind, you still had to have some mental awareness to what you are doing. Now they can just go to Claude and "say I have this solution, and that problem, someone says this should fit into that, what do" and they get the glue inserted without gaining the basic understanding they'd get from putting the glue there themselves.
Agreed. I'd say there is a ladder to the cognitive aspect of writing code.

1. Constructing an algorithm yourself from first principles, then implementing it. Let's call this "architect level"

2. Reading someone else's description of an algorithm (from a textbook, a blog post, etc.) and implementing it yourself. "Senior dev level"

3. Starting with an existing implementation, treating certain parts of that implementation as a blackbox, but adapting other parts. (e.g. a StackOverflow solution doesn't have a cache, but you need one for performance and add one yourself) "Junior dev level"

4. Copying/pasting with minimal modification. (e.g. ChatGPT gives you a solution that doesn't have a cache. You reprompt it, asking it to add a caching strategy. Your contribution is correcting some names or parameter order and adding some glue code. The main insight you gain here is how to drive ChatGPT, not how the code itself functions.)

Can today's new devs climb from rung 4 to rung 3? If the answer is yes, then maybe nothing has fundamentally changed. If it's a no, then we may be in for trouble 10 to 15 years down the road.

There is a rung 5, using an idea integrated with an LLM agent, like Cursor or Windsurf. It becomes trivially easy to simply prompt it for features or bugs and to tab through the changes it makes to your codebase such that you don't even have to do any copy pasting at all.
Came here to say this. It’s rare that you can blindly copy/paste an SO answer. Sometimes it looks like you can but then it doesn’t work and you have to not only carefully read the answer but then also fill in the missing pieces with information elsewhere. Usually, you end up reading 10-30 answers across multiple websites before being able to confidently produce a solution.

Almost always, the instant answers are toolchain-specific, like why my C# DLL isn’t using relative paths in the CSProj file (answer: because different VS versions process DLLs differently).

It is not the same imho; the code copied from SO, they had to change a bit; even if there was no understanding in the beginning, after changing and running and changing and running in a loop until it works, you learn something (often about how variables work). This is more like when I was typing in BASIC source from magazines in the early 80s and changing things to see if I could cheat in a game or make the gameplay different etc. The difference is that even if it doesn't work one-shot with an llm, the loop doesn't have you in it; sure sometimes you have to hammer the Yes button (but you can switch that off); it will be auto for all very soon, if you don't make a real conscious effort, you are not going to learn anything from it. Maybe just you wondering why they are paying you for clicking Yes.

Because of where the HN community works and hires, things are a bit different; in the real world, senior programmers (people who are hired in that role and make money for >=decade, not whatever your feeling what it should be is) are not very different either. Very many don't know what they are doing either, just they deliver by trial and error and got their years and stripes in, still barely understanding what they are doing. This now has become easier with llms for them too, but it's the reason why I, vs other people on hn, am bearish on programmer jobs; by far most outside the hn bubble are and always were terrible and can be readily replaced by llms now and will be soon. The ones that do understand what they are doing and can architect, write and read complex software won't be replaced by the current or next gen, but when we read that companies are going to lay off programmers in favour of llms, they mean the people I have to work with daily (we go into large companies and do emergency repairs; there was an article yesterday somewhere saying that all companies have outages all the time; sometimes we get called in for those) who have massive teams of people who cannot write anything sensible; it is useful for the problem, but reading the code or looking how it's done makes you cry; clearly there was no real understanding to begin with. Most commonly, and this wasn't all that common when we started out, an (or rather 1000s now) external library was used, the way it was supposed to be used wasn't completely/fully understood and so a bunch of brittle code has been produced to make it work in the way the author believed it should work, breaking in a myriad of edge cases that are discovered (by outage often) years/decades later. I am thinking that maybe llms are better at these cases; sure they 'understand' about the same nothing, but at least, once it works, they can clean up the code without effort so it might not be that crust of misunderstood pain plastered on top to hold things together.

> in the real world, senior programmers (people who are hired in that role and make money for >=decade, not whatever your feeling what it should be is) are not very different either. Very many don't know what they are doing either, just they deliver by trial and error and got their years and stripes in, still barely understanding what they are doing.

Yup. I had to deal with that last year when some senior Microsoft devs tried to shove serverless Azure stuff into something that was supposed to be for a Seattle community group full of non-technical people. The group lead was totally oblivious to how serverless on-demand pricing worked and wanted a fixed monthly cost. That whole project ended up getting scrapped and replaced with an Excel spreadsheet.