4 ms·

I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compell

I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing. The kind of person who insists on understanding things and working through the problem has always been rarer. It's not "humble", it's "inquisitive" and "persistent".

danielheath 29d ago
I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.
- Tade0 29d ago
  LLMs reduced interest on tech debt, but it's still there and people who have a tendency to acquire it will go bankrupt eventually.
  - oblio 29d ago
    "The code market can stay irrational longer than you can stay solvent." will probably be a thing.
    - bigstrat2003 29d ago
      That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.
      - Terr_ 29d ago
        Two imagined executive responses: 1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future." 2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."
        oblio 29d ago
        This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.
        mawadev 27d ago
        I was pretty early in the LLM stuff and I got called out on using it back in the day, because I showed the exact symptoms we see now, but as soon as management jumped on the train all the coworkers did a 180 and I alt tabbed out into a different department thinking it would change something... well it didn't :'D I guess it will take some years till we are sane again or not... I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.
  - backlava12 29d ago
    [dead]
intended 29d ago
The difference between the two is that friction is learning. the less friction the less growth. So even if they copied from SO they would have better knowledge than an Ai user. This isn’t speculation either, theres an MIT study which this is based on. https://www.media.mit.edu/publications/your-brain-on-chatgpt/ https://www.media.mit.edu/publications/your-brain-on-chatgpt...
- mrleinad 29d ago
  Learning could be targeted though. If I know where the error is (a script written by AI in powershell) and it's a logical one, it's ok to let the AI reason about it to get it fixed and move on. If I have no clue about how this part of the system works, then it's worth reading closely what the error says, in order to understand it first, then have the agent check the assumption you have. Reduce the friction by having the agent explain what happened and why the fix solved it. I know this might be an intellectual placebo, but sometimes you need to fix something fast to move on. Learning takes longer, and these days everyone expects you to be a 100x engineer with AI.
- laruss5 29d ago
  [dead]
mawadev 29d ago
In essence, you are correct. What I see with LLMs is how they will happily make up stuff, meanwhile you can pretty much exhaust SO, until you are forced to understand the problem you are having. You don't have to be a certain person to fall into this trap, you just condition your brain to accept this workflow somewhere. Pair this with day to day work stress like time and amount of tasks and you almost give in to a sort of addiction to deal with it all.
lelanthran 29d ago
> I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing. There's an infinity between someone who has to panel beat what they copied off SO and someone who just bangs their head repeatedly against an LLM.
oenton 28d ago
> The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. The kind of person who insists on understanding things and working through the problem has always been rarer. Well, this is where I disagree. I have coworkers who used to insist on understanding and now are doing exactly as OP wrote - copy/pasting from the LLM to brute force error messages. I don't know if it's generalizable but this is what I see in <big tech> working on a frontend team with mid to senior level engineers who I respect. One example a few weeks ago, I was helping a coworker root cause a bug in a React codebase. Pair programming isn't necessarily common but sometimes you see someone banging their head at a problem and you get curious. It turned out there was an effect (a callback that's invoked whenever some state changes) that invokes an API and this effect caused an infinite render loop because the error handling wasn't written correctly. It was something silly like - Call this API if we have no data -> get error -> update state -> call API again because we have no data... That was almost immediately what I suspected but my colleague was pulling out all the stops usually reserved for when you're desperate or need a sanity check, like logging to stdout after each line. Both my colleague and the LLM were convinced the problem lied in the pagination logic of the helper that invokes the API. He ended up rewriting that helper imperatively and functionally. To his credit, he rewrote it by hand and implemented the recursion correctly but he was baffled when the problem remained. Completely surprised Pikachu face. I don't think my coworker changed or suddenly stopped caring. It seems much more likely this is a predictable outcome when you lean heavily into AI authoring code for a sustained period of time. I'd also say that in itself is a consequence of the extreme pressure being exerted across the entire company to ship more code and review more code, faster.

danielheath 29d ago

I'm seeing people who _used to be_ like that losing that understanding without realizing it's happening - they have a superficial idea of what the code is doing, enough to feel like they understand it, but the change is apparent when watching them handle something unexpected.

