Where Does the Time Go When Waiting for AI?

You tell Claude Code to refactor an authentication module. It gets to work—reading files, analyzing dependencies, forming a plan, writing code, running tests.

The progress bar moves. Estimated time remaining: 8 minutes.

What do you do for those 8 minutes?

Stare at the terminal as output scrolls? Pick up your phone and scroll through social media? Switch to another tab to handle something else, but just as you’ve loaded half the context, Claude finishes and you get pulled back to review the results—only to realize you’ve completely lost track of where you were in the previous task?

In all the narratives about “AI saves you X hours,” there’s a systematically overlooked variable: AI work itself takes time, and your state during this time isn’t “working” nor “resting”—it’s “waiting.”

This waiting isn’t idle time. It’s a state of cognitive semi-occupation: you can’t fully disengage (since you might need to review results at any moment), nor can you dive deep into something else (because the switching cost is too high). It’s the biggest hidden time sink for programmers in 2025.

The operating system solved this problem 60 years ago. It’s called “process scheduling.”

A Problem Solved 60 Years Ago

Computers in the 1960s faced a painful reality: the CPU was very fast, but I/O (disks, printers, networks) was extremely slow. While a program was waiting for data to be read from the disk, the CPU just sat there. Idle. Wasting cycles.

The solution was multiprogramming—when one process was waiting for I/O, the CPU switched to another process to keep working. This evolved into increasingly sophisticated scheduling algorithms:

FCFS (First-Come, First-Served): Whoever arrives first runs first. Simple but inefficient—a slow process can block the entire queue.
Round Robin: Each process gets a small time slice, taking turns. Fair, but frequent switching has overhead.
Priority Queues: Important processes run first. Flexible, but requires accurate priority assessment.
Multilevel Feedback Queues: Dynamic adjustment—new processes get high priority; those that haven’t finished after a long time are automatically demoted.

The core goals of these algorithms are threefold: maximize CPU utilization, minimize wait time, and balance fairness with efficiency.

Now replace “CPU” with “your attention” and “processes” with “AI tasks,” and you’ll see this is a perfectly isomorphic problem:

Your attention is a scarce resource (like the CPU), able to fully focus on only one thing at a time.
There are many AI tasks (like processes waiting to execute), each requiring different amounts of time.
While the AI is reasoning (like a process waiting for I/O), your attention is sitting idle.
The goals are the same: maximize your output, minimize idle waiting, and balance depth with breadth.

But there’s a key difference: the cost of an OS context switch is measured in microseconds. The cost of a context switch for your brain is measured in minutes.

This difference determines: humans cannot switch contexts as frequently as a CPU. The optimal strategy for humans isn’t “switch faster,” but “switch less”—or more accurately, only switch when it’s worth it.

The 19% Slower Truth: Scheduling Overhead

In July 2025, METR released a study that surprised everyone: 16 experienced open-source contributors were 19% slower when using AI tools (Cursor + Claude 3.5 Sonnet) to complete complex tasks compared to not using AI.

Not beginners. Senior developers. Not simple tasks. Complex tasks within open-source projects they themselves maintained.

And—developers self-reported “feeling faster.” Objective measurement said: No, you were slower.

Why?

Researchers identified several factors: time spent writing prompts, time reviewing AI code for correctness, time debugging subtle errors introduced by AI. But these are just the surface.

The deeper reason, as revealed by Gloria Mark’s research (UC Irvine), is: each task interruption takes an average of 20+ minutes to recover from. For programmers, it takes 10-15 minutes to get back to an editing state, and 30-45 minutes to return to a deep flow state. If you’re interrupted every 15 minutes, you’ll never enter a flow state.

What do AI tools do? They give you a suggestion every few seconds to minutes: Accept? Reject? Modify? Each suggestion is a micro-interruption. Your brain must switch from “implementation mode” to “review mode,” make a judgment, and then switch back.

Researchers call this “orchestration overhead.” The work didn’t disappear. It shifted from “writing code” to “managing AI-written code.” For complex logic requiring sustained attention, this back-and-forth is a net negative.

This is the core contradiction of the scheduling problem: AI speeds up execution but makes scheduling more expensive. If your scheduling strategy is “let the AI write a line and I’ll review every line”—congratulations, you’ve turned yourself into an inefficient “human round-robin scheduler,” where context-switching costs eat up all the time AI saved.

Four Human-AI Scheduling Strategies

Since this is a scheduling problem, systematic strategies can be applied. Here are four, from simple to complex:

Strategy 1: Serial Blocking

