Human Attention is All You Have
There's a lot of chatter online lately about the increasing number of pull requests that software developers have to read. If you know Goldratt's Theory of Constraints, it would make sense to call this the bottleneck. In short, any system is limited by the throughput of its one constraint, and improving anything else is wasted or harmful (The Goal, 1984).
It's a good rule. But it's an inadequate explanation. I believe it only describes a symptom of a larger problem.
For many developers, including yours truly, there's a feeling of being constantly "on". We're not just reviewing pull requests; we're babysitting agents that constantly need more information, need to be pushed to keep working, need redirected when they make faulty assumptions... they're very needy. What they need is a constant flow of human attention.
This isn't a bottleneck in the Goldratt sense, because human attention was never a station on the line. Every stage of software development, from deciding what to build to maintaining code in production, needed humans to do the work. But agents changed that. Large portions of the conveyor belt now runs without us. Code is generated faster than it was ever typed. But the speed of software development hasn't quite hit the magical 10x multiplier that seemed promised to us when we started using coding agents to do most of the work. The agents constantly need your supervision. And then there's the temptation to stop reading agents' reports, to stop reviewing code yourself, to blindly accept the agents' own PR reviews. Stop paying attention for a minute, and you've suddenly buried yourself under an avalanche of technical debt and unreadable code. The slopman cometh.
How do we optimize the human side of the equation?
Two altitudes
A quick setup, for anyone who hasn't lived this yet. A coding agent (like Claude Code or OpenAI's Codex) takes a ticket, works in its own copy of the codebase, and comes back with a pull request, asking you questions along the way. Switch on "auto" mode and it stops asking: if it believes it has enough information to finish the ticket, it finishes without stopping.
Engineers have always worked at multiple altitudes. High: is this the right problem, does the architecture hold, what happens to the user. Low: the function, the query, the null pointer. You'd hit a flow state by moving between them all day, and it felt natural. Think hard about a small architectural refactor to make the code easier to read. Then you'd dive low enough to see the ground and implement the change you envisioned. If you stayed down there too long and lost your bearings, you could catch a thermal and climb back up to where the whole valley was visible again. That's what a glider does: it stays up all day without an engine, because the pilot keeps trading height for speed and speed for height. The bounce between altitudes wasn't a distraction from the work. It was what made a full day of it sustainable.
Agents took over the low altitude. There's no need to figure out how to implement changes yourself. What's left for you is the high altitude, all of it, all day long, with nothing below you to dive into and no thermal to catch. A glider that has to stay high loses speed and thus altitude. No wonder you're out of breath.
Multi-tasking
In 2025, you worked one ticket at a time. By mid-2026, the agents are fast and competent enough that you're tempted to run several, simultaneously. One agent asks you a question. By the time you answer it properly, another agent needs your input. You're constantly switching context. Hours go by. You feel unproductive with fewer than three running. It's hard to stop at the end of the day, because just one more answer means another agent is unblocked, and will continue to crank away while you finally take a late break for dinner. How could you be burnt out when you look this productive?
Everyone who does this work full time has been turned into a kind of manager. But we're managing agents, and not people. And thus, we do without the parts of management that make it survivable: reports who frame a problem before bringing it to you, support staff to handle your schedule, permission to make important decisions later, and more. Agents bring you forks with the context stripped off, at machine speed. They don't remember how tired you were yesterday. And they don't understand why you can't continue at the same speed all day today.
The dark factory
The current ambition is the dark factory: a code pipeline with no humans inside. You describe what you want and the agents build, test, ship, and run it. This is where you'll see other non-coding agents, like orchestrators to help you organize your ticket tracker, delegate tickets to coding agents, write documentation, and more.
Very few teams have made it this far. In practice, attempts to build a dark factory typically fail in similar ways. Small deviations from what you described in tickets compound while you're not watching. You find the mess late. So you watch more closely, and now you're spending more attention than you did before you had agents, most of it on fixing the factory instead of the product it was supposed to build.
We built agents so we could think less. But they took the thinking that was easy. What is left is the thinking that was hard, and there is nothing to let you breathe between one hard decision and the next.
Attention == decisions
Almost all of the attention goes to decisions, and their cost isn't interchangeable. A hard decision costs more than an easy one. A hard decision after you've made ten hard decisions costs you even more. Every engineer who has managed agents all day long can feel it in their body by 5 PM. So treat it as a budget: a finite number of decisions per day, spent on purpose. Because your budget is limited, it's better to spend it on the hard decisions that matter.
What counts as a hard decision? There's a gray area here between "hard" and "easy", but there are some patterns. A hard decision is costly to reverse (a schema change, a public API). It constrains work that hasn't started yet (a data model the next three tickets build on). It changes what a user sees or does. Or it's a question the ticket leaves open that the codebase can't answer. Anything else is minor: cheap to reverse, and derivable from the ticket, the codebase, or can easily be found in context some other way.
The split matters because minor decisions are not free either. Every decision counts against the same budget. So ideally, you delegate minor decisions to agents. Then engineers have capacity to focus on the hard ones, at a pace that gets work done without burning us out.
That number, hard decisions per ticket, turns out to be the only estimate that matters.
The H.A.R.D.* System
*Human Attention Required before Delivery
It has one requirement: every ticket is tagged, indicating the number of decisions required for completion. It's close to "how agentic is this ticket," but that's a feeling. This is countable. You can also think of it as, "how many times will work stop on this ticket while waiting for human feedback?"
And here's the benefit: once you've tagged how HARD a ticket is, you can decompose it, budget it, and execute it more effectively.
Tagging
As I've been using the system for my own software factory, I've currently settled on a five-point scale, H0 through H4.
H0: zero.
The problem is demarcated, the fix is obvious, and correctness is machine-checkable. The agent can automatically claim the ticket, implement it, tests pass, it merges, and even deploys. No human input is required for completion whatsoever.
H1: one.
Well-scoped work with one human decision at the end: the Pull Request. Accept, and the agent merges and deploys for you. Reject with notes and it reworks. Nothing before the PR costs you anything.
H2: two.
The PR review from H1 above, plus one early checkpoint: a data model change or a user-facing change is approved before the work continues.
H3: several.
The problem is clear; the path is not. You could write the prompt today; you just can't say which of the answers you'd take. The agent produces its understanding and one or more proposed routes before building anything. You pick. Schema and UI checkpoints are expected. The work is still the agent's.
H4: too many to count up front.
The problem itself is unclear: product direction, design, user feedback still coming in. You couldn't write the prompt yet, because you don't know what you'd ask for. This is where you work with an agent, not through one. A good tell: the moment you switch off auto mode and start steering every turn, you're on an H4. No ticket ships from here. The humans find the shape of the solution first, then it decomposes into H0 through H3.
How do you know whether a ticket is an H0 or an H1? Ask whether a human review at the end would change the outcome. An H1 needs the PR because someone still has to judge it: is this the right shape, did the agent read the ticket the way I meant it, would I have done it this way. An H0 is a ticket where that judgment was made before the work started, and turned into checks a machine can run. Passing tests are the floor, not the bar. The bar is that your automated checks (the linter, the type checker, code coverage, static analysis for cyclomatic complexity and "CRAP", etc) catch most of what a reviewer would catch. H0 means no human looks at the work before it merges. That only pays off if CI misses are rare and small: a bug you fix in ten minutes next week costs less attention than reviewing every one of these PRs today. And when in doubt, classify up: a wrongly-escalated H1 costs one glance; a wrongly-trusted H0 that merges and deploys itself is an incident.
Decomposition
Decompose when you can. H2 and H3 tickets require a few human decisions in them, but they're typically also filled with rote work. Rework the ticket so you can split off the rote work as H0s. See if the parts of a ticket that require decisions can be split into multiple smaller deliverables, with the decisions split between them, so one H3 can be turned into several H1s or H2s.
Second, a rubber stamp is a decision that costs human attention. If a ticket needs one, that makes it an H1. But the goal is to make it an H0 by making the check deterministic. Any time a human catches the same mistake twice, develop a test, a lint, and/or a gate. You've already paid the price in attention once, you shouldn't have to pay it again.
Budgeting
This is the art of engineering management. It applies to both human teams, and to a single engineer and their team of agents.
In many agile practices (like Scrum or Kanban), you grab the highest-priority ticket and work on it until completion. Agentic workflows make it far too easy to grab multiple tickets at once.
Some guidelines (not rules!):
Don't attempt to multitask while working on an H4. These are pairing sessions, one human and one agent, and they are where flow state lives. An interruption from a second agent that needs you to answer its question is worse than a distraction. It's a context wipe and kills momentum.
Only one H3 at a time per engineer. Same rule as the H4, for the same reason: a decision gets much harder when it requires a context shift. Short breaks to clear H1s and H2s are fine; a second H3 is not.
When you do multitask, pick closely-related tickets. The cost of a switch is the distance between contexts. Keep the distance short and the decisions on each ticket stay cheap.
Experiment with pacing on H1s and H2s. How many agents you can monitor at once is personal, and it varies by stage: maybe two tickets in planning is your limit but five in PR review is fine. Find the pace you can hold.
Execution
What changes when you execute a ticket under the HARD system?
The tag tells the orchestrator what to bring you. If you run an orchestrating agent that reads the tracker, dispatches coding agents, and moves work from plan to review to merge, coding agents will still stop and ask for clarification on questions. Although an orchestrator will attempt to stay at the "higher altitude" and keep an eye on the big picture, a tagging system like HARD helps clarify to the orchestrator exactly what should be brought to your attention or not.
An H0 never reaches you. An H1 reaches you once, when it's time to review the PR. An H3 is expected to come back with routes to choose from. A lower tag tells the orchestrator if a coding agent stops to ask a question, the orchestrator already has access to the answers that the coding agent needs, and shouldn't interrupt the human. Conversely, a higher tag (like an H2) means the orchestrator dispatches less work to a coding agent at once. This ensures that work is paused so you can review something like a proposed user interface change, before telling the orchestrator to resume.
The tag tells you when to show up. Once every ticket carries a number, you can schedule your attention like a calendar instead of reacting to it like an inbox. H0s run overnight. H1 and H2 reviews get batched into a window. The one H3 you're allowed gets an uninterrupted hour. The H4 gets a whole afternoon with the door closed. If you're scheduling your interruptions, they're not really interruptions any more.
Actual stops versus the tag is your best signal. Have the agent count how many times a ticket really stopped for a human. A ticket tagged H1 that stopped three times is telling you something: maybe the ticket was underwritten, or a piece of your judgment still lives only in your head. Over a few weeks, the gap between predicted and actual stops shows you exactly where to write things down, and whether your team's tagging accuracy is getting better.
From Easy to HARD
I counted the number of interruptions presented to me each day, and started categorizing them by hard decisions, easy decisions, and dumb decisions. (A dumb decision is any decision that should have been solved by a deterministic check, or where the orchestrator already knew the answer but wanted to confirm with me first, for some reason...) My big realization was that it wasn't the hard decisions that were leaving me feeling drained each day. It was the sheer number of decisions overall, and "easy" decisions still took a toll.
I've been iterating on this system for around 6 months now. It boils down to a single number on each ticket that tells me what to split off, what to turn into a check, when to show up, and what to leave alone until I'm fresh. Some days that means fewer agents running. But the work that ships is work I'm proud of. More importantly, it's sustainable.
If you try this system, I'd love to hear from you. And if your team wants help setting it up, that's work I do.
Questions? Email me!Glider model: "UNDERPOLY: Free Sailplane Glider" by UNDERPOLY Project, licensed under CC BY 4.0. Shown here as a point cloud.