Tade0 29d ago
LLMs reduced interest on tech debt, but it's still there and people who have a tendency to acquire it will go bankrupt eventually.
- oblio 29d ago
  "The code market can stay irrational longer than you can stay solvent." will probably be a thing.
  - bigstrat2003 29d ago
    That's certainly what I expect to happen. LLMs will ruin your software if you don't hand-hold them, but it'll take time for that to happen. And until that does happen, businesses hell bent on using them won't have anything to push them into realizing what a mistake it was to use them.
    - Terr_ 29d ago
      Two imagined executive responses: 1. "Nonsense, if it was a code-quality issue from the AI stuff, we'd have seen problems sooner, like in the first few months or a year. Oh, sure, some engineers complained, but that was just an adjustment period because they stopped once we told them we didn't care and mandated that they up-skill into the new AI-centric workflow future." 2. "The bold new AI initiative I put into place can't possibly be wrong, this failure is on the engineers who were responsible for overseeing its operation. This is supremely disappointing because we made their jobs so easy, they no longer have to write code, just review several dozens of pages per day with unremitting paranoid vigilance and attention to detail."
      - oblio 29d ago
        This, plus anyone responsible dodging that as soon as possible via job hopping. Harder to do in the current job market but internal transfers are still available, most of the time.
        mawadev 27d ago
        I was pretty early in the LLM stuff and I got called out on using it back in the day, because I showed the exact symptoms we see now, but as soon as management jumped on the train all the coworkers did a 180 and I alt tabbed out into a different department thinking it would change something... well it didn't :'D I guess it will take some years till we are sane again or not... I revisit it to see if the promises are unbroken now from time to time with every other update and these days it doesn't look so good. It is non deterministic all the way down.
- backlava12 29d ago
  [dead]

intended 29d ago

The difference between the two is that friction is learning. the less friction the less growth. So even if they copied from SO they would have better knowledge than an Ai user. This isn’t speculation either, theres an MIT study which this is based on. https://www.media.mit.edu/publications/your-brain-on-chatgpt/ https://www.media.mit.edu/publications/your-brain-on-chatgpt...

mrleinad 29d ago
Learning could be targeted though. If I know where the error is (a script written by AI in powershell) and it's a logical one, it's ok to let the AI reason about it to get it fixed and move on. If I have no clue about how this part of the system works, then it's worth reading closely what the error says, in order to understand it first, then have the agent check the assumption you have. Reduce the friction by having the agent explain what happened and why the fix solved it. I know this might be an intellectual placebo, but sometimes you need to fix something fast to move on. Learning takes longer, and these days everyone expects you to be a 100x engineer with AI.
laruss5 29d ago
[dead]

mawadev 29d ago

In essence, you are correct. What I see with LLMs is how they will happily make up stuff, meanwhile you can pretty much exhaust SO, until you are forced to understand the problem you are having. You don't have to be a certain person to fall into this trap, you just condition your brain to accept this workflow somewhere. Pair this with day to day work stress like time and amount of tasks and you almost give in to a sort of addiction to deal with it all.

lelanthran 29d ago

> I don't think it's generalizable. The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. It's more compelling, and we probably see more of them because of it, but it's the same general thing. There's an infinity between someone who has to panel beat what they copied off SO and someone who just bangs their head repeatedly against an LLM.

oenton 28d ago

> The kind of person who copy and pastes from the AI is the kind who did the same from StackOverflow before. The kind of person who insists on understanding things and working through the problem has always been rarer. Well, this is where I disagree. I have coworkers who used to insist on understanding and now are doing exactly as OP wrote - copy/pasting from the LLM to brute force error messages. I don't know if it's generalizable but this is what I see in <big tech> working on a frontend team with mid to senior level engineers who I respect. One example a few weeks ago, I was helping a coworker root cause a bug in a React codebase. Pair programming isn't necessarily common but sometimes you see someone banging their head at a problem and you get curious. It turned out there was an effect (a callback that's invoked whenever some state changes) that invokes an API and this effect caused an infinite render loop because the error handling wasn't written correctly. It was something silly like - Call this API if we have no data -> get error -> update state -> call API again because we have no data... That was almost immediately what I suspected but my colleague was pulling out all the stops usually reserved for when you're desperate or need a sanity check, like logging to stdout after each line. Both my colleague and the LLM were convinced the problem lied in the pagination logic of the helper that invokes the API. He ended up rewriting that helper imperatively and functionally. To his credit, he rewrote it by hand and implemented the recursion correctly but he was baffled when the problem remained. Completely surprised Pikachu face. I don't think my coworker changed or suddenly stopped caring. It seems much more likely this is a predictable outcome when you lean heavily into AI authoring code for a sustained period of time. I'd also say that in itself is a consequence of the extreme pressure being exerted across the entire company to ship more code and review more code, faster.