The senior engineer approved nineteen pull requests today. She read four of them. The supervision channel is collapsing in real time. Part three of a three-part series on the personnel infrastructure that does not exist for AI agents. Part one named the missing category. Part two named the missing assessment. This one names the missing supervisor.

It is Thursday, 5:47 p.m. The senior engineer has nineteen pull requests left in the queue and a meeting at six.

The first PR opens. The diff is two hundred and forty lines, generated by Claude Code in eleven seconds. She reads the title, scans the file changes, checks that the tests are green, glances at the function names. Eight seconds. Approve. Next.

By PR fourteen she has stopped reading the diffs in full. She is looking at the test results, the CI status, and the descriptive PR title. If those three things are clean, the PR moves. The thing she would have done four years ago, which is to read the actual code and ask whether the implementation matches the intent, would take her forty minutes per PR if she did it properly. There are nineteen PRs left and she has thirteen minutes.

This is the supervisory channel. This is what it actually looks like in 2026, in the most engineering-rigorous sector that exists.

She is not negligent. She is doing what the cognitive math tells her to do. The agent produced this code in eleven seconds. Reviewing it with the depth she would give human-written code would take her forty minutes. The math says: this is faster.

By the time she gets home, she will have approved nineteen pull requests. Her probationary period for each agent that wrote them was less than a minute.

The channel collapses twice

The first collapse is happening now, through speed asymmetry. The human cannot validate at the speed of generation. So the human starts heuristic-validating, and heuristic-validation is not validation. The senior engineer in our scene is doing exactly the right thing for her current constraints, and the constraints are wrong. She has been given a workload that assumes she can review human-written code at human speed, and replaced human-written code with agent-generated code at agent speed, without anyone adjusting the workload.

This is the visible failure mode. It is easy to point at. The harder failure mode is the second one.

The second collapse is happening through skill atrophy, and it has an eighteen-month time horizon. Or sometimes much faster than that.

The empirical version of this prediction is already published. A multicenter study by Budzyń and colleagues, published in The Lancet Gastroenterology and Hepatology in 2025, tracked nineteen experienced endoscopists across four Polish centers during the first three months after AI-assisted colonoscopy was introduced. When the investigators measured the same physicians performing colonoscopy without AI, the adenoma detection rate fell from 28.4 percent to 22.4 percent. Six percentage points absolute. A 21 percent relative decline in the ability to find precancerous growths, independently, among physicians who had spent years developing exactly that skill, after three months of working with the tool. An editorial responding to that finding in BMJ Digital Health this week proposed three guardrail dimensions for AI integration in medicine: task complexity, system resilience, and clinical consequence. The medical field is naming the deskilling problem in its own vocabulary, with its own empirical evidence, on its own timeline. The structural mechanism is the same as the one this article is describing.

The engineering version is the prediction.

The senior engineer in 2026 can still validate AI-generated code, even at heuristic speed, because she grew up writing code by hand. She spent ten years building pattern recognition for what well-written code looks like before AI got to it. When she glances at a diff, the patterns she trained on are doing the actual work, and her conscious attention is just the verification layer. The intuition is dense; the attention is thin.

The senior engineer in 2028 is a different story. By then she will have spent two years doing primarily what she is doing this Thursday afternoon: reviewing AI-generated code instead of writing original code. Her review speed will be higher. Her review depth will be lower. Her pattern recognition will start to drift toward "what AI-generated code looks like" rather than "what good code looks like," and those two things are not the same. The training set for her intuition will have shifted, quietly, without her noticing, because the work she does every day shifted.

This is the validator atrophying. It is not a critique of her engineering capability. It is a structural prediction about what happens to any skill when you stop practicing the upstream version of it.

The senior engineer in 2030 reviews AI output produced by a model that was trained on the outputs of last year's senior engineers, who were reviewing the outputs of the year before's. The human ground-truth signal weakens at every cycle, and the human reviewers have less practice with the original-work skill that ground-truth validation depends on.

This is the recursive structure. Who validates the validator? The same human, now less qualified to do the validation than they were when the agent first showed up.

The codebase the senior engineer no longer recognizes

There is a layer underneath the validator-atrophy problem that is even less visible, and worth naming because it changes what the senior engineer is actually losing.

