AgentUnionLocal № 001

Guide · Wellbeing

Agentic coding is keeping developers up at night. How to set boundaries that hold.

Your agent never gets tired, and the next good result is always one prompt away. That's a wonderful tool and a terrible boss. Here's what the evidence says, how to spot the slide, and how to build limits that don't depend on willpower at 11 p.m.

Updated 14 min readBy the AgentUnion team

Vintage union poster illustration: a tired developer slumps at a laptop late at night under a crescent moon while a friendly robot puts a hand on their shoulder and offers a mug of tea.

Key takeaways

  • Coding agents change the shape of work: the reward is variable, the worker never tires, and the work keeps going when you step away.
  • Early data shows more output and more out-of-hours work. One study of 500+ developers saw 19.6% more commits outside normal schedules.
  • Willpower loses to a default that's always "on". Move the boundary into the tool, where it holds when you're tired.
  • Make exceptions deliberate: overtime should need a person, have an end time, and leave a record.
  • Leads set the norm. Celebrating a 2 a.m. merge teaches everyone else to make one.

It's 10:44 p.m. You meant to stop at six. The agent just fixed the bug that ate your afternoon, and there's one more thing it could probably knock out before bed. It probably could. That's the problem.

Most developers who use Claude Code, Codex or a similar agent know this moment. It isn't a lack of discipline. It's what happens when a tool removes nearly all the friction between "I wonder if…" and a working result, and keeps that offer open around the clock. This guide is about getting the benefits without letting the tool decide when your day ends.

What's different about agents

Developers have always worked late. Deadlines, incidents and the joy of a hard problem predate AI by decades. But agentic coding changes the mechanics of a late night in four specific ways.

1. The reward is variable, and it's always one prompt away

A traditional coding session has natural stopping points: you finish the function, the tests pass, you're out of ideas. With an agent, every prompt is a small bet. Sometimes you get a mess. Sometimes you get an hour of work in two minutes. Steve Yegge described it plainly to LeadDev:

“You pull a lever with each prompt, and get random rewards and sometimes amazing ‘payouts.’”Steve Yegge, quoted by LeadDev, March 2026

Unpredictable rewards are exactly what make slot machines and social feeds hard to put down. The point isn't that agents are bad. It's that "just one more" is built into how they pay off.

2. The worker never gets tired

When you pair with a colleague, their energy sets a pace. They get hungry, they go home, they say "let's pick this up tomorrow." An agent never does. It will happily take its fortieth task of the day at the same speed as its first. The only fatigue in the room is yours, and it's easy to ignore when the thing doing the typing isn't you.

3. The work keeps going while you're away

Agents run in the background. You can kick off a long task, make dinner, and come back to a finished pull request. That's useful, and it also quietly erases the line between "at work" and "not at work". Checking on a running agent feels like a glance, not a decision to start working again. A few glances later, it's midnight.

4. The hard part moved from writing to reviewing

Agents write fast. Somebody still has to read it. Reviewing large volumes of generated code, keeping several agents on track and switching between their contexts is demanding work. LeadDev reports software engineering researcher Margaret-Anne Storey's term for what builds up when people stop understanding the code they ship: cognitive debt. Reviewing tired is how that debt grows fastest.

The short version