You → Give instruction → Wait for AI to finish → Review → Next instruction

You are like a 1960s single-program CPU—one task at a time, sitting idle while waiting for I/O.

When to use: AI tasks are very short (<30 seconds), or you have high uncertainty about the results and need to see them immediately. Cost: A lot of waiting time is wasted. If Claude Code runs for 8 minutes, you’re idle for 8 minutes. Reality: The default mode for most people. Also the least efficient.

Strategy 2: Time-Slice Round Robin

You → Send Task A to AI → Switch to work on Task B → AI completes A → Pause B → Review A → Continue B or switch to C

This is classic Round Robin—switching between multiple tasks, giving each a slice of attention.

When to use: You have multiple independent tasks that can be progressed in parallel. Cost: Context switching. Each switch requires paying the cognitive cost of “reloading context.” If Task B is complex, switching away for 5 minutes and switching back might take 10 minutes to recover. Key tip: Task B must have low context-switching cost—writing documentation, replying to Slack messages, doing simple code reviews, organizing a TODO list. These tasks don’t require deep flow state and can be interrupted and resumed at any time.

Strategy 3: Asynchronous Batch Queue

You → Prepare specs for 5 tasks in batch → Send all to AI / multiple agents → Do your own deep work → Review all results together 1 hour later

This is the most efficient strategy—it completely decouples human and AI work. AI executes in batches, humans review in batches. No back-and-forth switching.

Addy Osmani (Google Chrome team) described this approach: “I’ve dabbled in this ‘massively parallel’ approach; it’s surprisingly effective at getting a lot done.”

When to use: Tasks can be clearly defined (spec-first) and are independent of each other; you don’t need to see real-time results of every step. Cost: Requires more upfront time investment for task planning and spec writing. If the spec is unclear, the AI might go off track for an hour before you realize it. Key prerequisite: You must have strong task decomposition skills—breaking a big goal into multiple independent, well-specified sub-tasks. This is itself an advanced skill.

Strategy 4: Layered Scheduling (Human as Decision Layer, AI as Execution Layer)

Your attention stays only at the "architectural decisions" and "direction judgment" level
AI handles all "implementation details" level work
You are only "interrupted" when the AI encounters architectural-level issues (similar to OS hardware interrupts)

This is the closest model to “humans as the OS kernel”—you don’t participate in the production or review of every line of code; you work only at higher abstraction layers: defining problems, designing architecture, judging direction, accepting results.

When to use: You have a deep understanding of the problem domain, can write precise high-level specs, and the AI’s execution quality is high enough that it doesn’t need line-by-line review. Cost: Building trust in AI capability requires a process. If the AI frequently makes errors in details, you’ll be constantly “pulled back” to the execution layer, and the layering collapses. Reality: Currently, only a few top developers can consistently operate in this mode. But as AI capability improves, this will become an increasingly common target state.

The Benefits and Costs of Parallelism

Faros AI’s telemetry data provides a picture from a large-scale real-world environment:

Metric	High AI Usage Teams vs. Low Usage Teams
Daily interactive tasks	+9%
Daily PRs	+47%
Task completion rate	+21%
Merged PRs	+98%
PR size	+154%
Review time	+91%
Bugs / developer	+9%

This table tells a complete story: AI indeed helps developers do more (throughput increased), but the cost is that everything becomes larger, harder to review, and more error-prone.

Faros researchers put it accurately: “This isn’t traditional multitasking (which research has shown to be counterproductive). This is a fundamental shift in work style—when AI can share the workload, engineers can orchestrate multiple parallel workflows simultaneously.”

But they also found: single-task speed did not improve. Parallelism increased total throughput but didn’t make any single task faster. If you’re doing just one thing, AI might even make you 19% slower.

This is exactly the dividing line for scheduling strategy—your output doesn’t depend on “how fast AI can complete a task,” but on “how many AI tasks you can orchestrate simultaneously.” The upper limit of the latter is determined by your scheduling ability: How many independent sub-tasks can you decompose? How much cognitive load from parallel flows can you tolerate? How quickly can you make review decisions?

METR measured single-task efficiency. Faros measured system throughput. Both conclusions are simultaneously true: AI makes individual tasks slower but makes the system faster—provided you know how to schedule.

Those who don’t schedule experience METR’s conclusion: slower, more tired, “feels fast but actually slow.” Those who do schedule experience Faros’s conclusion: more output, more parallelism, higher throughput.

The difference isn’t in AI’s capability. The difference is in your capability as a “scheduler.”

Your Attention is the CPU