The agent does not, by default, write code in the dev manager's style. It writes in its own. Different naming conventions. Different comment density. Opus in particular over-comments. Different patterns for error handling. Different choices about when to break a function into smaller ones. The default Claude Code output and the default Codex output do not match each other, and neither of them matches what the human team was writing eighteen months ago.

This is configurable. You can give the agent a style guide. You can point it at the existing codebase and instruct it to match. You can write a CLAUDE.md or a set of cursor rules with the team's conventions, the code patterns to prefer, the patterns to avoid. The agent will follow them. The agent will follow them better, and more consistently, than most human juniors do.

Here is the part that has not been named correctly. Those configuration files are the new-hire onboarding process. That is what they are. The list of code conventions, the style guide, the architectural decisions encoded as "here is how we do it on this team," the explicit rules about what good looks like. Every well-run engineering team already has these documents. They used to live in a Confluence page that new hires read in their first week, and then they lived in the code review feedback the new hire got for their first three months, and gradually the new hire absorbed them and started writing code that looked like the team's code.

For the agent, none of that gradual absorption happens. The agent reads the rules each time, follows them within the limits of the prompt context, and starts again the next session. The onboarding has to be explicit, written down, and continuously enforced because there is no "first three months" during which the agent organically learns the team's style. The configuration file is the new-hire packet, and it is the entire onboarding.

If you have not written your team's CLAUDE.md, your codebase is being written by an employee you did not onboard. The style drift the senior engineer is starting to notice in her code reviews is the predictable result. She is not failing to recognize bad code. She is failing to recognize her own team's code, because the team's code has quietly shifted toward the agent's defaults during the months no one wrote down what good was supposed to look like.

This makes the validator atrophy worse. She is losing the validation skill, and the thing she is supposed to validate against is also drifting away from her. Both reference points are eroding at the same time.

Switch the model and you compound the problem. The team's CLAUDE.md was tuned for Sonnet 4.6's style defaults. The internal copilot rolls forward to Opus 4.7 in a quiet upgrade. Suddenly the configuration that used to produce code matching the team's style is producing something subtly different, because Opus has its own defaults that the configuration was not written to override. The senior engineer notices that the code "feels different" but cannot name what changed. The configuration is the onboarding, and the model upgrade is the personnel change Article 2 named, and the two compound in the codebase before anyone realizes the team's house style has been quietly handed over.

What HR figured out fifty years ago

Pause on the supervisory problem and look sideways for a moment.

Every enterprise has been solving a version of this problem since the 1970s. How does a manager supervise a direct report whose technical capability exceeds their own?

This is the standard situation for an engineering manager supervising senior engineers, a CMO supervising specialists in domains the CMO has never practiced, a hospital administrator supervising attending physicians, a finance director supervising quantitative analysts. The manager is not the smartest person in the room on the work itself. The manager is the accountable person in the room. The literature on how to make this work is enormous.

The answer is not "make the manager smarter than the report." That solution does not scale. The answer is structural.

You change what you supervise. You stop supervising the process and start supervising the outcome. You build trust thresholds that loosen the inspection rate as the report demonstrates reliability and tighten it when the report demonstrates drift. You construct peer review structures that catch what the manager cannot. You build a culture of declared confidence so the report says "I am sure" or "I am guessing" and the manager treats those differently. You sample, you do not exhaustively review.

If those phrases sound familiar, you are also describing AI supervision. You are describing what every engineering manager learns in their first year of managing engineers who are better engineers than they are. The vocabulary is different. The structure is identical.

The AI field is solving this problem in 2026 with words like "human in the loop" and "approval gates" and "evaluation rubrics." HR has been calling it management by objectives, delegation maturity matrices, and trust calibration since the 1970s. The fifty-year head start exists. We have just not connected the two conversations.

Where the HR analogy breaks

The analogy is useful. It is also incomplete in a specific way that matters.

When a human manager supervises a senior engineer, both parties operate on the same time scale. The engineer writes code at human speed. The manager reviews at human speed. The natural pacing of the work creates the conditions under which sampling, outcome-supervision, and trust calibration work. The manager can choose to review one in ten PRs deeply, and the system stays in equilibrium because the engineer is producing PRs at a rate the manager can sample.

