There's a new experience becoming normal for developers in 2026: you start a task at the end of the day, and when you come back, a background agent has done the work and opened a pull request. The code is written, the tests are run, the change is waiting for your review. For routine, well-defined work, this is a genuine multiplier — the agent does the typing while you do something else, and the work accumulates while you're away. But the experience also relocates your job. You spend less time writing code and more time reviewing changes you didn't watch get made, and reviewing work you didn't see happen is a different skill than reviewing your own.

The shift is subtle but real. When you write code, you build understanding as you go — you know why each decision was made because you made it. When you review a PR an agent produced overnight, you arrive at the end of a process you didn't observe, and you have to reconstruct the reasoning from the result. That reconstruction is the new core skill, and it's one most developers haven't deliberately practiced, because until recently the code you reviewed most carefully was your own.

Why Reviewing Unwatched Work Is Harder

The absent context changes what review requires.

You didn't build the mental model along the way. Writing code is also how you understand it. When an agent writes it while you're away, you get the artifact without the understanding that normally comes with producing it. Reviewing well now means building that understanding from the diff alone, which is more effortful than reviewing code whose creation you witnessed.

Plausible and correct look the same on the surface. Agent-authored code tends to look reasonable — it follows conventions, it reads cleanly. That surface plausibility makes it easy to approve without truly verifying, especially for a change you didn't see being made. The risk isn't obviously bad code; it's confidently reasonable code that's subtly wrong.

The volume tempts shallow review. When agents produce more PRs than you would have written by hand, the pressure to review each one quickly grows. Background agents can generate work faster than careful review can consume it, and the failure mode is rubber-stamping under volume. The agent's speed becomes your review bottleneck, and the temptation is to relieve the bottleneck by reviewing less carefully.

What the New Rhythm Looks Like

Work accumulates while you're not working. The headline benefit: progress happens on your off-hours. Start tasks before stepping away and return to completed work. For the right tasks, this genuinely multiplies what gets done in a day.

Your day shifts toward review and direction. Less of your time goes to writing, more goes to specifying tasks clearly enough for agents to execute and reviewing what they produce. The center of gravity of the job moves from authorship to direction and verification.

Specification quality determines agent output. What you get back in the morning is only as good as what you asked for the night before. Vague tasks produce PRs that miss the point; precise tasks produce PRs worth merging. The work moves upstream, into how well you frame the task before the agent runs.

Where Background Agents Fit

Well-defined, routine work. Bug fixes with clear repro steps, mechanical changes, well-specified small features — these are where background agents shine, because the task can be framed precisely and the result is straightforward to verify.

Work that's easy to verify. The best background-agent tasks have clear success criteria you can check quickly. The faster you can confirm a PR is correct, the more the agent's overnight work translates into real throughput rather than a review backlog.

Not ambiguous or high-stakes work. Tasks requiring judgment, design decisions, or carrying high risk are poor fits for unwatched execution. The absence of a human in the loop is exactly what these tasks can't afford. Keep them in the foreground.

How to Make the Rhythm Work

Invest in specifying tasks well. The leverage of background agents is upstream, in how clearly you frame the work. A precise task description is the difference between a mergeable PR and a confused one. Treat task specification as the skill that's now most worth improving.

Build review discipline for unwatched work. Develop the habit of reconstructing an agent's reasoning from its PR rather than trusting surface plausibility. Read the change as something to be verified, not approved — especially when it looks reasonable.

Protect review from volume pressure. Don't let the agents' output rate dictate your review depth. If background agents produce more than you can review carefully, that's a signal to run fewer of them, not to review each one less. The quality gate only works if it stays a gate.

Match the task to the rhythm. Send routine, verifiable work to background agents and keep ambiguous, high-stakes work in the foreground. The productivity comes from putting the right tasks in the overnight queue, not from putting everything there.

The Job That's Emerging

Background agents don't eliminate the developer's work — they move it. The morning PR is real productivity, but it comes attached to a new responsibility: reviewing, carefully, work you didn't watch get made, at a volume that tempts you to review it less. The developers who thrive in this rhythm will be the ones who get good at the two skills it rewards — specifying tasks precisely enough that agents produce good work, and reviewing that work rigorously enough to catch the plausible-but-wrong.

The PR waiting in the morning is a gift only if you actually verify it. The same automation that produces work while you sleep produces the temptation to wave it through while you're busy. The productivity is real for teams that keep the review honest. For teams that let the agents' speed erode their scrutiny, the morning PR is just a faster way to merge mistakes — and find out about them later, when they're harder to trace back to the night they were made.