# When the Agents Write the Code, the Human Checks Themselves [2/2]

In social psychology, decision fatigue has been described since Baumeister and colleagues in 1998 [1]. The exact mechanism (ego depletion as a central reservoir of willpower) has been strongly called into question by a multi-lab preregistered replication with 23 labs and over 2000 participants [2]. The phenomenon itself has not been: the quality of a decision measurably drops over the course of a sequence of decisions. The most robust evidence comes from a PNAS study of more than 1000 real parole decisions by eight experienced judges, observed over 50 court days [3]. Right after a break or lunch, roughly 65 percent of applications are granted. Over the course of the following session, the rate falls gradually, in individual sessions down to near zero, and jumps back up after the next break. A conceptual review from health psychology confirms that the phenomenon shows up across professions [4]. Clinical decision research provides a second, independent confirmation: a study of more than 21,000 outpatient visits in primary care practices shows that physicians increasingly prescribe antibiotics inappropriately over the course of each clinic session, peaking in the last hours before the lunch break [5]. Same mechanism, different context, same direction.

What happens in an agentic setup is the rapid translation of this mechanism into a developer’s day. Where I used to make maybe eight conscious decisions in two hours (“do I take this library, do I refactor this method, do I write this test”), it now feels like forty. In the same amount of time, the agents produce a multiple of the material that needs deciding. Typing was never the exhausting part. Judging is.

For testers this is doubly interesting. Anyone who in the classic setup already held the role of “reviewer of code someone else wrote” knows this fatigue already. In the agentic world it is not reinvented but generalized: suddenly everyone working with agents is constantly in the reviewer position. What used to be a time-boxed task in classic code review becomes a permanent state.

The everyday effect sounds harmless. You start clicking “OK” faster. You skim diffs you should really be reading line by line. You accept architecture proposals where yesterday you would still have asked “why, actually”. Nobody says it out loud. But almost everyone who works honestly with the setup knows that moment in the late afternoon.

The second cost factor is context switching. The cost of context switches has been folklore in software engineering practice for decades and is well documented in CHI research. A field study of knowledge workers finds an average of roughly 25 minutes until an interrupted task is resumed, typically after more than two other tasks in between [6]. A follow-up study shows that interrupted tasks do get finished measurably faster, but at a measurable price of more stress, frustration, and effort [7]. For programming work specifically, the picture is even clearer. Parnin & Rugaber in 2011 empirically examine how developers find their way back into the code after an interruption, and find that they do not simply pick up where they left off; they visibly invest time in recovery strategies such as code notes, deliberately left compile errors as bookmarks, or rereading the last commit, because the mental stack is deeper than in generic knowledge work [8].

In agentic supervision, the context switch does not sit between the hours but inside the block of work. You jump from the refactor review to the E2E diagnosis to the architecture decision to the logging detail. Four different contexts, four different mental models, all in thirty minutes. Every jump costs setup time. And because the agents work in parallel and do not wait, the temptation is strong to take each one as it comes in.

What helps is classic engineering discipline in new clothes: class-batched reviews. All refactor reviews in one block. All architecture decisions in a second. Test diagnoses in a third. This sounds obvious and is not; the agents behave like an open-plan office where someone is constantly standing at your desk.

The trick is not to run more agents at once. The trick is that only one kind of question reaches you at a time.

The third bottleneck is the most insidious, because it does not feel like fatigue but like routine. Attention span under continuous review.

