Why developers using AI are working longer hours

2026-03-0723:397771www.scientificamerican.com

Studies find AI helps developers release more software—while logging longer hours and fixing problems after the code goes live

Software engineering was supposed to be artificial intelligence’s easiest win. Today companies such as OpenAI, Anthropic, Microsoft and Google have all released AI products geared specifically to coding. And a survey of nearly 5,000 technology professionals released in a report last year by Google’s DevOps Research and Assessment (DORA) team found that 90 percent of respondents said they were using AI at work—with more than 80 percent saying the technology had boosted their productivity.

“We see a large majority of folks that are relying on AI to get their job done, at least a moderate amount, which is really fascinating,” says Nathen Harvey, who leads the DORA team.

AI can generate code for everything from Web and mobile apps to data management tools. It often automates some of the tedious elements of the job, such as building testing infrastructure and updating software to run on new devices and systems. In some cases, even inexperienced developers can create working prototypes simply by describing their intentions to AI systems in a process often called “vibe coding,” a term coined by OpenAI co-founder and researcher Andrej Karpathy. But writing code is only part of the job; developers still have to verify that it does what it’s supposed to and fix it if it fails.

On supporting science journalism

If you're enjoying this article, consider supporting our award-winning journalism by subscribing. By purchasing a subscription you are helping to ensure the future of impactful stories about the discoveries and ideas shaping our world today.

Another finding from the DORA report was that while individual coder effectiveness appeared to rise with the use of AI, so, too, did “software delivery instability”—an assessment of how frequently code needed to be rolled back or patched after release to address unexpected issues.

“As you use more AI, you’re more likely to roll back changes that you’ve pushed into production,” Harvey says. “And this, obviously, is something that you want to avoid.”

Even as it becomes increasingly adept at writing code, AI doesn’t eliminate the need for human software engineering. Developers often still need to craft bespoke code—or at least tweak an AI tool’s output—to handle unusual cases or specific business needs that might not be reflected in AI training data. They also still need to carefully confirm that machine-generated programs behave exactly as intended and meet company standards.

AI tools don’t automatically shorten the workday. In some workplaces, studies suggest, AI has intensified pressure to move faster than ever.

If employers don’t manage its effects, AI may even exacerbate stress and burnout among software engineers. In a report published in the Harvard Business Review in February, researchers at the University of California, Berkeley’s Haas School of Business found that employees at one U.S. tech company took on more tasks, worked at a faster pace and worked more hours after adopting AI. Even without the company mandating use of the technology, employees began prompting AI during lunch, breaks and meetings, with some finding former downtimes less refreshing. There’s a risk that initial excitement and productivity boosts could give way to fatigue, lower-quality output and greater employee turnover, the researchers warned.

This pressure isn’t happening in a vacuum. Following years of industry-wide layoffs and corporate mandates for efficiency, AI is often deployed alongside the expectation that those left behind will do more with less.

Additionally, a report assessing more than 500 developers, released late last year by Multitudes, a New Zealand–based company that helps businesses track and optimize software engineering practices, found indications that AI can expand worker productivity but also working hours. On average, engineers merged 27.2 percent more “pull requests”—packages of code that were approved for insertion into existing software projects. But they also experienced a 19.6 percent rise in “out-of-hour commits”—submissions of coding work outside of their ordinary schedules. That could be a sign of problems to come.

“If that out-of-hours work is going up, it’s not good for the person,” says Multitudes founder and CEO Lauren Peate. “It can lead to burnout.”

The Multitudes report doesn’t definitively prove that AI directly caused the measured changes, but Peate says interviews suggest that the observed changes in hours among engineers are likely a sign that businesses expect greater productivity from employees in the AI era.

“People were feeling additional pressure to get more work done, and it looks like that was contributing to them putting in more hours,” she says.

While some research has suggested that less experienced developers might be among those who benefit the most from AI’s assistance, and vibe coding can let people with a minimal programming background build programs that run, a recent assessment from Anthropic suggests that overreliance on AI may affect the development of coding skills.

In a report released in January, Anthropic researchers found that software engineers working with a new software library saw a small, statistically insignificant boost in speed when they solved a task with the aid of AI compared with a control group working without AI assistance. When the coders were quizzed about the software library after the task, however, the group given AI assistance scored 17 percent lower than the AI-free group. Those who asked questions of the AI rather than just relying on it to generate code generally performed better, but the researchers raised concerns that using AI to simply complete tasks as quickly as possible under workplace pressure could be harmful to engineers’ professional development.

Additionally, they noted, the biggest gap in quiz performance was in questions related to debugging code—the process of finding and fixing the flaws that make code malfunction. In other words, junior developers who rely too much on AI might have a harder time not only writing code on their own but also understanding and putting the finishing touches on the code they generated in the first place. In a statement to Scientific American, Anthropic researcher Judy Hanwen Shen said the goal “shouldn’t be to use AI to avoid cognitive effort—it should be to use AI to deepen it.”