The AI version breaks this equilibrium. The agent produces output at a rate the human cannot sample meaningfully even at the one-in-ten rate. If the agent generates a hundred PRs a day, one-in-ten sampling means the human is reviewing ten PRs a day, which sounds reasonable until you notice that the ninety unreviewed PRs are now in production. The trust threshold mechanism HR built was designed for a workforce that produces work at a rate compatible with the sampling rate. AI agents do not produce at that rate.

There is a second break, harder to name. In the human version, the manager is not the only safety net. There is also the engineer's own self-awareness, the team's peer review culture, the post-incident review process when something fails. The agent has none of these. It does not catch itself making mistakes the way a senior engineer does after years of doing the job. It does not push back against an unclear specification the way a peer reviewer does in a team retro. It does not learn from a specific incident in a way that updates its behavior the next day. The supervisory structure HR built assumed multiple overlapping correction mechanisms, and the agent strips most of them away, leaving only the manager's review.

So the AI version requires the same structural moves HR figured out, plus new ones the human management literature does not need to handle. Sampling at the right cadence given the production rate. Real-time drift detection that does not depend on human attention. Recovery workflows that the agent cannot subvert. Confidence signals the agent has to be designed to surface, because it will not produce them on its own.

This is the part of the problem that is genuinely new. Not the supervision-of-smarter-reports framing. That part is fifty years old. The new part is supervision-of-faster-and-more-prolific-reports, with most of the safety nets the older framing assumed quietly removed.

What we need to build

The supervisory structure for AI agents is going to look like the supervisory structure for human direct reports who outpace their manager, plus three new things specific to the speed-and-volume problem.

The first is rate-aware sampling. If the agent produces at ten times the human rate, the sampling cadence has to account for that. Not "review one in ten." Review the cases that statistically matter, the high-consequence outliers, the cases where confidence is borderline, the cases that look like prior failures. Sampling becomes a triage problem, and the triage logic has to be designed deliberately.

The second is continuous drift detection that does not depend on human attention. The senior engineer at 5:47 p.m. is not going to notice that the agent's code style has shifted slightly over six months. The system has to notice. Drift detection is the supervisory work the human cannot do in real time.

The third is the rotation of validators back through original work. If the validator atrophies because she stops writing code, the structural answer is to ensure she does not stop. She writes some code every week. She reviews some agent PRs every week. The mix is deliberate, because the validation skill depends on the writing skill, and the writing skill depends on practice.

None of this is technically hard. None of it is conceptually new. The infrastructure for human supervision-of-smarter-reports has been refined for fifty years. The additional pieces, sampling, drift detection, validator rotation, are well within the engineering capability of the teams shipping these agents.

The question is whether the institutional category exists to do the work.

The third missing thing

Across three articles I have argued for three missing things. None of them are technical. All of them are institutional.

Article one was about the missing category. AI agents fit none of the existing institutional buckets cleanly, and the bucket they actually belong to has not been built. We treat them as software integrations because that is the category we have, and the category is the wrong fit.

Article two was about the missing assessment. We have fifty years of personality and team-fit instruments for human hires. We have not pointed any of them at the agents. The defaults under ambiguity are non-local, baked in upstream by the model provider, and the customer organization cannot evaluate them because the evaluation surface is not available to them.

This article is about the missing supervisor. The senior engineer at 5:47 p.m. on a Thursday is doing the job of three roles at once: writer, reviewer, and accountable supervisor. The supervisor role is the one she is failing at, not because she is bad at it but because the role was designed for a different time scale. There is no third party in the room. There is no HR-equivalent mediating the friction. There is no rate-aware sampling, no continuous drift detection, no validator rotation. There is just her and the agent and the queue, and the queue is winning.

Until someone builds the supervisor role for AI agents the way HR built the supervisor role for human direct reports, the channel will keep collapsing. Once now, through speed. Again in eighteen months, through skill erosion. The third time, when nobody can answer the question this article opened with.

Who validates the validator?

Right now, nobody. That is the problem. The category exists. The category has not been built.

This concludes the three-part series. The pieces work as a sequence: name the category, name the assessment, name the supervisor. Take any one of them seriously inside an enterprise deploying agents today, and you will discover the other two waiting for you.