Back to those 8 minutes. Claude Code is running. What should you do?

The answer depends on which scheduling strategy you’re running.

If you’re in serial blocking mode (the default for most people): Those 8 minutes are essentially wasted. You’ll pick up your phone or anxiously stare at the progress bar. Then Claude finishes, you review the result. Send the next task. Wait again. At the end of the day, your actual “high-productivity time” might be only 3 hours.

If you’re in asynchronous batch mode (the goal for efficient developers): You won’t send just one task. In the morning, you’ll spend 30 minutes breaking today’s work into 5-8 independent, clearly-specified sub-tasks. Then you’ll launch 3 parallel agents or queue tasks for the AI. For the next 2 hours, you’ll do your own deep thinking work—writing architectural documents, making technical decisions, discussing direction with colleagues. After 2 hours, you’ll review all AI outputs together. At the end of the day, you’ve progressed 8 things simultaneously.

Specific operational advice:

1. Categorize your tasks into three types. - Fully delegatable: Implementation tasks with clear input/output specifications (writing tests, refactoring, formatting, translating docs) → Send directly to AI, no need to wait. - Requires collaboration: Tasks with a general direction but details requiring human judgment → Use chunked iteration (check in at each step, provide direction). - Must do yourself: Tasks requiring deep thought, creativity, or political judgment → Don’t use AI, protect your flow state.

2. Use “waiting periods” for low context-switching cost tasks.

When AI is running, don’t switch to another high-complexity task—that will make you poor at both. Switch to “fast-food” tasks: replying to messages, checking email, writing brief docs, organizing a TODO list. The context-loading cost for these tasks is near zero and can be interrupted anytime.

3. Batch reviews, don’t review line-by-line.

Every time AI gives you a suggestion and you switch to look at it—that’s the most expensive scheduling mode. Accumulate them, review 5 results at once, make unified judgments. Just like code review should look at entire PRs rather than live-monitoring line by line.

4. Invest in “spec-writing” ability.

The prerequisite for asynchronous batch mode is your ability to write clear specs. If your instructions are vague, AI misunderstands, and runs for 20 minutes doing the wrong thing—you not only haven’t saved time but have wasted it. Spec-writing ability = the quality of you as a “scheduler.” Vague specs are like an OS assigning processes to wrong memory addresses—resulting in segfaults.

5. Protect deep work time blocks.

The ultimate scheduling strategy isn’t “filling waiting time”—but making waiting time disappear from your workday. How? Front-load all AI tasks to the start of the workday (send tasks, set specs, launch agents), then spend the entire morning doing deep work, and batch-review and iterate in the afternoon. AI’s reasoning time gets scheduled during periods when you don’t need its results anyway.

This isn’t a collection of productivity tips. It’s a core question about attention economics: when AI reduces execution cost to near zero, scheduling cost becomes the new bottleneck. Your value is no longer determined by “how fast you can write code”—but by “how efficiently you can orchestrate human-AI collaboration.”

In the token elasticity article, I said “saved 38 minutes”—that’s a statement that needs correction. More accurate expression: under an optimal scheduling strategy, AI’s reasoning time can be completely hidden within your other work, equivalent to “saving 38 minutes.” Under the worst scheduling strategy, you have 10 extra minutes of waiting and 20 minutes of context-switch recovery—the net effect might be negative.

The OS scheduler is transparent—you don’t need to tell the CPU when to switch processes. But in human-AI collaboration, you are your own scheduler. No one switches for you. No one decides for you when to do deep work, when to review AI output, when to batch-send tasks.

The quality of this scheduler determines whether AI is “19% slower” or “47% more productive” for you.

Appendix: Sources Referenced in This Article

METR study (AI slows experienced developers by 19%): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Gloria Mark interruption recovery research: cited from https://super-productivity.com/blog/ai-coding-tools-focus-guide/
Faros AI telemetry study (10,000+ developers): https://www.faros.ai/blog/lab-vs-reality-ai-productivity-study-findings
Faros AI original report: https://www.faros.ai/blog/ai-software-engineering
Addy Osmani 2026 AI Coding Workflow: https://addyosmani.com/blog/ai-coding-workflow/
AI Coding Tools’ Impact on Focus: https://super-productivity.com/blog/ai-coding-tools-focus-guide/
Cerbos: The Productivity Paradox of AI Coding: https://www.cerbos.dev/blog/productivity-paradox-of-ai-coding-assistants
Agentic Coding Cost Analysis (Vantage): https://www.vantage.sh/blog/agentic-coding-costs