The Human-in-the-Loop Is Tired: Pydantic on AI Dev Burnout

Laura Summers, who works on Pydantic AI and Logfire, published an article that hit a nerve with the HN crowd: "The human-in-the-loop is tired." The piece argues that LLM-assisted programming is simultaneously productive and exhausting - and that the exhaustion is structural, not incidental.

The Core Argument#

Summers frames the problem as a "human reward function" breakdown. Traditional programming was hard, but it delivered small dopamine hits: solving a problem mentally, understanding gnarly logic, watching code compile, the feeling of control.

LLM-assisted programming automates the work that generated those rewards. What remains is "the cognitive load of review and supervision" - without the corresponding payoff.

Her most concrete example: "The honest truth is that in the last few months, there have been days when I have spent close to two full days writing a plan for an LLM to execute: obsessively clarifying, specifying, re-specifying, only to have it do inexplicable things like port hooks incorrectly or invent non-existent components."

Two days of spec writing. Then the model does something wrong anyway. That is the loop she is describing.

The Intensity Problem#

Summers cites a Berkeley Haas study showing AI increases work intensity rather than reducing it. More gets done, but at higher cognitive cost.

The addictive dynamic makes it worse: "I felt that one in my bones. I was up until nearly 2am recently, prompting, because I was so close to getting a plan right. Or so I thought."

One HN commenter, Terr_, nailed the comparison: "Right, it's more like pulling the lever on slot machine. Oooh, 677, bad luck, do a ritual and try again, and maybe this time..."

Regular programming also has a feedback loop, but normal errors happen consistently. You can reason about them. Slot machines and LLM prompting share a quality: variable reinforcement schedules that keep you pulling the lever.

The Isolation Effect#

A subtler point in the article: LLM-assisted work is lonely. It replaces natural collaboration moments - rubber-ducking with colleagues, asking for help, pair programming - with solitary human-machine iteration.

User xtracto on HN offered a counterpoint: "Maybe im part of some spectrum, but building stuff with AI in that 'solitary mode' ive found it really enjoyable. It takes me to the times 30 years ago when I was a 14 year old writing my own games on Basic and C++."

Fair enough. But teams that previously collaborated now have individuals silently iterating with their agents. The aggregate effect on team dynamics is an open question.

What HN Is Saying#

The HN discussion (249 points, 130+ comments) generated substantial engagement, though it also drew meta-commentary about the article's writing style.

User N_Lens opened with: "While I appreciate and agree with the key points of the post, Claude's writing style fingerprints are all over it and I guess it's even more exhausting to read someone's AI written article."

User luciana1u noted the irony: "the irony of an article about human fatigue being detected as AI-written by half the comments is doing more for the argument than the article itself."

Beyond the style debate, several commenters shared substantive reactions.

User zem offered a counterpoint workflow: "my anecdotal advice is to avoid the entire 'agent' temptation, and treat the LLM as a code generator. have a single session running at a time. come up with a plan, iterate on it until you are satisfied, then tell it to execute the plan, and watch it."

User misja111 reported the opposite experience: "I feel the opposite, AI is making me less tired at the end of a working day even though I get much more done. What used to tire me: being forced to have a sharp eye for syntax errors when programming, or simply the effort of all the typing and navigating through source files."

User magnio identified with the PR review problem: "It's so funny and somber to see programmers having an existential crisis when they get a glimpse of what work is like for business managers, the demographics many programmers detest."

That observation deserves emphasis. The article describes a developer waking up to thirty AI-generated PRs every morning and needing snap judgment calls on each one. That is a management burden, not an engineering one.

The Solutions Summers Proposes#

The article is not purely diagnostic. Summers offers three practical responses:

Pre-mortems: Running fresh LLM sessions to assume your plan has failed catastrophically. The idea is to catch specification gaps you miss when you are too close to the work.

Rule extraction: Encoding implicit team judgment into instruction documents (like AGENTS.md files) that seed LLM behavior. This converts years of accumulated wisdom into something agents can use.

Skillset evolution: Rather than abandonment, expertise becomes about "taste, nuance, mature architectural opinions" - distinguishing principles from bandwidth constraints.

The third point echoes something we have written about before: as AI handles more implementation, human value shifts upstream to specification and judgment.

The Bigger Question#

User verdverm asked the obvious follow-up: "Should we not get to work less if AI is increasing productivity so much while also making us exhausted more quickly? Perhaps on the way to UBI and the end of labor, we could get a 32 and 24h work week with lots more vacation."

This is the gap between productivity gains and quality-of-life gains. AI tools make individuals more productive. But the productivity mostly accrues to organizations, not the individuals doing the work. And if the work becomes more intense, even a more productive worker ends up burned out.

User watwut made a historically-grounded observation: "We got 40 hours workweek rather than 80 hours workweek because of political movements and fights, not because of technology. Labor saving device, on itself, leads to two outcomes: you work as much as before, but produce more (cue all the burned out overworked ai coders) or you get unemployed desperately looking for new work."

Whether AI tooling leads to better working conditions is not a technology question. It is a negotiation question.

What This Means for Your Workflow#

If Summers' description resonates with you, some tactical adjustments:

Track your supervision time. If you are spending two days writing plans for ten minutes of LLM execution, the ratio is inverted. Either your plans are over-specified or the model cannot follow them.

Preserve non-LLM coding time. Some tasks are faster and more satisfying done manually. Do not route everything through the agent just because you can.

Notice the isolation. If you have not talked to a teammate about code in weeks, the LLM is not a substitute for that collaboration. It is a replacement that costs you something.

Set stopping points. The slot-machine dynamic is real. "One more prompt" at 2am is not productive. It is compulsion.

The article is worth reading in full, AI-style-fingerprints and all. Pydantic builds developer tooling, so their perspective on developer experience carries weight.

Sources#

• The human-in-the-loop is tired (Pydantic)
• HN discussion thread
• Berkeley Haas study on AI and work intensity