By Phillip Gales · May 2026
Last Tuesday
Last Tuesday, I worked for eleven hours. I produced, by any external measure, the output of a fifty-person engineering team. I made decisions on twelve architectural trade-offs, signed off four briefs, locked three work scopes, and watched roughly four-and-a-half thousand lines of production code merge to main.
In the same eleven hours, I also watched two documentaries about the Chernobyl disaster, three about the Hindenburg, and one — for variety — about the structural failures that brought down the Tay Bridge in 1879. I read no books. I went outside twice, briefly. I ate a sandwich.
When I went to bed, I was more tired than I have been after any normal working day in twenty years of founding companies. I had not, in the conventional sense, done anything. I had been needed — briefly, intensely, at sharp irregular intervals — and the gap between being needed and not being needed had been, in aggregate, almost the entire day.
This article is about the gap. About the cognitive failure mode that lives in it. About a pattern I am going to call the 90/10, because nothing in the existing vocabulary fits and because naming the thing is the first step to taking it seriously.
I should say at once that this is the last piece in a six-part series on building software with AI agents, and it is by some distance the most personal. The earlier pieces argued the architecture: two-agent peer review, the eight-stage build pipeline, the product unit test layer, the brief loop, the Coordinator pattern. This piece is what happens to the human inside all of that. The previous five pieces are the technique. This one is the cost.
The 90/10, named
The shape of a founder's day, when supervising a multi-pod AI engineering operation, is not what the productivity literature predicts. It is not eight hours of focused work followed by sixteen hours of recovery. It is not the deep-work-and-shallow-work split Cal Newport wrote about. It is not even the pomodoro pattern of bursts and breaks, though it looks superficially similar.
It is, in practice, roughly the following. For ninety percent of any given working hour, I have nothing to do. The agents in each active pod are writing, reviewing, revising, and re-reviewing — none of which requires me. The Coordinator is shuttling artefacts between them — also without me. The pipelines hum along. I sit at my desk and, by any measure of doing, am idle.
For the remaining ten percent, I am at full intensity. A Coordinator surfaces an architectural decision. Two agents have disagreed on something neither can resolve from context. A locked-decision needs ratifying. The decision in front of me is, almost always, important — these are the questions the agents have already failed to answer, which means they are the ones requiring corporate context, taste, judgment, or irreducible trade-off arbitration. They take five to fifteen minutes each. They are mentally demanding in a specific way: I need to have, in my head, the full structure of the brief, the work scope, the codebase implications, and the strategic context.
The pattern is not new in human experience. Air traffic controllers know it. Anaesthetists know it. Bomb-disposal technicians have built an entire profession around it. The structure is: long idle stretches punctuated by short bursts of irreducible high-stakes attention. The literature on these professions — vigilance fatigue, boredom-induced burnout — is more relevant to AI-agent supervision than anything in the standard founder-productivity canon.
The reason this matters is that the 90/10 pattern, on inspection, is not less exhausting than continuous work. It is, in many cases, more exhausting. The idle ninety percent is not rest, because at any moment a question might surface that requires full context — which means I cannot context-switch away, read a book, take a walk, write an unrelated piece of code, or do anything that would let the cognitive structures necessary for the 10% decay. The ten percent that requires me is structurally indistinguishable from the most demanding work I have ever done in my career. The ninety percent that doesn't is structurally indistinguishable from waiting for a fire.
Why this isn't the burnout you think it is
There is now an emerging literature on burnout-from-AI-agentic-coding. Quentin Rousseau's "One More Prompt: The Dopamine Trap of Agentic Coding" (March 2026) describes a continuous-strain burnout pattern: the founder keeps asking the agent for one more thing, the agent keeps delivering, and the founder's reward system gets hijacked into a slot-machine loop. MindStudio's research note "Agent Burnout Hits at Hour 4" describes a fatigue cliff that arrives around the fourth hour of intense agent supervision.
Both descriptions are accurate and both are about the wrong failure mode.
The dopamine-trap framing assumes the founder is doing continuous high-engagement work with the agent. Push a prompt, see a result, push another prompt, see another result. The exhaustion is from the unbroken stimulation. The fatigue cliff at hour four is the same shape: a continuous demand on attention that the brain eventually rebels against.
The 90/10 pattern is structurally different. The exhaustion is not from continuous engagement; it is from the anticipation of engagement. Most of the time, I am not interacting with anything. I am sitting at my desk, available, waiting for the Coordinator to surface a question. The cost is not the engagement, which when it comes is welcome — it is the suspended attention required to remain ready for an engagement that may not come for thirty minutes, may come twice in five minutes, and may come at unpredictable enough intervals that I cannot plan anything else around it.
Vigilance fatigue is not dopamine-trap fatigue. The brain does not collapse from over-stimulation. It collapses from under-stimulation while being unable to stand down. Rousseau is describing a sprint. I am describing a standby shift.
If you have built or used the patterns described earlier in this series, you have, whether or not you realised it, run a standby shift. The question is whether you have built up the tooling and the personal discipline to survive doing it for a working week, a working month, a working year. I have, on most days, not. This is, in part, why I am writing this article.
Why you cannot context-switch
The intuitive solution to long idle stretches is to fill them with other work. Read a book. Reply to investor emails. Cook lunch. Take a walk. Run errands. Anything that converts idle time into useful time.
The intuitive solution does not work, and the reason it doesn't work is the most counterintuitive structural property of the 90/10 pattern.
The questions that come to me during the 10% require all the context. The brief, the work scope, the architectural decisions already locked, the dependencies on other pods, the corporate strategy in the background. None of this is information I can re-acquire on demand in five minutes when the Coordinator surfaces a question. It is information I have to be holding in working memory, more or less continuously, throughout the 90% idle stretch.
Holding the context, it turns out, is itself work. Not in the sense of producing output — no output is produced — but in the sense of occupying cognitive capacity. The same mental space that would otherwise be reading a book, replying to email, or thinking about something interesting is, in the 90% idle stretch, allocated to maintaining the architectural picture across the pods. The space is occupied. Nothing else fits in it.
This is why I end up watching documentaries. Documentaries — at least the kind I watch, about the failure of large physical systems — occupy almost none of the same cognitive structures as engineering decisions about software products. They run in parallel. I can hold the architectural picture in my head while watching the Chernobyl RBMK reactor explode for the eighth time, because the two pieces of content do not compete for the same mental real estate. I cannot, by contrast, read a book about software architecture or even an interesting essay about strategy, because those compete for the same space and they win — at which point I lose the architectural picture and become useless for the next surfaced question.
The 90/10 day, in practice, is a day in which I do almost nothing productive in the conventional sense and yet cannot, in any meaningful sense, do anything else. The idle ninety percent is not free time. It is held time. The cost of holding is hidden, distributed across the day, invisible from the outside, and unmistakable from the inside.
The weekend trap
The thing nobody warned me about, before I started running this kind of operation, is what weekends do.
Saturday morning. Coffee. The pods I shut down on Friday afternoon are quiet. I will, I decide, just check in. Take a look at the Coordinator's status board. See if anything pressing surfaced overnight that I want to address before Monday. Five minutes, ten at most.
Five minutes in, I notice that the brief loop on the recruitment feature has produced a third Codex review and the changes look like they are about to converge. I should, I think, just sign off at G1. That takes a few minutes of reading. While I am reading, I notice that the work scope for an adjacent pod has a subtle conflict with the recruitment feature's database schema, which I should probably flag before it propagates further. I open the other pod. I read the work scope. I file the conflict. The Coordinator surfaces a clarifying question. I answer it.
It is now eleven thirty. I have, technically, just checked in. I have not, in any sense, worked. And yet I am four hours into a Saturday in which I had planned to do anything but this, and the agents are now producing artefacts at the rate they would produce them on a Tuesday, which means my next "check-in" will arrive in roughly thirty minutes, and the one after that will arrive in roughly thirty minutes after that, and by three in the afternoon I will have spent the entire day in front of the screen.
This is, on inspection, the same trap Rousseau described — but it is also not. The dopamine-trap version of this is the founder who cannot stop because they love the work. The 90/10 weekend version is the founder who cannot stop because the cost of stopping is non-zero. If I disengage at eleven thirty, the pods continue producing artefacts that will require my attention by Monday, and Monday morning's queue will be twice the size it would otherwise be. If I keep checking in, the queue stays at zero and my actual working hours stay roughly the same — except that they are now distributed across Saturday and Sunday in addition to the weekdays.
The math is the trap. There is no rule that says I must check in on Saturday morning. There is also no obvious cost-free way to not. The agents are agnostic to my calendar. The Coordinator is agnostic to my calendar. The only entity that knows it is Saturday is me, and on a long enough timeline, that knowledge corrodes. The five-day week is a human convention. Without other humans in the system to reinforce it, the convention collapses.
I will not pretend I have solved this. I have, mostly, not solved this.
The Coordinator pattern is a force multiplier on this
The previous piece in this series described the Coordinator pattern — one human supervising multiple pods, each with its own Coordinator and its own specialist agents. The Coordinator pattern is, on every relevant metric, an improvement: more output per founder-hour, lower coordination overhead, cleaner role separation between human and agent.
It also, on the 90/10 axis, makes everything worse.
One pod produces, in practice, a surfaced decision roughly every thirty to forty-five minutes during active feature work. Three pods produce one every ten to fifteen minutes. Five pods produce one every six to nine minutes. Ten pods produce one every three to four minutes.
Note what is happening. The bursts are not getting longer — each burst is still five to fifteen minutes of intense thinking. What is shortening is the idle gap between bursts. At ten pods, the idle gap is so short that there is no recovery time. The 90/10 day, at scale, ceases to be a 90/10 day at all. It becomes a 50/50 day, or a 30/70 day, with continuous bursts and no continuous-context window. Which, perversely, is more like Rousseau's continuous-strain burnout than the original 90/10 pattern was.
The implication for founders adopting the Coordinator pattern at multiple pods: the cognitive economics get worse before they get better. The first pod is easy. The third pod is genuinely hard. The fifth pod is the upper bound of what one founder can sustain. The tenth pod is, in my experience, structurally impossible without help — by which I mean another human, doing the supervision role on a subset of the pods.
This was, on reflection, not the answer I was hoping for when I started running the pattern. I had assumed the marginal cost of adding pods was approximately zero. It is, in the agent-time and money axes, indeed approximately zero. In the founder-cognitive-bandwidth axis, the marginal cost rises steeply, and the slope steepens with each additional pod. The Coordinator pattern is not a path to running a hundred-and-fifty-person organisation as a solo founder. It is a path to running three to five pods as a solo founder, and a path to running more than that as a founder with help.
What I do about it
I will not pretend to have a complete answer. I have a handful of practices that, in combination, make the 90/10 day survivable on most days. They are not solutions; they are mitigations.
Hard daily stop. I have a fixed end time. The agents continue without me. Whatever queue accumulates overnight is handled in the morning. The discipline is to actually shut the laptop, not to plan to shut the laptop in fifteen minutes once this last thing resolves.
Planned offline windows. I block forty-five-minute windows during which the Coordinator is explicitly instructed to escalate nothing — to queue all decisions for the end of the window. This converts the unbounded 90% idle stretch into a bounded forty-five-minute one. The idle stretch is still held time, but only for forty-five minutes, not for indefinite.
Documentaries about catastrophic engineering failures. I am only partly joking. The cognitive structures that hold software architecture are different from the cognitive structures that follow narrative accounts of physical-system failure. Documentaries are the parallel-processing trick I use to make the held time more bearable. Books, podcasts, and conversation do not work. Documentaries do.
Push first-pass review out to synthetic readers. Where possible, I have the Coordinator route artefacts through a synthetic-persona pass before they reach me — usually a FishDog hedge-fund-analyst persona reviewing a brief for user-perspective concerns. The persona catches roughly a third of issues that would otherwise have reached my queue. Each issue that does not reach me is a 5-to-15-minute attention burst I do not have to spend.
Two-pod cap on bad days. When I notice the cognitive load is bleeding over from the workday into the evening — a specific somatic feeling I have learned to recognise — I cap the active pod count at two for the following day. It is the most reliable signal I have for "I am about to do harm to myself" and the most reliable lever I have for averting it.
A second human, eventually. This is the practice I have not yet, in May 2026, implemented but which I am increasingly convinced is the only path past five pods. A second founder, or a senior operator, who can hold the supervision context for two or three of the pods while I hold the rest. The arithmetic — two humans, ten pods, fifteen-person team output per pod, 150-person organisation output — is the operating model that will, I think, win the decade. The skill that will distinguish the founders who get there from the founders who burn out is the willingness to bring in the second human early enough.
When the pattern doesn't apply
Three configurations escape the 90/10, and I include them here in case you are reading this article wondering whether it is going to be your life.
Single-pod, interactive use. If you run a single pod and drive the brief loop manually — prompt by prompt, in conversation, with no Coordinator routing in the background — you do not experience the 90/10. You experience something much closer to Rousseau's dopamine-trap: continuous engagement, fast feedback, hour-four fatigue cliff. The exhaustion is real but it is the over-stimulation kind, not the vigilance kind. Different mitigations apply.
Supervision delegated from day one. If you split the founder role across two humans early — one for strategy and concept, one for supervision and pod-management — you experience neither failure mode. You experience the conventional cognitive shape of a 2024 founder, distributed across two heads. This is not, in my experience, the path most founders are currently taking. It is, almost certainly, the path more founders should be taking.
Founders who can let context decay. If you can genuinely let the architectural picture decay between bursts and rebuild it on demand in five minutes when the Coordinator surfaces a question, you escape the held-time cost. I have spoken to two founders who claim they can do this. I do not believe them — but I do not have a way to disprove the claim, and I include the configuration here because it is at least theoretically possible.
The 90/10 is the cognitive failure mode of one specific configuration: solo founder, multiple pods, continuous availability, the brief-loop discipline running in the background. Change the configuration; change the failure mode. Most of the founders I know are running this configuration, which is why I have written about it.
What the series adds up to
There were six articles. They argued, in roughly this order, that:
Frontier coding agents have surpassed individual human cognitive throughput on code, and the only verification layer that scales is a peer LLM, not a human.
The full eight-stage product development pipeline — concept through release notes — is now substantially done by AI agents, with the human at the gates only. The leverage is roughly 60-80× on human-time.
A new layer of testing — product unit tests — has emerged that asks "did we build what the brief said," executed by an LLM driving a headless browser against the brief.
The brief itself is best co-authored through a bidirectional loop between two frontier LLMs in alternating author and reviewer roles, with the human only at the gates.
The organisational shape that emerges around all of this is hierarchical: a Coordinator agent per pod, with the founder talking to Coordinators rather than to individual agents. The pattern scales to multiple pods, with the founder's cognitive bandwidth as the constraint.
The cognitive bandwidth, in practice, is a 90/10 split — long idle stretches of held context punctuated by short bursts of irreducible high-stakes attention. The pattern is exhausting in a way the productivity literature does not yet have language for. Naming it is the start of building tooling around it.
These six observations are, taken together, an architecture for running software companies that did not exist in 2024 and that will, I think, be the default by 2028. The economics are not subtle: one founder, three to five pods, $1,000-$2,000 per month in AI subscriptions, output equivalent to a forty-five-to-seventy-five-person engineering organisation. The cost is the human at the top of this pyramid, who pays in a currency the productivity literature does not yet price: vigilance fatigue, held context, weekend creep, and the slow corrosion of the five-day week.
I have written this series because I think the patterns are happening regardless of whether anyone names them. Founders contemplating this transition are about to walk into all six of these dynamics, and the lack of vocabulary will, in my experience, make it harder rather than easier. Naming gives you the tools to think about the trade-offs deliberately. Choose the patterns that fit your appetite for the costs. Build the tooling that mitigates the worst of them. And, if you are about to run a five-pod operation as a solo founder: hire your second human before you think you need them. Trust me on this one.
The agents are not tired. You will be. The math, on net, is still extraordinary. The future is, on most days, already here. It is also, on most days, exhausting in a way nobody told me about, and that is the entire reason I have written these six pieces.
Phillip Gales is the founder of [FishDog](https://fish.dog), a synthetic market research platform. This is the sixth and final piece in a six-part series on building software with AI agents. The previous pieces — Two AI Agents Are Better Than One: Why I Stopped Trying to QA Codex Myself, Anatomy of an AI-Built Product: 21 Days, 40 Hours of My Time, 128,506 Lines of Code, Product Unit Tests: A Missing Layer of QA in the Age of AI Engineers, The Product Brief Loop: How Claude and Codex Write Better Specs Than I Can, and The Coordinator: Why Founders Won't Manage People, They'll Manage Agents — argued the architectural case for two-agent peer review, walked a real product build through its eight stages, named the missing layer of QA, detailed the bidirectional discipline that makes AI-built specs work, and introduced the hierarchical Coordinator pattern for multi-pod founder-led organisations. This final piece names the cognitive failure mode the architecture produces.