AI Made Output Cheap. Attention Is Still Expensive.

Attention is all there is. Every task we start needs some of it, even when an agent does most of the implementation.

"It's just one hour with Claude."

I understand the appeal. A feature that once needed a serious discussion can begin as a casual experiment. You explain the idea, let the agent work, and come back to something you can run. It becomes much easier to say yes.

The hour sounds like the entire cost. But someone still has to decide whether the feature matters, explain what it should do, review the result, and work out how it fits with everything else. Each of those steps needs attention from a person who was probably already doing something.

That is what worries me about how we are starting to work. We can produce more while spending less time fully present with any one thing.

Switching becomes the workflow

In my previous post, I described four background agents each opening a pull request within an hour and a half.¹ Getting that to work took real preparation, and I want to keep improving it. It also makes a different kind of workday possible.

Give one agent a feature, another a bug, and a third something you want to explore. While they work, start planning the next task. Then a result comes back. You leave the plan, reconstruct the context for the bug, answer a question about the feature, and try to remember where the exploration was supposed to stop.

Every transition has a reason. There is always something ready for your attention. Context switching starts to become the workflow itself.

The unfinished work comes with you. You can be reading a pull request while still thinking about the specification you left open, or listening to someone explain a problem while mentally checking whether an agent understood your last instruction. Even worse, you might open an agent's session during a meeting and start answering its questions while a colleague is still talking.

Sophie Leroy's 2009 experiments on attention residue help explain this. People had difficulty disengaging from an unfinished task, and their performance on the next task suffered. Moving to the next activity did not mean their attention had fully moved with them.²

There is also evidence for why an interrupted day can feel more draining even when the work gets done. In a 2008 lab study of 48 participants, Gloria Mark, Daniela Gudith and Ulrich Klocke found that interrupted participants spent less time on the main email task, after subtracting the time spent handling interruptions. They also reported more stress, frustration and effort. The researchers interpreted the faster work as compensation for being interrupted.³

These studies predate coding agents. I think they offer a useful warning for this way of working: visible output can increase while the person coordinating it feels worse. Counting completed tasks tells us very little about the effort of repeatedly getting back into them.

Planning and reviewing fill the gaps

Delegating implementation leaves us with more decisions about what to delegate and what to accept when it comes back.

Planning takes concentration. You have to understand the problem, choose a scope, explain the constraints, and decide what evidence would count as success. An agent can help with all of that. It can also give you several plausible approaches to consider before you have settled the first question.

Reviewing takes a different kind of concentration. You have to reconstruct enough of the problem to judge someone else's solution. Passing tests help, but you still need to decide whether the tests cover the important behavior and whether the change solves the problem you meant to solve.

Put several tasks in flight and the gaps between them fill with planning and review. A finished implementation creates another demand on your attention. An unresolved plan stays open while you deal with it.

A CHI 2025 survey of 319 knowledge workers found that participants described a shift in critical thinking toward verifying information, integrating AI responses, and overseeing the work.⁴ This was a self-report survey, so I read it as evidence about the thinking people describe doing. It helps explain why delegating production still leaves substantial work for the person using the result.

I worry about a day made almost entirely of those transitions. You finish reviewing one thing and immediately have to make a scope decision about another. There is little time to stay with a problem long enough to understand it better, and plenty of material that needs a response.

"Hand me a document, for humans"

The same pressure shows up in writing. Generating a long plan or report with an LLM is fast. Getting it ready for a human reader is harder and usually takes longer than the initial generation.

"Hand me a document, for humans" makes sense to me as a new default request between colleagues. It asks the sender to do the work that comes after the first draft, and that work requires sustained attention.

A generated document can give every alternative equal space, repeat the same point under several headings, and leave the recommendation buried somewhere in the middle. It can look finished while still leaving the important decisions unresolved.

Preparing it for someone else means checking the claims, resolving contradictions, and choosing which details matter. You have to cut passages that sound polished but add nothing, make the recommendation explicit, and supply context the reader never saw in the conversation with the model. Deciding what to leave out can take more thought than producing another page. Each pass can expose another question you need to settle before the document is useful.

