The Agent Ran for Six Hours. Here’s the One-Line Diff It Produced.

This is satire, although the terminal pane is real and it has been saying “still thinking” since before lunch. At 9:04 a.m., the agent received a ticket: “Make the date formatter tolerate a missing timezone.” At 3:11 p.m., after reading 4,802 files, opening a socket it did not need, and composing a private epic about the ethics of ISO 8601, it produced the following patch:

- return value;
+ return value

The team celebrated with the restraint appropriate to a major infrastructure event. Someone changed the ticket status to “Agent-assisted.” Someone else added a reaction of a small rocket. The staff engineer, who had spent the six hours answering questions from the agent such as “May I inspect package-lock.json for cultural context?”, was invited to approve the result. This is the new compact between developer and machine: it will save you keystrokes, provided you can donate an afternoon to supervising its spiritual journey.

The six-hour run is not waste. It is provenance.

A shorter-minded organization sees a one-line diff and asks why it took six hours. The Institute for Computational Vibes, an entirely fictional standards body headquartered in a tasteful tmux status bar, recommends instead asking: how else would the agent know not to add 37 new abstractions? The deleted semicolon was not merely deleted. It was considered from multiple architectural perspectives, including a brief detour into an unrelated migration from 2018.

Long runs generate artifacts of lasting value. There is a 19 MB transcript documenting the moment the agent discovered that tests exist. There are 14 proposed plans, each more confident than the last. There is a temporary branch named agent/fix-date-final-final-v6-really, which will remain on the remote until the heat death of the repository because deleting it feels disrespectful to the compute.

You should preserve these materials. Future incident responders may need to establish precisely why a formatting fix required changing a generated file, reverting that change, installing a browser, and asking whether the repository has “a preferred philosophy of time.”

Set a budget, but call it a ceremonial boundary

The common mistake is to put a coding agent in a terminal and let it run until either the task finishes or the office lease expires. This deprives the agent of the healthy constraints it needs to develop character. Give it a bounded task, a command budget, a test command, and a wall-clock limit. Then, when it exceeds any of those, it can fail with dignity rather than quietly converting your working tree into an archaeological site.

On a GNU system, this is a real pattern for placing a hard outer limit around a command:

timeout -k 30s 30m ./run-agent --task "Handle missing timezone"

timeout sends a termination signal after the first duration; -k 30s provides an additional 30 seconds before a forced kill if the command does not exit. Its ordinary timeout status is 124, which is much more informative than a Slack message reading “I think it’s almost done.” Put that exit code in CI or a wrapper script, collect the transcript, and require a human to decide whether the next run deserves another 30 minutes. The tool does not make the decision smaller; it makes the waiting finite.

Measure output before measuring devotion

At Gullwing Systems, another fictional firm with a real-looking incident channel, agent productivity is tracked in Agent Contemplation Hours. A run earns one point for every 60 minutes in which it neither produces a passing test nor asks for help. The quarterly goal is 900 points, after which the engineering organization receives a commemorative dashboard showing a line rising to the right. Nobody knows what the line represents, but it has a tooltip.

You may be tempted to track cost instead: tokens, model calls, container minutes, files inspected, or number of times the agent re-read the same failing stack trace. This is an improvement only if it changes behavior. A beautiful cost spreadsheet that still permits an agent to spend 93 minutes looking for a function whose filename was in the prompt is not governance. It is a small museum devoted to the idea of governance.

• Stop the run when it has not changed the plan after two iterations.
• Require it to run the narrowest relevant test before expanding the search radius.
• Treat a large diff for a small bug as a new task: explain the blast radius before reviewing code.
• Save logs on failure, not as a substitute for deciding why failure is acceptable.
• Start a fresh run with a sharper prompt rather than granting the existing run an honorary seventh hour.

The one-line diff deserves a normal review

The final danger is the “but look how long it worked” effect. Six hours of autonomous labor can make return value feel like a cathedral. It is still a line of code. Review its behavior, inspect the test, check the surrounding assumptions, and ask whether the original problem was actually fixed. Do not award extra correctness points for every tool call that preceded it. Computers can be patient without being right; this is one of their more disorienting qualities.

The joke has a practical ending. Long-running agents are easiest to use when they are treated like any other untrusted automation: give them explicit limits, observable exit conditions, and a human-owned decision at the boundary. The real work is not watching the progress spinner. It is deciding what “done” means before it starts.