The Promise and the Counter-Evidence§
The pitch, as the author of the original post frames it, was straightforward: AI would give developers their time back. Less boilerplate, delegated tedium, earlier evenings. What he reports instead is that he is working more than he ever has, and that the work feels heavier — not because any individual task became harder, but because there are far more of them running at once.
The important caveat is that this is not a complaint about tool quality. The author says he now uses agents for all of his engineering work, has documented how that setup evolved, and still reads the code they produce. He also reports a genuine capability gain: he can investigate and ship things that would not have been worth starting two years ago. The article is an attempt to reconcile those two observations, using data from his own GitHub history as supporting material.
The Unit of Work Changed, Not Just the Volume§
The clearest part of the account is a before-and-after description of a working week. As a full-stack engineer, a normal week previously meant two or three serious tasks — a feature, a tricky bug, perhaps a migration. Each demanded real focus, but the key property was seriality: one problem held in the head at a time, finished, then replaced by the next.
Today the week is parallel by default. In the author's description, several agents run simultaneously: one implementing a change, one investigating a production question, one working through a review, another doing research he will need later. None of them requires him continuously. Every one of them requires him intermittently — and, as he puts it, that "sometimes" is the problem.
That distinction is the analytical core of the post. The cost of an agentic workflow is not concentrated in the moment of implementation; it is distributed across a large number of small, unpredictable re-entry points.
Why Parallel Agents Produce Serial Human Bottlenecks§
The technical mechanism the author identifies is context switching. Each agent eventually returns with something: a question, a plan to approve, a diff to read, or a result to make sense of. Responding is not a trivial acknowledgment — it means reloading a different problem, a different repository, and a different set of decisions.
Agent execution is asynchronous and horizontally scalable. Human review and judgment are neither. The author's decision to keep reading the code means the verification step stays firmly with him, which is presumably deliberate and, by his own framing, part of why the setup works. But it also means throughput gains on the generation side convert into a higher arrival rate of interruptions on the human side.
There is a second, quieter dynamic in the post: scope expansion. The claim that he can now investigate and ship work that would not have been worth starting two years ago implies the queue of viable tasks has grown. If per-task cost falls but the set of tasks worth doing grows faster, total load can rise even as efficiency improves. The author does not use that framing explicitly, but his description is consistent with it — and it is the most plausible bridge between "the tools are good" and "I work more."
Practical Implications§
For teams adopting multi-agent workflows, the post suggests the binding constraint is no longer implementation capacity but human attention and review bandwidth. Three implications follow directly from the described setup:
- Concurrency limits are a design decision. The number of agents one engineer runs in parallel determines their interruption rate. That number should be chosen, not accumulated.
- Batching agent returns is a real optimization. Questions, plans, and diffs that arrive continuously fragment focus; the same items reviewed in blocks preserve the serial deep-work pattern the author describes losing.
- Review capacity, not generation capacity, sets the ceiling. Since the author keeps reading agent-written code, plan approval and diff review are the throughput-determining steps, and they do not parallelize the way agent execution does.
The post also implicitly argues against measuring AI adoption by output volume alone. If the output rises while the engineer's ability to hold a single problem in their head degrades, the headline productivity number may be masking a change in the nature of the job.
What Remains Uncertain§
The source excerpt is truncated before the GitHub analysis it promises, so the specific metrics the author extracted — and what they show — are not available here. Whether his commit or pull-request history supports the parallel-work account, or merely illustrates it, cannot be assessed from the available text.
Beyond that, several things are unestablished. The claim that the work "feels heavier" is self-report, not a measurement of hours or interruptions. The post covers one engineer's experience, with no team-level or cross-organization data, so it is unclear whether this is a general pattern or a personal configuration choice. It is also unclear whether the added load is a transition cost of learning to orchestrate agents or a stable equilibrium of the workflow. And the scope-expansion explanation is inference, not something the author states as a finding.
The value of the piece is that it names a failure mode the productivity narrative tends to skip: when execution gets cheap, coordination and judgment become the scarce resources — and those are exactly the parts that still run at human speed.