I want to receive something the sender has read and taken responsibility for. Tell me what you recommend, why you recommend it, and what remains uncertain. Give me enough context to judge the recommendation. Keep the supporting detail available when it helps.

That editing and judgment need to be included in the time we allow for writing. The draft appearing quickly can create pressure to send it quickly too, while most of the work needed to make it useful is still ahead. Sending it immediately passes the checking and interpretation to the reader, who now has to work out what the sender believes and what decision they are being asked to make.

There is something uncomfortable about asking an LLM to expand an idea, sending the result to a colleague, and having that colleague ask another LLM to summarize it. The exchange can finish without either person settling what they actually think. A shorter document with a clear recommendation would give them somewhere to start.

The hour keeps growing

Imagine a team whose immediate priority is fixing customer onboarding. Someone suggests an internal dashboard. It would be useful, and the first version might take an hour with Claude.

The dashboard now needs a specification and a review. Someone has to check where its numbers come from. Once people use it, they ask for changes. Even before maintenance becomes a concern, the team has another thread to follow while the onboarding problem waits.

The implementation estimate left out most of that attention. It also left out the work displaced by the new request.

When implementation was expensive, the estimate itself could force a conversation about priorities. If a feature needed weeks of engineering, someone had to explain why it deserved them. A smaller estimate makes it easier to skip that conversation. Enough individually reasonable requests can fill the team's day before anyone has chosen what matters most.

That is why I think prioritization matters more as implementation gets cheaper. "We can build it quickly" leaves the question of whether we should spend attention on it unanswered.

Faster to success, faster to failure

Cheap implementation can be an excellent way to learn. If we have a clear question, we can build a small experiment, test an assumption, and stop when we have an answer. Faster feedback can help us change direction earlier.

The difficulty comes when the question is vague and the implementation becomes the plan.

Something runnable is easier to discuss than an unresolved priority. People start improving what is in front of them. Another feature gets built around it, someone prepares a demo, and a colleague starts depending on it. The code may have been cheap to produce, but the decisions around it accumulate.

Changing direction then means asking people to let go of work they have reviewed, explained, and started using. You also need enough uninterrupted attention to notice that a change of direction is needed. A queue of implementations waiting for review can consume the time you would have spent asking that question.

Speed helps us reach success or failure sooner. Turning failure into useful learning still requires a reason for the experiment, a way to judge it, and a willingness to stop. Otherwise, we can spend the time saved on implementation extending an idea whose purpose was never clear.

Before starting another agent, I want to be able to explain why this task comes next, what result would be useful, and who has time to review it. That can be a short conversation. It needs to happen while the work is still easy to decline or change.

I still want the faster tools. I want fewer hours lost to work that can be delegated, and more room to think carefully about the work that matters. That only happens if we protect the time we save. An agent finishing a task creates an opportunity to choose what comes next, including the opportunity to stay with the problem already in front of us.

TL;DR

AI makes it cheaper to build and write. Choosing what matters, switching contexts, reviewing results, and reading carefully still require human attention. A day full of planning and review can be draining even when output increases. Getting an LLM-generated document ready for humans usually takes longer than generating it: the author still has to verify the claims, edit the text, and decide what the reader needs.

"It's just one hour with Claude" counts only implementation. Before starting another task, decide why it comes next, what a useful result looks like, and who has time to review it. Faster implementation helps us learn when priorities and stopping points are clear. Without them, it can create dependencies and commitments that make changing direction harder.

Footnotes

1. Joseph Arrieta (2026). Getting your repo ready for background coding agents. CodeCarvers. ↩

2. Sophie Leroy (2009). Why is it so hard to do my work? The challenge of attention residue when switching between work tasks. Organizational Behavior and Human Decision Processes. ↩

3. Gloria Mark, Daniela Gudith and Ulrich Klocke (2008). The Cost of Interrupted Work: More Speed and Stress. CHI 2008. ↩

4. Hao-Ping Lee et al. (2025). The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers. CHI 2025. ↩