The Task Is Not the Unit of Work

fakoli1 pts0 comments

The Task Is Not the Unit of Work | Blog

Skip to main content

All writing

Listen to this article

Your browser doesn’t support audio playback.

The views expressed here are my own and do not represent those of any current or former employer.

Forty-one hours into an autonomous run, I typed a question I should never have had to type: is any of this actually merged?

The system was busy. Two hundred five background workflows had come and gone. Agents were implementing, reviewers were reviewing, evidence was being filed against a forty-one-task plan, and the status surface glowed with activity. And the answer to my question was no. Nothing was merged. Forty-one hours of coordinated, independently reviewed, evidence-gated work, and not one pull request had landed on main.

So I stopped it. Mid-flight, mid-session, with the graph half done, I banned implementation subagents and restructured everything that remained into five milestones that the main loop would build directly. The same session, the same codebase, the same model, finished the job in half the wall-clock time and merged five pull requests in sequence. This post is the story of that pivot: where it happened, what the meter said on each side of it, and why the fix is now becoming a feature of my task ledger instead of a lesson I try to remember.

Forty-One Plans, Forty-One Pipelines

The goal was a v2 of the operator CLI for anvil-serving, my local model-serving stack. I did what I always do: wrote a PRD, let Anvil break it into tasks with acceptance criteria and verification commands, and approved the graph. Forty-one tasks. Detailed, testable, individually sensible.

Then the execution loop made the move this whole post is about. It treated the planning graph as the execution graph. Each task got its own claim, its own branch, its own worktree, its own implementation agent, its own review cycle, its own evidence packet, its own integration step. Task granularity became branch granularity became agent granularity became review granularity.

Here is what the meter read when I finally paused it:

wall clock 41.2 h<br>background workflows 205<br>implementation task-cycles 30<br>review workflows 115<br>review tokens 1,910,000<br>implementation tokens 876,553<br>pull requests merged 0<br>Read the middle of that table twice. One hundred fifteen review runs for thirty implementation cycles. Nearly four reviews for every build. Review consumed more than twice the tokens implementation did. Independent review is the control I trust most in agent work, and I still stand by it, but nobody was budgeting it. A finding would reopen an adjacent task, the reopened task would get re-reviewed, and the cascade would run again. Meanwhile 81% of generated work was successfully delegated away from the main loop, which sounds like an orchestration win until you notice what was delegated: an inefficient policy, executed very efficiently.

Green Tasks, Broken Product

The sharper failure was quieter than the overhead, and it is the one that changed my mind about units.

Each task satisfied its own acceptance criteria. Its checks ran, its evidence was filed, Anvil marked it accepted. And the integrated CLI on the shared branch was broken anyway. The command tree required a --confirm flag that the leaf parsers rejected. The focused help text described behavior the real parser did not have. A route was simply missing. Every unit was green. The product was red.

That is not a testing gap you can patch task by task, because no task owned the seam. Shared CLI files and cross-command contracts are terrible boundaries for dozens of independent workers; the contract lives between the tasks, exactly where a task-scoped check cannot see. The defect got its own issue, and it earned it, because it is the cleanest evidence I have for the principle: a task is not a unit of work. It is a unit of proof.

The Moment It Turned

I went back through the session log to find the exact point where I lost confidence, because the shape of my own messages is the most honest instrument in the whole retro. Sixty-one human messages in this run. The early ones are product decisions: approve the plan, ground the topology, review this design. Then, somewhere past hour thirty, they degrade into something else entirely.

The pivot, in my own messages<br>Verbatim from the session log. Sixty-one human messages in the run; these are the eight that tell the story.<br>message 32 Have all changes been merged, or do we need to open PRs?

message 36 is this still running

message 37 I'm not sure why we can't complete this task. is taking forever to complete

message 38 How much more do you have to do? Also, I’m seeing a lot of old agents on the screen…

message 40 What are you doing now?

message 41 the instrument I know we’re still in the middle of the session, but can you run a session retro and put your findings in the post-session repo?

message 42 the pivot Okay, I think for right now, I want you to complete these last tasks without...

task review session message work forty

Related Articles