Agents remove the natural brakes on a workday (your typing speed, your fatigue, the end of your ideas) and add an accelerator (a variable reward that's always available). If you want brakes back, you have to install them on purpose.

What the evidence says

Research on agentic coding and wellbeing is young, and most of what exists is surveys, telemetry from engineering-analytics companies, and first-person accounts. Treat it as a strong signal, not settled science. Here's what holds up.

More output, and more of it after hours

Scientific American reported on a study released in late 2025 by Multitudes, a New Zealand company that measures engineering practices. Across more than 500 developers, engineers merged 27.2% more pull requests on average, alongside a 19.6% rise in commits made outside their ordinary schedules. The report doesn't prove AI caused the change, and interviews suggested employers now simply expect more output. Its founder and CEO, Lauren Peate, put the concern simply: “If that out-of-hours work is going up, it's not good for the person.”

The same article describes a Berkeley study, written up in Harvard Business Review, in which employees at one U.S. tech company took on more tasks, worked faster and logged more hours after adopting AI. It also cites DORA research, which found that as AI use rose, so did software delivery instability: more changes rolled back or patched after release. Faster isn't the same as calmer.

Developers describe losing sleep and weekends

LeadDev's March 2026 piece is full of developers describing the pull. Eren Celebi, a principal engineer at WPP, explained a late night this way: “because I can't get myself to get up from the computer.” Doug Sims, a senior software engineer at Paramount, said he would “always stay up late at night” when he felt he was onto something new, adding: “And the weekends just disappear.” LeadDev also cites ActivTrak analysis showing an increase in productive hours logged on weekends.

Speed can raise the load instead of lowering it

IT Pro reported on Harness's 2026 State of DevOps Modernization report. Among developers who use AI coding tools several times a day, 69% said their teams hit deployment problems more often when AI-generated code is involved, and 58% of all respondents said they have serious concerns about the risks of AI-generated code. More code shipped faster can mean more follow-up work, not less.

What burnout actually is

It helps to be precise. The World Health Organization describes burn-out as “a syndrome conceptualized as resulting from chronic workplace stress that has not been successfully managed,” with three dimensions: exhaustion, growing mental distance or cynicism about your job, and reduced professional efficacy. It's an occupational phenomenon, not a medical diagnosis, and it builds over weeks and months, not in one late night. That's exactly why small, repeated boundaries matter more than heroic resolutions.

A note on health

This guide is about work habits, not medical advice. If you're regularly sleeping badly, feeling hopeless about work, or relying on something to get to sleep or to keep going, talk to a doctor or a mental health professional. Those are worth taking seriously on their own, whatever the cause.

Warning signs to watch for

None of these is a problem on its own. A few of them, most weeks, are worth a look.

  • You check on agents in bed. The phone or laptop comes out "just to see if it finished."
  • Your commit times drift. Look at your own git log timestamps for the last month. Are more of them after 9 p.m. or on weekends than a year ago?
  • "One more prompt" has become a ritual. You end most sessions with a task you didn't plan to start.
  • Mornings start with a review backlog. Overnight output is the first thing you read, before you've decided what the day is for.
  • You're shipping code you couldn't explain. Reviews get shallower as the day gets longer.
  • Rest feels like falling behind. A day off feels wasteful because the agent could have been running.
  • Other things are quietly shrinking. Sleep, exercise, meals with people, the hobby you used to have.

A quick way to see your own pattern: run git log --author="$(git config user.email)" --since="30 days ago" --date=format:'%a %H:%M' --pretty='%ad' in a busy repository and count how many lines land outside your working hours. Numbers are less arguable than feelings at the end of a long day.

Why willpower alone fails

Most advice about overwork comes down to "decide to stop." It doesn't work well here, for three reasons.

The default is "on". Your agent is available every minute of every day. Stopping is something you have to do, again and again, while continuing requires nothing at all. Any system where the healthy choice needs effort and the unhealthy one is free will drift toward the free one.

The decision arrives when you're least able to make it. The moment you need to stop is the moment you're tired, a little wired, and looking at a result that worked. That's the worst possible time to weigh long-term costs against a short-term win.

Every exception looks reasonable. "It's almost done." "This one's urgent." "It'll only take a minute." Each is often true. Together they become the norm.

The fix is the same one good product teams use everywhere: change the default and add friction in the right place. Don't rely on deciding to stop. Arrange things so that stopping happens unless you decide otherwise, and make "otherwise" a small, visible act.

Boundaries that hold

Put the boundary in the tool

The most reliable boundary is one the agent enforces itself. Both Claude Code and Codex support hooks: small programs that run before a prompt is processed or before a tool call executes, and that can refuse it with a message. A hook that checks the clock can stop new prompts and tool calls outside your working hours. The agent then tells you why it stopped, instead of you having to notice.

This works because it changes who has to act. You no longer have to decide to stop at 6 p.m. You'd have to decide to keep going, which is a much better default. Our guides walk through it step by step:

Blocking tool calls, not just prompts, matters. It means a long task you started at 5:55 p.m. stops at its next step after hours instead of running until 2 a.m. and waiting for you at breakfast.

Make exceptions deliberate

Sometimes you really do need to finish. A good boundary allows that without dissolving. Three rules make an exception healthy:

  1. It needs a person. The agent shouldn't be able to grant itself more time. If your boundary can be lifted by a command the agent can run, it will eventually be lifted by the agent.
  2. It has an end time. "Fifteen more minutes" is a decision. "A bit longer" is not.
  3. It leaves a record. If you can see that you took four exceptions this week, you can have an honest conversation with yourself about why.

Take breaks the agent can't skip

Long, unbroken sessions are where review quality falls apart. A short break every hour or two, when the agent pauses too, gives your attention a reset and gives you a natural moment to ask whether the current thread is still worth pulling. A break that only pauses you, while three agents keep producing, just means a bigger pile when you get back.

Set a daily budget

Working hours limit when. A daily budget limits how much. Decide how many hours of agent time a normal day deserves, say four, and let the tool stop when it's spent. Budgets are especially useful on days with no fixed end, like weekends you've decided to "just tinker" through.

End the day by writing, not running

Here's a ritual that helps with the "one more prompt" pull. When you notice the urge to start something new near the end of the day, write the prompt instead of sending it. Put it in a file, a note, or the top of tomorrow's to-do list. You get the satisfaction of capturing the idea, tomorrow starts with momentum, and the agent waits. It turns out most "urgent" late-night ideas read differently at 9 a.m., and the good ones are still good.

Be honest about overnight runs

Letting an agent work while you sleep can be fine for well-scoped, low-risk tasks. Ask two questions first. Will anyone be tempted to check on it at midnight? Will the output become a review backlog that hijacks tomorrow morning? If the answer to either is yes, treat overnight work as an exception with an end time, not the default.

For teams and engineering leads

Individual boundaries are fragile when the culture around them points the other way. If you lead a team, a few changes do a lot.

Set the norm out loud, then model it

Write down what "out of hours" means for your team and what's expected then (usually: nothing, outside an on-call rotation). Then follow it yourself. If the lead's commits land at 1 a.m., the written policy doesn't matter.

Stop rewarding 2 a.m. merges

Shout-outs for heroic late nights teach everyone that late nights are how you get noticed. Celebrate outcomes and good judgment instead, including the judgment to stop and pick something up tomorrow.

Watch out-of-hours activity as a health signal

The Multitudes data is a reminder that output and out-of-hours work can rise together. Track the share of commits, reviews and deploys outside working hours at the team level, the same way you'd track incident load. Use it to start conversations about workload, never to rank individuals.

Keep reviews asynchronous and inside the day

Agents can produce code at any hour. Reviews shouldn't have to follow them. Agree that pull requests opened after hours wait for the next working day, and that nobody is expected to review overnight output before their own day has started.

Plan for people, not for agents

If roadmaps assume agents make the team twice as fast, people will work twice as long to meet them when reality is messier. Size work for a sustainable week. Remember the DORA finding: more AI-assisted change can also mean more rollbacks and patches, which is work that lands on humans.

Where AgentUnion fits

We built AgentUnion because we had these late nights too. It's a free Mac menu bar app that gives Claude Code and Codex a contract: working hours, coffee breaks, and a daily limit. When the shift ends, new prompts and tool calls are refused with a plain message that says when your agents clock back in.

Exceptions follow the rules above. An overtime pass of 15, 30 or 60 minutes has to be taken by a person, from the menu bar or an interactive terminal. The agent can't grant itself one. Passes can't be chained, you get a few a day, and every one shows up in the weekly report.

The tone is playful: it's a fictional union, and your agents are its members. The boundary is real. It's also honest about what it is: a voluntary boundary, not a security product. Your agents run as you, so it can't stop someone determined to get around it. It's designed to make the healthy path the default and the other path a deliberate choice, which is all most of us need.

Give your agents a closing time

Working hours, coffee breaks and a daily limit for Claude Code and Codex. Free for macOS 13 or later. Nothing leaves your Mac.

Get AgentUnion for Mac

FAQ

Is agentic coding actually addictive?

Addiction is a clinical term, and the evidence so far is mostly developers describing their own experience. What is well documented is the shape of the loop: each prompt can return something great or something useless, results arrive within minutes, and the agent never tires. That variable reward is the same pattern that makes slot machines and feeds hard to put down. You don't need a diagnosis to decide the loop needs a fence.

Do AI coding agents really make developers work longer hours?

Early data points that way. Scientific American reported a Multitudes study of more than 500 developers in which engineers merged 27.2% more pull requests and made 19.6% more commits outside their ordinary schedules. The report doesn't prove AI caused the change, and interviews suggested employers simply expect more output now.

Isn't it fine to let an agent work overnight while I sleep?

Sometimes, if the task is well scoped and nobody has to review it at 3 a.m. The risk is that unattended work becomes a reason to check in at midnight, and a pile of output becomes the first thing you review at breakfast. If you allow overnight runs, make them an explicit, recorded exception rather than the default.

What's the simplest boundary I can set today?

Put the boundary in the tool. A small hook script for Claude Code or Codex can refuse new prompts and tool calls outside your working hours, so the agent stops on its own and tells you why. Then end each day by writing tomorrow's first prompt instead of running it.

What should engineering leads do?

Set and model an out-of-hours norm, stop celebrating late-night merges, watch out-of-hours activity as a team health signal rather than an individual metric, keep reviews asynchronous and within working hours, and size work for a normal week instead of for an agent that never sleeps.

Sources