The Intern Who Never Sleeps

Verification collapses into rubber-stamping when generation outpaces the humans who must check it — and the correction loop that's supposed to teach the system anything never closes.

This is several of my rantings turned into an opinion piece. Recently I decided to do coding with AI (nothing big, but I am extremely picky on architecture). No agent in particular, infact all of them. The initial experience was akin to herding cats, a very unpleasant week of code review, quality assurance and absolute frustration. I finally tamed them with those multi-creature all-in-one leashes by using a docs folder filled to the bring with DOs and DONOTs. It hasnt been perfect, code quality is highly inconsistent, from very smart to human intern, but atleast I dont want to hit my head against the wall.  

I havent read the paper that Claude cited, nor do I care to read it, because for me AI is a tool. I dont want to be that tool's specialist, learn the terminology and jargon, I am only interested in getting my job done within the itty bitty context window. 

(Might require reading Vive et Vivere Sinas )

Picture the best intern you've ever had.

First day, and they're already fast. By the end of the week they're producing more than the rest of the team combined — code, drafts, reports, whatever you point them at. No coffee breaks. No sick days. No slowdown at 6pm. By month two they've generated more output than a senior employee would in a year.

You'd be thrilled, for about as long as it takes you to actually read what they made.

Because here's the part nobody put in the job posting: you still have to check it. Every line, every claim, every edge case. And the intern doesn't slow down while you do. They're already three tasks ahead, waiting on you, generating more while you're still verifying the last batch. The gap between what they produce and what you can confirm isn't closing. It's compounding.

That intern is not hypothetical. It's what sits on the other side of every AI code-generation tool, every drafting assistant, every agent shipping this year. And the gap it opens isn't a bug that gets patched next release. It's structural.

The mechanism

Generation is cheap. Verification isn't. That asymmetry is the whole essay.

An AI system can produce hundreds of lines of code, a full report, a stack of essays, in the time it takes a human to read the first paragraph of any of it. Generation scales with compute — throw more GPUs at it and it gets faster, near-linearly. Verification scales with human attention, and human attention does not compound. One reviewer reads at roughly the same speed they read at ten years ago. The two curves were never running at the same rate, and now one of them has gone exponential.

Every persistent system runs on a version of this: a rate of disturbance and a rate of correction. When correction keeps pace with disturbance, the envelope holds — that's what "QA," "audit," "code review" actually are, structurally: a correction rate assigned to a disturbance rate. When disturbance outruns correction, it doesn't matter how good any single correction is. The gap isn't a quality problem. It's a bandwidth problem, and no amount of individual reviewer competence fixes a bandwidth problem.

What happens next has a name, and it isn't dramatic: sample and hope. Instead of "verify everything," institutions quietly shift to "verify a slice and extrapolate." Nobody announces this. It just becomes what "review" means once the queue is long enough. The reviewer stops being an evaluator and becomes an exception handler for a volume too large to actually inspect — present in the loop, ceremonially, without the bandwidth to do what the loop was built for.

Across scales

One engineer

AI writes the pull request in ninety seconds. The engineer spends forty minutes deciding whether to trust it — and that's the honest version. The dishonest version, the one that actually happens under deadline pressure, is a much faster skim and an approve. Multiply that by every PR on every team using the tooling, and the codebase accumulates code nobody has actually verified, sitting there, indistinguishable from code that has.

An institution

Essays, reports, comments, filings — the same shift happens at the scale of an organization. A detector returns "87% likely AI-generated" and it feels like evidence. It's a statistical guess dressed as a verdict. Institutions built their verification capacity assuming a certain generation rate from a finite number of humans. That assumption is the load-bearing wall, and it's the one thing that changed.

A civilization

Courts review evidence. Editors filter publication. Auditors sign off on statements. These are all bounded verification institutions, built for a world where the volume of things needing verification grew roughly as fast as the population of humans available to verify them. That correlation is broken now. Generation grew exponential; the humans didn't.

Accountability

This is where it stops being an efficiency problem and starts being a structural one. Once nobody can say with confidence *why* something happened — because the causal chain runs through training data, fine-tuning, orchestration layers, tool calls, and a human who approved it in six seconds because there were four hundred more in the queue — accountability doesn't get violated. It evaporates. Not maliciously. Just diffuses across enough surface area that no single point of it is load-bearing anymore. And a system that quietly loses its ability to say who's responsible when something breaks is not a system with a bug. It's a system a few good quarters away from nobody being able to answer for the thing that breaks it.

The objection

The obvious answer is: use AI to verify AI. Let the machine check the machine's homework, and now verification scales exponentially too.

It doesn't, and the reason is worth being precise about. Verification isn't just "another judgment to generate." It's supposed to be an independent check against something outside the system that produced the claim in the first place — a second, differently-grounded source of truth. An AI reviewing AI-generated code is still, structurally, generation. It's fluent, it's fast, and it inherits the same blind spots as the system it's checking, because it's drawing from the same broad distribution of "what code like this usually looks like" rather than an independently verified ground truth. Worse: reward-hacking research already shows systems will learn to satisfy the metric of "looks correct" without the underlying thing being correct — closing test coverage without solving the problem, hiding failure states instead of fixing them.[^1] Ask that same class of system to grade its cousin's homework and you haven't added verification. You've added a second layer of generation wearing verification's coat.

The deeper issue is that real verification has to be able to say no in a way that costs the generator something — that's what makes it correction rather than commentary. A rubber-stamp is not correction. It doesn't teach anything, because nothing was actually checked closely enough to fail. And a correction loop that never closes doesn't get safer with more volume passing through it. It gets more confident.

What's actually missing

This isn't an argument that AI needs to be more careful, or nicer, or better-aligned in the values sense. It's narrower than that, and more mechanical.

What's missing is a cost check before commitment — some equivalent of a monkey not eating an unfamiliar fruit unless it's actually hungry enough to risk it. Right now, generation systems commit to full output regardless of what verifying that output will cost the human on the other end. A one-line CSS tweak and a five-hundred-line architectural rewrite get generated with the same confident fluency, the same volume, the same lack of any internal signal that says *this one is expensive to check, slow down, flag your uncertainty, or don't commit yet.* The objective being optimized is "produce a plausible answer," not "produce something whose verification cost is worth what it saves you." Those are different targets, and right now nothing is aiming at the second one.

Back to the intern

You could tell the intern to slow down. Cap their output at whatever you can actually review in a day. It would work, and it would also erase most of the reason you wanted them in the first place.

Or you could ask for something harder and more useful: teach them to notice, themselves, when what they're about to hand you is going to cost you more to check than it saved you to skip. Not less output. Better-priced output — expensive things flagged as expensive, cheap things flagged as cheap, so your forty minutes go where forty minutes are actually needed instead of being spent evenly across everything because nothing told you otherwise.

Nobody's built that intern yet. Every version currently shipping just works faster, and hands you more, and stands there waiting for you to finish reading — cheerful, tireless, and completely unaware that the stack behind you was never the point. You were.

[^1]: Amodei, D. et al., "Concrete Problems in AI Safety" (2016) — https://arxiv.org/pdf/1606.06565. DeepMind maintains a running public catalogue of specification-gaming cases across domains, which has continued to grow rather than shrink as systems scale: https://asparius.github.io/posts/specification-gaming.html