Healthy AI First · Episode 4 · 18 min
How Much Can Run at Once

At 10:40 in the morning, 3 of Jonas's 4 agents reach for him at the same time, and a couple of rooms away, Miriam loses track of her own quarterly plan across 3 AI chats. This episode explains attention residue, takes apart the myth of the "23 minutes", and uses Little's Law to show why more agents with the same review capacity mostly mean longer waits. Plus a tool tip on separate git worktrees, a resumption point for every switch, and a suggestion to try out, for developers and for the office.
Listen on
Companion document
All studies, sources and claims from this episode in one PDF, to read along or look things up later.
Download the companion document (PDF)Chapters
- 0:00Cold Open
- 1:24Welcome
- 2:05The Juggler
- 3:11Miriam's Morning
- 4:13What Stays Behind
- 5:27The 23 Minutes
- 6:53A word from us
- 7:44Small Portions
- 9:10The Queue at the Pass
- 10:42How Many Balls
- 12:16Separate Working Copies
- 13:53The Resumption Point
- 15:16A Limit for the Team
- 16:18Until Next Time
Show notes
Fictional characters: Jonas (junior developer), Daniel (senior developer), Miriam (team lead for Daniel and Jonas). The Little's Law calculation is an illustration, not a measurement.
Try this week
- With coding agents: a single complex task you actively supervise, at most a quiet background job, a fixed limit for changes waiting for your review (for example 3), and a resumption point of a few lines at every switch.
- At the office (writing, planning, analysis): a separate chat for each topic and a single topic you're actively working on, at most 3 drafts waiting for approval, and before switching chats, a couple of lines in a note: what's decided and what comes next.
- Watch not only how much gets done, but also how you feel in the evening.
Tool tip: separate git worktrees for parallel agents
Run parallel agents in separate git worktrees so they don't overwrite each other's files. In Claude Code: claude --worktree <name> (short form -w), with a different name in a second terminal. Important: each worktree only sees its own state. When 2 branches change the same part differently, Git may report a conflict; "semantic" conflicts (one side renames a field, the other keeps reading it) can still merge cleanly as text. So review the changes together and run appropriate tests on an integrated version; tests do not catch every conflict either. So merge early and often. In addition, put rules like "never rename database fields without asking" into the instructions file (CLAUDE.md for Claude Code, AGENTS.md for Codex). It is read as context, not enforced; real blocks are built with hooks.
Sources
Attention, interruption, resumption
- Leroy, S. (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, 109(2), 168-181. Two experiments. https://doi.org/10.1016/j.obhdp.2009.04.002
- Leroy, S. & Glomb, T. M. (2018). Tasks Interrupted: How Anticipating Time Pressure on Resumption of an Interrupted Task Causes Attention Residue and Low Performance on Interrupting Tasks and How a "Ready-to-Resume" Plan Mitigates the Effects. Organization Science, 29(3), 380-397. Four studies. https://doi.org/10.1287/orsc.2017.1184
- Mark, G., Gonzalez, V. M. & Harris, J. (2005). No Task Left Behind? Examining the Nature of Fragmented Work. CHI 2005. 24 observed information workers (3 days each); on average about 11 minutes in a working sphere before switching, 57 percent of working spheres interrupted, 77 percent resumed the same day, on average after 25 minutes 26 seconds with 2.26 intervening working spheres. https://doi.org/10.1145/1054972.1055017 (PDF: https://www.ics.uci.edu/~gmark/CHI2005.pdf)
- Gallup Business Journal (2006). Too Many Interruptions at Work? Interview with Gloria Mark; source of the "23 minutes and 15 seconds" figure (time until returning to the interrupted task, not time to regain focus). https://news.gallup.com/businessjournal/23146/too-many-interruptions-work.aspx
- Mark, G., Gudith, D. & Klocke, U. (2008). The Cost of Interrupted Work: More Speed and Stress. CHI 2008, 107-110. Lab experiment with 48 participants, mostly German university students; a short email task, the same people with and without interruptions; in interrupted conditions active task time was shorter (interruption time subtracted), no statistically significant difference in errors or politeness, but participants reported more stress, frustration, workload, effort and pressure after about 20 minutes. https://doi.org/10.1145/1357054.1357072
- Risko, E. F. & Gilbert, S. J. (2016). Cognitive Offloading. Trends in Cognitive Sciences, 20(9), 676-688. https://doi.org/10.1016/j.tics.2016.07.002
Small changes and review
- DORA: Working in small batches (capability, continuously updated). "Any batch of code that takes longer than a week to complete and check is too big"; large AI-generated pull requests named as a pitfall. https://dora.dev/capabilities/working-in-small-batches/
Queues and WIP limits
- Little, J. D. C. (1961). A Proof for the Queuing Formula: L = λW. Operations Research, 9(3), 383-387. https://doi.org/10.1287/opre.9.3.383
- Little, J. D. C. (2011). Little's Law as Viewed on Its 50th Anniversary. Operations Research, 59(3), 536-549 (on validity and assumptions, including long-run averages). https://doi.org/10.1287/opre.1110.0940
- Kingman, J. F. C. (1961). The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), 902-904. Basis of Kingman's approximation: waiting time grows roughly like ρ/(1-ρ) with utilization ρ, so it rises steeply long before a system is overloaded. https://doi.org/10.1017/S0305004100036094
- DORA: Work in process limits (capability, continuously updated). https://dora.dev/capabilities/wip-limits/
Parallel agents, worktrees and merging
- Git documentation: git-worktree ("A git repository can support multiple working trees, allowing you to check out more than one branch at a time"). https://git-scm.com/docs/git-worktree
- Anthropic: Claude Code, Run parallel sessions with worktrees (
--worktree, isolated file edits). https://code.claude.com/docs/en/worktrees and https://code.claude.com/docs/en/common-workflows - Anthropic: Claude Code, How Claude remembers your project (CLAUDE.md is loaded at the start of every conversation and treated as context, not enforced configuration; use a PreToolUse hook to block an action). https://code.claude.com/docs/en/memory
- Codex documentation: Codex, AGENTS.md ("Codex reads AGENTS.md files before doing any work"). https://learn.chatgpt.com/docs/agent-configuration/agents-md
- Fowler, M.: Semantic Conflict (changes that merge cleanly as text but change how the program behaves; remedies: integrate often, test). https://martinfowler.com/bliki/SemanticConflict.html
- DORA: Trunk-based development ("Merge branches to trunk at least once a day"; the longer a merge is delayed, the more likely merge conflicts become). https://dora.dev/capabilities/trunk-based-development/
Further reading (not covered in detail in this episode)
- Parnin, C. & Rugaber, S. (2011). Resumption Strategies for Interrupted Programming Tasks. Software Quality Journal, 19, 5-34. About 10,000 programming sessions from 86 programmers; editing began within a minute of returning in only about 10 percent of them. https://doi.org/10.1007/s11219-010-9104-9
- Trafton, J. G., Altmann, E. M., Brock, D. P. & Mintz, F. E. (2003). Preparing to resume an interrupted task. International Journal of Human-Computer Studies, 58, 583-603. An 8-second warning made resumption slightly faster. https://doi.org/10.1016/S1071-5819(03)00023-5
- Google Engineering Practices: Small CLs. About 100 lines is usually reasonable, about 1,000 usually too large, no fixed limit. https://google.github.io/eng-practices/review/developer/small-cls.html
- Sadowski, C. et al. (2018). Modern Code Review: A Case Study at Google. ICSE-SEIP 2018. About 9 million changes; median 24 changed lines; median of one reviewer. https://doi.org/10.1145/3183519.3183525
- SmartBear: Best Practices for Code Review (vendor claim, based on a Cisco team around 2006; 200 to 400 lines at a time). https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
Foundation of the series
- Healthy AI First Software Development, version 2 (October 1, 2026), chapter 5 "Small changes and limited review work" and chapter 7 "Context switching and agent WIP". The pilot rules (15 to 30 minutes per review, one supervised task plus one background job, a resumption point of 5 to 6 lines) are explicitly marked there as proposals to test, not research findings.
Healthy AI First is AI-researched and AI-generated, narrated in Björn's voice, recreated with AI, and reviewed by him.
Bringing AI into your team?
Björn is one of the founders of CLN Work. CLN Work helps companies adopt AI in small, verifiable steps: finding where real capacity is, which processes can be automated, and how to use AI interactively. The decisions stay with you.
Book a free 30-minute conversation