Cognitive psychology knows the phenomenon as the vigilance decrement, documented since Mackworth’s classic study of radar monitoring in the Second World War [9]: someone who has to attentively monitor something over a long time, where an error appears only rarely, loses the ability to detect it. In the lab, Mackworth found a 10 to 15 percent drop in detection rate within the first thirty minutes, with further deterioration afterward. A much-cited review from human factors carries the pattern over to modern automation: when a human monitors an automated pipeline while also having their own tasks, complacency rises, and simple practice does not help against it [10]. More recent research specifically on human oversight of AI suggestions shows the pattern in its present-day form. Vasconcelos and colleagues demonstrate empirically in 2023 that users tend to accept AI suggestions without checking them themselves as soon as they perceive the cognitive effort of verification as too high; even well-constructed explanations only partly reduce this over-reliance, because the human runs a simple cost-benefit calculation [11]. In agentic supervision this is exactly the situation: many suggestions, each individually plausible, real verification more expensive than acceptance.

In practice this means: after thirty minutes of continuous review work, the detection rate drops. You stop seeing bugs you would have caught immediately when fresh. And because the agents keep producing, this effect adds up fast.

From my own practice, a single observation, not a study finding: when I check agent output for longer than half an hour at a stretch, I find things on rereading after a break that I did not see on the first pass. This is the same mechanism that code review research has known since the beginnings of formal inspections; as early as 1976, Fagan recommends limiting an inspection session to at most two hours and reviewing no more than 150 lines per hour, because otherwise the defect detection rate drops significantly [12]. A modern empirical study of code review practice at Microsoft extends the picture: in today’s asynchronous practice, reviews revolve less around pure defect detection than expected; a large share of the documented reviewer comments aims at code understanding and knowledge transfer within the team [13]. That does not make the attention demand on the reviewer smaller, it shifts it. In the agentic world the same effect just becomes permanent instead of situational.

When the three bottlenecks come together, they form a pattern I have come to take seriously. Three levers that work in my daily practice:

First, a decision-budget logic. A long-term study of 27 CEOs of large companies, tracked around the clock over 13 weeks, shows the pattern cleanly: top executives spend the largest part of their working time in meetings, where the main activities are prioritizing, sorting, and handing off; the real strategic decisions of their own are a clear minority [14]. In an agentic setup, by contrast, you first decide everything yourself. You have to correct that explicitly: which decisions are reversible and cheap (a code comment, a small refactor in an internal library) and pass without review? Which are reversible and expensive (a larger refactor, an architecture detail)? Which are not reversible (a schema change in production, an external interface)? The first category moves to auto-approve, the third stays strictly with the human.

Second, lead in groups instead of darting between individual agents. Three fixed slots a day are the clean ideal and in practice rarely feasible; in a warm agent fleet you have to hook in somewhere all the time. What does work, once you are no longer running just four agents in parallel but rather twelve or sixteen, is bundling them into thematic groups with their own focus. One group works on the backend, one on the tests, one on documentation and small bug fixes. You actively devote yourself to one group at a time, instead of jumping between the agents of different groups.

This works like a dog walker with several groups of dogs at once. He actively leads one group; the others stand around, look about, or run toward the goal where they are already playing anyway. When he switches, he switches at the group level, not between individual dogs of two parallel groups. That is exactly the difference between functioning parallel supervision and chronic darting about.

Third, a thirty-minute cap on continuous review work. With a break afterward that is not a screen again. Movement, coffee, staring at a wall. The vigilance research is clear enough that you do not need to optimize further.

Anyone who measures agentic development only along the axis of “faster and cheaper” is measuring the wrong thing. Speed has become a given, not a differentiator. What sets software apart today is no longer that it gets shipped, but that it is unique. That it does something that is not also sitting in every second repository. That the human who is responsible for it is genuinely still in the loop, with the three bottlenecks above under control.

For the testing community, I think, this means two things.

One: the role of the tester does not disappear in an agentic world. It becomes more central. What the agents produce has to be checked by someone who holds the context. That is exactly the skill good testers have always had. It is just now being called upon under new conditions.

The other: the three bottlenecks above apply especially to people in review roles. Whoever takes the setup seriously builds guardrails. Whoever does not runs the risk of scrapping the AI in half a year with the argument, “it was not for us”. The difference does not lie in the AI. It lies in the architecture around it.