Already, the U.C. Berkeley researchers noted, engineers can find themselves helping co-workers who’ve created incomplete software solutions through vibe coding. And some open-source projects have reported a rise in low-quality, AI-driven submissions that sap core developers’ time.

That comes after a 2025 Harvard Business School working paper indicated that AI can lead to open-source developers shifting their time from handling project management tasks, such as reviewing code contributions and maintaining lists of issues for contributors to fix, to generating code themselves.

“You can do it by yourself now, so there’s not a lot of need to interact much with others,” says Manuel Hoffmann, a co-author of the paper and an assistant professor of information systems at the University of California, Irvine’s Paul Merage School of Business. “And that's not necessarily a bad thing.”

Still, such use of AI may limit another channel for less experienced programmers to hone their skills, develop professional networks and expand their résumés.

And as AI redefines what productivity means, workplace structures that prevent burnout, keep workloads manageable, and provide avenues for advancement and training may be more important than ever.

“When you’ve got great things happening, and you add some AI to the mix, they’re probably going to get better,” Harvey says. “And when you have painful things that are happening, [and] you add some AI to the mix, [you’re] probably going to feel that pain a little bit more acutely.”


Read the original article

Comments

  • By diavelguru 2026-03-080:274 reply

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

    • By unshavedyak 2026-03-080:327 reply

      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.

      • By diavelguru 2026-03-080:452 reply

        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.

        • By LoganDark 2026-03-081:262 reply

          But it's also programming as you have to study outputs to ensure they're correct. Some (it seems many) don't do this, and then their outputs usually aren't correct.

          • By DrewADesign 2026-03-081:331 reply

            Sounds more like code-level QA to me.

            • By LoganDark 2026-03-082:162 reply

              In my experience, QA is something like ensuring it responds correctly to input. This is similar, but not the same as code review. I would more liken QA to dynamic review rather than static. Note though that code review can still be a form of QA. (Formal proofing especially.)

              • By DrewADesign 2026-03-082:221 reply

                That’s what QA departments in software companies do. In many other contexts they examine things produced by machines to ensure they meet the specs and functional requirements for that piece, and if not, either adjust it, have someone else adjust it, or have the adjusted machine spit out another one. They might design tests, fixtures to measure things, etc etc etc but they do not make the things directly.

                • By LoganDark 2026-03-082:371 reply

                  To be fair, ensuring that machines produce the correct outputs (even by making someone else fix it) is still the kind of process I'm talking about. After all, that's also how it works in software.

                  • By DrewADesign 2026-03-083:12

                    It depends on what the machines are supposed to do. I’ve never worked in software QA, but worked as a developer for over a decade and currently work in manufacturing. Is mass-manufacturing totally different? Sure. QA engineers in small high-complexity single-run prototyping shops? It’s not much different.

              • By bmd1905 2026-03-096:05

                [dead]

          • By haliskerbas 2026-03-081:33

            That’s what my teammates are for, I pipe slack and jira to Claude and the asker and teammates tell me if there’s a bug

        • By phil21 2026-03-081:43

          > It's using the swarm as your own dev team. reply

          Managing high performance dev/ops teams is it's own form of a state of flow. In fact for me, it's much more addicting than any other as the outcomes are usually many multiples of any IC role you could have. Even crazier when you have a "follow the sun" team involved so there the work just gets sequentially handed off and is always in constant motion.

          I imagine AI coding is like this for a lot of folks.

      • By androiddrew 2026-03-080:372 reply

        I have never been in a flow state with an agent running. I use agents, but that isn’t flow.

        • By diavelguru 2026-03-080:48

          and flow state is a luxury in 2026 with AI swarm most likely to be found sparingly if all. Good luck all!

        • By diavelguru 2026-03-080:44

          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.

      • By andai 2026-03-0817:53

        I fix this by manually prompting many small changes (with a very fast model — smaller models are fine for simple changes / additions, and you can iterate fast).

        So I can still work way faster than programming manually, but I stay in flow. And most importantly, my mental model stays synced the whole time. There's no catching up to do.

      • By MattGaiser 2026-03-081:161 reply

        Are you a single agent user?

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

      • By arjie 2026-03-081:30

        I have similar problem but I have to switch contexts and it makes the work a lot more intense.

      • By amelius 2026-03-081:43

        This. And another problem is that I feel not proud after completing the task. No sense of achievement.

    • By TheAceOfHearts 2026-03-081:221 reply

      Hypothesis: limiting usage / tokens could have a positive effect on project quality, since it forces the developer to think more carefully about the problems they're working on. When you're forced to stop and slow down, you try to be more deliberate with token usage. But if you have unlimited tokens you can just keep generating infinite lines of code without thinking as hard about the problem.

      I've seen people on social media bragging about how they're able to produce a mountain of code as if this was praiseworthy.

      • By DrewADesign 2026-03-081:32

        One might wonder if the trend holds when limiting token use to… zero?

    • By cpncrunch 2026-03-081:251 reply

      Does a person review all the AI generated code?

      • By DrewADesign 2026-03-081:371 reply

        Not at all unless they’re a) competently b) making something worth anything at all that c) isn’t a proof-of-concept or the like.

        • By cpncrunch 2026-03-081:461 reply

          Yes, of course. I mean, is all production code reviewed?

          • By DrewADesign 2026-03-082:131 reply

            Sorry, I wasn’t giving a serious answer. It’s just not as amusingly worded as in thought.

            Seriously, though, your question is one of those “how long is a piece of string” sort of questions. Just like any other software quality question, it depends on context, competence, goals, market dynamics, organizational culture, project timelines, team expertise, etc.

            Do people pay their bills on time? Do people wear seatbelts? Do people brush their teeth for the full two recommended minutes? Depends, depends, depends.

            • By cpncrunch 2026-03-082:421 reply

              Sorry, I didn't realise you weren't the OP. I was really asking the OP as they said they had large productivity gains from using AI to code. But if you're a professional developer, the same question can be answered by you: do you specifically review all AI generated production code?

              In my own case 100% of my code is reviewed by humans (generally me), and that IMO is the only sensible option, and has been the standard since I started coding commercially 33 years ago. I don't use AI to generate code though, other than a few experiments, as I don't really need to write much code these days.

              • By bmd1905 2026-03-086:542 reply

                [dead]

                • By DrewADesign 2026-03-0810:201 reply

                  If you’re going to spam your product, you could have the decency to have literally any other contributions on your account. It’s literally just advertisements and I’ll bet a straw penny they’re generated by a chatbot.

                  • By cpncrunch 2026-03-0814:001 reply

                    Ironically they seem to use ai to review ai generated code, which is the main problem.

                    • By DrewADesign 2026-03-0819:34

                      Indeed. And the ouroboros takes another big bite!

    • By democracy 2026-03-081:42

      Great shilling attempt )

  • By qzira 2026-03-081:432 reply

    When people talk about AI increasing developer productivity, they usually focus on the coding part. In my experience, the bigger change happens after the code is written. When you move from writing code to supervising agents, your output increases — but your cognitive load increases too. Instead of writing every line yourself, you're now monitoring systems: Did the agent go off-script? Did it retry 50 times while I was asleep? What did that run actually cost? The strange part is that the mental burden doesn't disappear just because the agent is autonomous. In some ways it gets worse, because failures become harder to notice early and harder to contain once they start. It starts to feel less like programming and more like running operations for a team of extremely fast, extremely literal junior developers. Curious if others are seeing the same shift.

    • By Waterluvian 2026-03-081:582 reply

      That really sounds like micro managing jr. developers.

      I wonder if the interface for this kind of thing might be better presented as a sort of JIRA ticket system. Define a dependency graph of work with the ability to break down any ticket into more tickets or change priority or relationships etc.

      Though I think the micro manage part still doesn’t fit into that model. You’d need the code-level view and not just a ticket covering the tests that satisfy the spec and performance goals.

      • By qzira 2026-03-082:59

        I think a lot of people feel this tension. Programming used to be mostly about building things directly. You write code, run it, fix it, repeat. With agents it starts to shift toward supervision: define the task, watch the output, correct the drift. It's a different kind of work. Sometimes it feels less like programming and more like managing a very fast team that never gets tired but also never really understands the goal unless you spell it out extremely carefully. I suspect a lot of developers still enjoy the "building" part more than the "supervising" part.

      • By ender341341 2026-03-082:111 reply

        > That really sounds like micro managing jr. developers.

        That's how I tend to describe AI to a lot of non-technical people (I actually generally say it's like having an really fresh intern who can read technical docs insanely fast but needs a lot of supervision).

        • By qzira 2026-03-083:05

          That's a really good analogy. The interesting part is that the "intern" is not only fast, but also extremely confident. A human intern usually hesitates, asks questions, or signals uncertainty when they are unsure. Agents often produce very clean-looking output even when the reasoning behind it is shaky. So part of the supervision isn't just checking the result, but trying to detect when the confidence is misleading.

    • By democracy 2026-03-081:541 reply

      Yeah I am not sure many people gonna hang around this - I am not sure I wanna do this role. I like building and delivering and ai is great help but I will not be happy supervising agents, there are better jobs. Unless the money is not to be refused

      • By qzira 2026-03-085:19

        That's a very real concern. For a long time programming felt like a craft: you build something, run it, improve it. Agent workflows introduce a different kind of work. You're not just building anymore, you're supervising. Some people enjoy that shift toward orchestration. Others really don't. I suspect we'll eventually see tools that try to restore the "build and run" feeling instead of turning developers into supervisors.

  • By furyofantares 2026-03-080:164 reply

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

    • By throwaway314155 2026-03-081:35

      No one saw it coming.

    • By antonvs 2026-03-080:182 reply

      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.

      • By whattheheckheck 2026-03-081:45

        Because swe was the furthest advanced "collaborative cognition" field in terms of human workflows

      • By furyofantares 2026-03-080:35

        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.

    • By djeastm 2026-03-081:44

      I seem to recall short snippets of IDE code completion being one of the first commercial applications of it.

    • By Copyrightest 2026-03-081:06

      [dead]

HackerNews