The author is neither a lawyer nor a doctor. The medical and legal analogies in this essay are based on outside observation, so the details may not be rigorous. Please focus on the bigger picture — decision density and how context is operated.
1. Not a Productivity Explosion — Decision Fatigue
I've read all kinds of writing about how AI and developers work together, but my day-to-day didn't quite line up with the usual "productivity explosion" narrative. The making part definitely got faster. But at the same time, something felt strangely tiring. And I couldn't quite put into words where that fatigue was coming from.
It took a few days of self-questioning before the shape of it started to come through. AI doesn't keep asking me what to make — it keeps asking me what to choose. "Should we dig into the root cause of this error, or just paper over the symptoms?" "Option A or option B?" "Should this feature ship this iteration?" Productivity exploded, and so did the volume of decisions that came along with it.
This essay started as an attempt to take that fatigue apart and — by holding up professions that have lived with similar burdens for a long time (medicine, law) as a mirror — see if a structure might point to a response.
2. A Scene: The Three-Minute Exam at a University Hospital
A while back my wife went through chemotherapy. The oncologist at the university hospital really did, in three minutes, scan the previous test results, check her status, state the next treatment plan, and move on to the next patient. That's when I understood why people talk about "three-minute medicine." From the patient's side it feels cold. From the doctor's side, if you don't run at that speed, today's clinic doesn't end.
This is the typical scene of a profession with high decision density. One judgment every three minutes, dozens to hundreds per day — and it's not just doctors. Judges who issue short rulings dozens of times a day, like in parole hearings or warrant applications, are in the same boat. There's a fascinating study showing that judges' rulings shift with the time of day — right before lunch the parole approval rate dropped to almost 0%, and right after lunch climbed to 65%. Lawyers also face matter-by-matter decisions in succession. High-decision-density professions have always existed.
What I've been feeling, working with AI, is that the developer profession is rapidly moving onto that map. Time spent writing code is shrinking; time spent making judgments is growing. The closer making time converges to zero, the more what's left is choosing "what to make," "why to make it," "which is better."
3. The Analogy Only Half Fits
At first I tried to wrap it up with "developers now have to work like oncologists at university hospitals." But when I looked closer, the details didn't line up.
The list of things developers ask AI looks like this: "What's the root cause of this bug?" — diagnostic questions. "Suggest three approaches to solve this problem." — treatment-selection questions. The answers to these two types of questions can be almost entirely delegated to AI, and that's exactly what an oncologist's main job consists of. Diagnosing, and choosing the treatment.
So what's left in the developer's hands? Trade-off decisions (speed vs. stability, simple vs. flexible). Scope decisions (include this feature or not, touch this now or not). Taste and style (naming, folder structure). And the hardest set of all — product and business judgments. "How to build it" has already been handed off to AI, and only "why · what · how far" remains in my hands. We need a new analogy.
4. The Structural Shift Across Three Axes
Looking carefully, the axes of the developer's job that AI shifted aren't just one. At least three moved at once.
Axis 1: Decision density. The number of judgments per unit time spiked. Before, a developer could spend a whole day grappling with a single issue. Now AI keeps asking for decisions by the minute, so the density of necessary judgments inevitably grows.
Axis 2: Context persistence. A doctor can close one patient's chart and move on (wipe out); a judge can externalize each case into the record and clear their memory. A lawyer, on the other hand, carries a single client across years. Short-cycle wipe outs aren't possible, so residual context stays in the head — which is exactly where the AI-augmented developer ends up.
Axis 3: Parallelism. I used to do one thing at a time; now I run several AI agents at once. Three terminals, two agents, a preview in the browser. But here's the limit: AI executes in unbounded parallel, but the human attention that has to make the resulting judgments is still serial.
I drew a matrix of where these three axes intersect.
Doctors and judges sit in the bottom-right. Decision density is high, but wipe out is possible. Where I sit is top-right. I hold a finite set of apps over the long term, the decision density has climbed to doctor/judge levels, and on top of that comes parallelism.
This quadrant has historically been the law-firm partner's seat.
5. The Lawyer's Quadrant, and Concurrency in the Decision Queue
Imagine a law firm partner's day. Multiple matters running in parallel, each matter sustained over a long time. Morning: review client A's brief. Noon: client B on the phone. Afternoon: strategy meeting on matter C. Decision density is high, and each matter carries thick context.
But there's a reason the partner can sustain this. Before issues reach the partner's desk, paralegals and junior associates have already filtered them once, and matter-by-matter standard responses are protocolized — so the partner only sees what genuinely requires partner-level judgment.
Compare that with the growing pains I'm going through. Multiple AI agents ping me with "please decide" simultaneously. Not sequentially. Simultaneously. One asks "go this direction?", another "how do I handle this error?", another "scope is creeping, what now?".
So what do I become? I become one person doubling as partner + paralegal + secretary. There's no one to filter before I judge. There's no court schedule to enforce time blocks, no booked conference room. Pings come, and I have to take them as they come, and the moment I take one, switching cost begins.
This was the actual identity of the fatigue I'd been feeling. The problem wasn't the count of decisions but the simultaneous arrival of decisions. Not density, but concurrency in the decision queue.
6. The Principle — Evidence over Hypothetical
Once this structure became visible, the nature of the questions I was getting from AI started looking different.
When I'd been getting abstract choices like "option A or B?", I'd actually been simulating each in my head to judge — which, on reflection, is a luxury. In an era when production cost is converging to zero thanks to AI, the most expensive thing left is the simulation in a human's head.
So the rule I arrived at is this:
The closer production cost converges to zero, the more you should make and present rather than ask. Get the human to judge from outputs, not hypotheticals.
Instead of "should I do A or B?", I should be receiving "I built A and B as previews — please check and tell me which one." Doctors and judges work this way too. They judge based on evidence, not hypotheses. Abstract choices turn humans into philosophers; concrete outputs turn them into judges.
I'll call this the Evidence over Hypothetical principle. It's the root of the response mechanisms discussed below.
7. Two Tracks of Response — Automation on the AI Side, Scheduling on the Human Side
While searching for ways to handle decision-queue concurrency, I realized the path forks in two. At first I thought one was "engineering" and the other was "personal routine," but on closer look that wasn't right. The real boundary lies elsewhere — what AI can do for you, and what only humans can do.
Track 1: Output Automation — Anything AI Can Produce, Hand Off to AI
This is the side that tunes AI's working environment. Give AI authority to make certain types of decisions on its own, document recurring decisions as project-specific standard responses, enforce the evidence-based pattern from above so abstract questions never bubble up. CLAUDE.md, DECISIONS.md, per-agent preambles, sub-agent delegation patterns — all of this belongs here.
A step further: even the lawyer's case file can be absorbed into this track. A one-line system prompt like "update STATE.md after every reply" handles it. Decision logs, switch memos, context summaries — every document AI can produce belongs to the harness. In short, you build the system that filters issues at the paralegal layer before they reach the partner's desk, and slides the case file along with them.
Track 2: The Human Scheduler — Optimizing Context Switching for Serial Attention
When you think about it, this is exactly the OS scheduler problem. A CPU can only run one process at a time, so the OS is carefully designed around when to load and unload which process and how to reduce context-switching cost. Track 2 is the same problem with human attention in the CPU's seat. The terminology transfers cleanly:
- Scheduling policy: handle incoming pings immediately (interrupt) or queue them up and batch at safe checkpoints (cooperative). All "deep work" advice is essentially recommending cooperative scheduling. (Maybe turning off your terminal notifications is what would actually raise your productivity.)
- Context-switching cost: OSes measure it in cycles; humans measure it in "the time it takes to load a matter back into your head." The case file is cache warm-up — quickly reconstructing context that had been flushed.
- Locality: bundle related work on the same matter into the same time block. Process while the cache is still warm.
- Rate limiting: when too many pings come in, queue and throttle them. Never receive them as interrupts.
The doctor/judge examples introduced earlier are near-stateless simple scheduling — just wipe out per patient/case. The lawyer example is relatively stateful scheduling, carrying rich context per matter, which is why elaborate switching aids like case files and time blocks evolved. The mode worth our attention may well be the senior partner at a large law firm.
Why the Two Tracks Are Separate
Because they're not solved by the same tool. Track 1 is automating everything AI can produce — the realm of prompts, scripts, file structures. Track 2 is how to allocate those outputs across one human's serial attention — that is, tuning the human-side scheduler — the realm of calendars, queues, switching rituals.
And here's the important part: even if track 1 reaches perfection, the burden of track 2 doesn't go to zero. If anything, the better track 1 gets, the more pronounced track 2's burden becomes — because the volume of outputs entering the queue grows. It's the same phenomenon as OS schedulers becoming more sophisticated in the multi-core era. This was the actual identity of the fatigue I'd been chewing on for days.
8. What Remains — The Quality of Judgment Equals the Quality of Your Harness and Scheduler
After laying it all out, one thing has become clear. The shift from builder to decision maker is irreversible. And what I, as a developer, should be improving has shifted along with it.
Once, "improving my craft" meant knowing things more deeply, writing things more quickly. Now it's different. The quality of my judgment is my craft. And the quality of judgment depends not on how many decisions I make per day, but on how well I've set things up so they can be sampled and judged.
To put it differently — a developer's judgment quality equals the quality of their harness and scheduler. When and how do you make evidence surface (harness)? How cleverly have you packaged recurring decisions (harness)? In what time structure do you run your own attention (scheduler)? The ability to design these two together is the real craft of the developer in this era.
I think back to that doctor's speed in the three-minute exam. She could judge at that speed because she stands on top of a massive harness — decades of clinical experience, treatment guidelines, charting standards, the division of labor with residents and nurses — and a refined scheduler that takes patients in minute-long slots. We're in the middle of building both right now. A lot is still missing, and that's why our heads ache. But the direction is this way.
If this resonates, I'll share the more detailed playbook I've been trying out.