Claude Code made background subagents the default for all accounts this month. You can now queue tasks before bed, close your laptop, and wake up to a draft PR. WakaTime will show zero hours logged for those six hours your agent was running. The code exists. The hours don't.
This is not an edge case in the time-tracking model. It is the time-tracking model breaking.
What Changed in July
For most of the AI coding era, the human was in the loop at all times. Copilot autocompleted as you typed. Cursor generated functions when you tabbed into the next block. Claude Code executed tasks as you watched the terminal. The AI was fast, but it was your attention that kept it moving. When you closed your laptop, the AI stopped.
Background agents break that constraint. The pattern that's emerged among heavy users in 2026 — queue Claude Code or Codex with tasks before dinner, let them run, review the output in the morning — used to require deliberate setup. Now it's the default. You prompt the agent, leave, and it works. The commit timestamps in your Git log no longer correlate with hours you were present.
If you're a developer who works from 9 to 6 and queues three background tasks at 5:50pm, your IDE time-tracker shows an 8-hour workday. Your commit history shows commits at 2am, 3:30am, and 5:15am. Those commits are real. The reviewer who picks them up doesn't know they came from a session that ran six hours after you left. Your PR count for the week is inflated by work that generated zero keystrokes on your end.
The Assumption That No Longer Holds
Time-tracking for software development has always rested on a simple assumption: hours at the keyboard correlates with output. When you were at the keyboard, you were producing. When you weren't, you weren't.
Synchronous AI assistance already put pressure on this. If Claude Code helps you write a function in four seconds that previously took twenty minutes, the hours-in number drops without the output dropping. But the model handled this tolerably, because you were still present. You still appeared in the heartbeat log. Your session was active, even if each minute of that session was more leveraged than it used to be.
Background agents break the model in a different way. The output — commits, pull requests, code changes — now has no corresponding human presence in the tool logs. WakaTime heartbeats fire when a developer is actively editing in an IDE. They don't fire when a background agent is generating the code in a terminal process you're not watching. A developer who efficiently queued tasks and went to sleep produces the same heartbeat record as a developer who simply didn't work.
This creates a specific distortion: the ratio of "hours the tool saw you" to "output your account generated" is no longer meaningful as a productivity signal. A developer spending 30 minutes writing precise agent specifications and queueing them generates more code output than the same developer spending four hours writing code directly — but the 30 minutes looks like a quiet morning and the four hours looks like a full day.
Attribution Is the Harder Problem
At the individual level, the mismatch between hours logged and output generated is mostly a measurement problem. At the team level, it becomes an attribution problem.
Code review is already strained by AI volume. LinearB's 2026 benchmarks show that AI-generated PRs wait 4.6 times longer before a reviewer picks them up. Part of this is rational: AI-generated code can be syntactically correct while missing the architectural intent, and experienced reviewers have learned to spend more time on it. But part of it is that reviewers often can't identify it on sight.
Background agent code is one step further removed. The PR description might say "refactored auth module to support new token format," and the author listed is @janedoe — because Jane queued the task, provided the specification, and merged the PR. She didn't write the code in any sense that maps to what authorship used to mean. If the change causes a bug six weeks later, the blame history points at Jane. She's the author of something she reviewed rather than produced.
This matters beyond blame assignment. The implicit knowledge model in most engineering teams assumes that "who wrote it" tells you something about "who understands it." When Jane authored a module by carefully writing it herself, she holds context about the decisions made, the tradeoffs considered, the edge cases she thought about and chose not to handle. When Jane authored a module by reviewing what her background agent produced, she holds a different kind of context — hopefully a useful one, but not the same kind.
We're building codebases where the authorship record is becoming a record of who directed work, not who did it. That's not inherently bad. But it's a different meaning of the commit history than the tools expect.
What Tracking Needs to Do Differently
The answer isn't to ignore background agent output. It's to stop treating all output as equivalent.
At minimum, the tools running agents should expose structured logs: task queued at, agent active from/to, model used, files modified, tokens consumed. Claude Code already produces session transcripts. What's missing is an integration layer that routes this data into the same place where developer time is measured — so you can see human-active hours and agent-active hours as separate signals in the same dashboard.
The useful measurement question shifts from "how many hours did you work?" to two questions: "how many hours did you direct work?" and "how much output resulted from that direction?" The second number includes what background agents produced. The first doesn't. The ratio between them is where the actual productivity leverage lives.
This is different from what current tools measure. WakaTime counts hours at the keyboard. GitHub shows commits. Neither surfaces the specification quality that determined whether the agent succeeded, or the review time that translated agent output into shippable code. Those are the human inputs that matter in an async-agent workflow — and they're almost entirely invisible to current tracking.
The Data Gap That's Opening
The timing matters. Claude Code's background agents going default coincides with GitClear's 2026 data showing that 41% of production code is now AI-authored, block duplication has grown 81% since 2023, and long-term code maintenance (changes to files last touched over 12 months ago) has dropped by 74%. The codebases being built at accelerated agent-assisted pace are not being maintained at the same rate.
None of those trends are directly caused by background agents. But they all share the same underlying pattern: AI is accelerating one part of the development cycle while the measurement infrastructure is still calibrated for a different model. We're adding output we can count (commits, PRs, lines) while losing visibility into the quality and attribution signals that make output meaningful.
At xeve, we track sessions using heartbeats from the Mac tracker, VS Code extension, and Claude Code hook. That model captures human-active time accurately. What it doesn't capture yet is agent-active time — the hours the background process runs after you've stepped away. That gap is narrow today, for most developers. As background agents become more capable and more default, it widens. The developers who end up with useful productivity data are the ones whose tools evolve with the workflow, not the ones still looking at keyboard hours to understand how much they shipped.
The shift is not that AI makes developers faster. It's that AI makes the relationship between hours and output nonlinear in ways that hours-based tracking cannot see. That's a different problem than developer productivity measurement has confronted before. The tools that adapt to it first will tell developers something genuinely useful — which is more than most current dashboards can claim.