Why developers using AI are working longer hours

(scientificamerican.com)

39 points | by birdculture 1 hour ago

10 comments

  • diavelguru 55 minutes ago
    This is a real thing. I spent all of January doing Greenfield development using Claude (I finished the requirements) and all I can say is thank goodness I had the Max 5x plan and not the 20x as I got breaks once the tokens were used up till the next cycle. I was forced to get up and do something else. That something else was biking, rowing, walking. My productivity had never been higher but at what cost? My health no thanks. So I'm glad I'm using the time till token reset for my health. I time it perfectly. I do a walk, row, bike for 1 hour then as I arrive back the tokens are reset. I get like 3 hours nonstop use per token batch with the 5x plan. I've been thinking about going 20x but am scared...
    • unshavedyak 49 minutes ago
      I don’t get this tbh, I use Claude too and my issue is the opposite - too many small breaks. Every time I hit enter my brain wants to checkout because the agent just spins while it creates thousands of tokens and churns on the subject. Even if it’s only 2m, that’s 2m where my mind has nothing to work on.

      Hard to stay in flow and engaged.

      Feels weirdly similar to being interrupted over slack.

      • diavelguru 37 minutes ago
        you are correct flow is not achieved as this is not programming more like system design, architecture, QA, Product Owner work. It's using the swarm as your own dev team.
      • MattGaiser 5 minutes ago
        Are you a single agent user?

        At least in my case, flow is gone. It’s all context switching now.

      • androiddrew 44 minutes ago
        I have never been in a flow state with an agent running. I use agents, but that isn’t flow.
        • diavelguru 33 minutes ago
          and flow state is a luxury in 2026 with AI swarm most likely to be found sparingly if all. Good luck all!
        • diavelguru 38 minutes ago
          yes agreed. I'm running 3-5 parallel Claude at once with requirements as the input. My prompt is say work on section 5.1 or something very specific. Then I'm monitoring the work across all instances.
  • furyofantares 1 hour ago
    > Software engineering was supposed to be artificial intelligence’s easiest win.

    At what point in time? Did anyone foresee coding being one of the best and soonest applications of this stuff?

    • antonvs 1 hour ago
      They're probably talking about some point after the capabilities of LLMs started to become clear.

      It's why Codex, Claude Code, Gemini CLI etc. were developed at all - it was clear that if you wanted a concrete application of LLMs with clear productivity benefits, coding was low-hanging fruit, so all the AI vendors jumped on that and started hyping it.

      • furyofantares 47 minutes ago
        Sure, but jumping from its amazing these things work for code at all to software engineering is solved is something only grifters or those drunk on the kool-aid did.

        I do agree that it was thought that these llm-agents would be extremely useful and that is why they were developed, and I happen to believe they in fact are extremely useful (without disagreeing that much of the stuff in the article definitely does happen.)

        I just sort of resent the setup that it was supposed to be X but actually it failed, when not only is there only minor evidence that it failed, but it was only a brief period in time when it was supposed to be X.

    • Copyrightest 16 minutes ago
      [dead]
  • ausbah 16 minutes ago
    two unthought out thoughts:

    1. llms allow devs to be more productive, so more free time is seen as opportunity for more work. ppl overshoot and just work more

    2. generalized tooling makes devs seem more replaceable putting downward pressure on job security (ie work harder or we’ll get someone who will, oh and for less money)

    3. llms allow for more “multitasking” (debatable) via many running background tasks, so more opportunities to “just finish one more thing”

  • Fordec 54 minutes ago
    Selection bias? The early adopters that are motivated to adopt tools to deliver more, typically also were working more to start with and may have already been struggling with their rate of output?
  • dworks 20 minutes ago
    thouroughly reviewing and especially testing is faster than skipping manual review and tests
  • SoftTalker 1 hour ago
    No silver bullet. We've known this since at least the 1980s. The fact that the authors of the code might not be human doesn't change this.
  • antonvs 56 minutes ago
    I can't deny that this might be a trend in practice, but at companies with reasonably self-aware practices, it isn't, or doesn't need to be.

    There's this weird thing that happens with new tools where people seem to surrender their autonomy to them, e.g. "welp, I just get pings from [Slack|my phone|etc] all the time, nothing I can do than just be interrupted constantly." More recently, it's "this failed because Claude chose..." No, Claude didn't choose, the person who submitted the PR chose to accept it.

    It's possible to use tools responsibly and effectively. It's also possible to encourage and mentor employees to do that. The idea that a dev has to be effectively on call because they're pushing AI slop is just wrong on so many levels.

    • cejast 6 minutes ago
      > More recently, it's "this failed because Claude chose..." No, Claude didn't choose, the person who submitted the PR chose to accept it.

      I can relate to this, unfortunately these tools are becoming a very convenient way to offload any kind of responsibility when something goes wrong.

  • decker_dev 1 hour ago
    [dead]
    • johnfn 1 hour ago
      Was this comment written by an LLM? It seems like it was to me. e.g. the “paradox” is not a paradox at all and is just an obvious statement.
      • AstroBen 1 hour ago
        From looking at their other comments: unquestionably yes it's a bot.
      • bluefirebrand 1 hour ago
        I just assume any green account names are LLMs nowadays
    • written-beyond 1 hour ago
      A developers job has always been reviewing and understanding code.

      Code is literally always the last resort. Unless you're building solutions for other customer, most companies should attempt to minimise the amount of code they have. Because, and I repeat, it's a developers job to understand and review code. More code, more understanding needed, more reviews needed, more problems created.

      • grim_io 1 hour ago
        I don't know about you, but if I started doing all that instead of writing code as a priority, I'd be fired.

        My job is to generate more money, not indulge in code.

      • whatever1 1 hour ago
        Nah summarizing code is now an LLM job as well. There is no place for engineers in the new tech world order.
  • aplomb1026 50 minutes ago
    [dead]
  • shablulman 1 hour ago
    [dead]