The human in the loop is tired of reviewing

Pydantic's Laura Summers put a name to something a lot of developers are feeling: the human in the loop is tired. The automation arrived as promised — and the satisfying part of the work went with it. What's left is supervision: reviewing volumes of mostly-correct output that still need your eyes, your judgment, your taste. She's right that this is an engineering problem, not a personal failing. We'd add one thing: the tiredness has a location. It's downstream, in review. And you can move your effort upstream.

The tiredness has a shape

The exhaustion isn't “too much code.” It's a reward-function problem. The parts that paid you back — solving the problem, watching it compile, the feeling of control — got automated, and what replaced them is the cognitive load of review with none of the dopamine. One engineer in the piece describes waking up to thirty agent-generated PRs a night, each demanding a snap judgment. That's the trap: unbounded output, bounded attention, and every “one more prompt” pulling you back into a machine that never gets tired even as you do.

Reviewing output is the expensive place to be

Here's the thing about all that review: you're auditing guesses. Each PR is the agent's attempt at an intent you never actually wrote down — so you catch the misread after it's been built, one diff at a time, forever. The volume isn't the disease; it's the symptom. When the intent lives only in your head, the agent has to guess it every turn, and you have to check every guess. Reviewing faster doesn't fix that — you'd just be exhausted more efficiently. What fixes it is reviewing sooner: the decisions, not the diffs.

Top of the loop, or bottom of it

It really comes down to where in the loop you're standing. Re-prompting, patching, running the whole thing again to catch what the last pass got wrong — that's standing at the bottom of the loop. You're downstream of every decision, cleaning up after choices that were made without you, and the work only ever comes at you. Planning the shape of the thing before it runs — and staying in the conversation while it runs, resolving each question the moment it surfaces — is standing at the top, where the decisions actually get made. Same loop, same agent. But from the top, a little judgment redirects everything below it; at the bottom, you pay again and again for judgment that never happened. That's not a small optimization. It's the difference between steering the loop and being dragged around by it.

Re-prompting and re-fixing is standing at the bottom of the loop. Planning — before it runs, and while it runs — is standing at the top. Same loop, and a world of difference.

Move the judgment upstream

The cheaper place to spend a human is before the code, on the decisions — the handful of choices that determine what all those diffs were trying to be. Write the intent down, resolve the open questions once, and the agent builds against a target instead of guessing at one. You review the shape of the thing while it's still a paragraph, not thirty variations after it's a thousand lines. This is the same move behind engineering the loop rather than the prompt, and it's why a resolved plan raises first-pass correctness: fewer wrong guesses means less to catch downstream. Planning isn't only an up-front act, either — staying at the top of the loop means updating the plan as the build teaches you something, so you keep steering instead of dropping back down to cleanup.

One decision beats thirty reviews

Notice which skills the article says survive the shift, and even grow more valuable: taste, architectural judgment, holding a coherent vision. None of those live in diff-auditing. They live in deciding. That's exactly where inplan puts you. The agent drafts the plan and raises its open questions inline — datastore? edge cases? the ambiguous requirement? — and you answer only the ones that genuinely need a human. You keep the rewarding part, direction, and hand off the draining part, line-by-line supervision. The scarce resource is your attention; spend it on the choice that shapes a hundred diffs, not on the hundred diffs.

It quiets the “one more prompt”

The intensity trap Summers describes — the slot-machine pull of re-rolling a prompt hoping the next output is the one — runs on the loop having no defined end. A plan gives it one. It carries the resolved feature set and what “done” means, so the loop has an exit condition instead of an open-ended craving. You resolve the questions, the agent executes, and there's a real line where you can stop — not because you gave up, but because the thing is actually decided.

And there’s someone on the other side

The loneliest line in the article is about the isolation: everything goes into some AI black hole; there's no person on the other side actually learning. inplan is built as a conversation, not a black hole. It's turn-based — the agent proposes, you respond in comment threads, like two people on a shared doc — and on a team, the other side is other people: a PM, an architect, a teammate, each answering the questions in their domain on the same living plan. The loop still has humans in it, and they can see each other.

Still in the loop — just the part worth staying awake for

Summers ends where she should: the humans are still in the loop; we're just tired. The point of moving your judgment upstream isn't to leave the loop — it's to stand in the part of it where a human is still ahead. Direction, context, the call between two reasonable options: that's yours, and it's the part that gives something back. Let the agent run the fast, tiring inner loop against a plan you resolved once. You won't be doing less that matters. You'll just be doing less of what was wearing you out.