Why LLM‑Assisted Programming Is Making Developers Exhausted

The core problem: productivity gains are paired with supervision fatigue

Developers using large language models (LLMs) now write code faster, but the human‑in‑the‑loop is exhausted because most of the work shifts from writing code to constantly reviewing, correcting, and steering AI output. The article from Pydantic explains that this supervision overload is real, not hype, and that ignoring it will lead to burnout.

Hands‑on creation versus AI‑driven generation

When programming felt like touching the fabric of the universe, the reward came from solving a problem, seeing code compile, and exercising control.

LLMs have narrowed the gap between promise and reality, delivering usable code quickly. However, the experience now feels “unsettling” because the creative part is outsourced while the quality‑control part intensifies.

“At that point, what am I still doing here?” – Douwe, Pydantic AI maintainer, on waking to dozens of AI‑generated PRs each morning.

Developers report spending days crafting exhaustive prompts that still produce “inexplicably stupid” results, such as importing the wrong component or inventing non‑existent APIs. The fatigue stems from holding the intended design in mind while the model churns out mostly‑correct but imperfect code that still requires human judgment.

The intensity trap: more work, same mental bandwidth

Research highlighted by Simon Willison (Berkeley Haas study) shows AI intensifies work rather than reducing it. Developers stay up late polishing prompts, chasing a perfect plan, and opening multiple AI sessions in parallel. The number of started tasks explodes, but the number of finished tasks does not, because the brain cannot be parallelised.

The human reward‑function problem

Traditional coding provides frequent micro‑rewards: solving a bug, watching a test pass, feeling in control. LLM‑assisted coding removes many of these dopamine hits and replaces them with a heavy cognitive load of supervision. The satisfying part shrinks while the exhausting part grows, leaving developers more productive but less happy.

Parallel to the responsive‑design transition

The shift to LLM‑driven development mirrors the 2009 move from fixed‑width to responsive web design. Designers feared loss of control; eventually, the craft evolved rather than died. Similarly, core engineering skills—taste, architectural judgment, nuance—remain essential, but the pixel‑level control of hand‑written code becomes less relevant.

What survives: expertise, taste, and distilled judgment

In an era where anyone can generate syntactically correct UI, the differentiators are:

Architectural taste – knowing which patterns truly fit a problem.
Nuanced judgment – spotting subtle design trade‑offs that a model cannot.
Distilled expertise – encoding years of review comments into prompts or rule‑sets that guide the LLM.

One engineer built a tool that extracts rules from thousands of past code‑review comments to seed an AGENTS.md file, effectively turning implicit judgment into explicit instructions for the model.

Developers who thrive are those with strong, practice‑earned opinions, who can separate enduring principles from outdated habits, and who adapt workflows without abandoning standards.

Breakpoints: isolation and the “human on the hook”

LLM‑assisted work is often solitary. The back‑and‑forth with a model replaces spontaneous rubber‑ducking and peer collaboration, leading to feelings of loneliness. Some commenters note the process feels like a slot‑machine: intermittent rewards that can become addictive and amplify isolation.

“Programming with an LLM is an intensely solitary activity… you and the machine, going back and forth, refining and prompting and reviewing.” – article author

A related term emerging in discussions is "human on the hook", emphasizing that responsibility collapses onto the developer when the AI fails, while successes are invisible.

Strategies to mitigate fatigue

Several community suggestions address the supervision overload:

Single‑session focus – Keep one LLM instance active, iterate on a clear plan, and let it execute step‑by‑step, reviewing each output before moving on. (Comment by @zem)
Pre‑mortem prompting – Ask a fresh LLM to assume a plan has catastrophically failed and diagnose gaps, catching specification errors early.
Structured outputs – Instruct the model to return results in simple, machine‑readable formats (e.g., JSON, logs) to reduce the need for prose reconstruction. (Comment by @eugmai86)
Explicit reward engineering – Design prompts that embed micro‑rewards (e.g., “When you finish a component, summarize the key design decision”) to restore some of the dopamine feedback lost in pure code generation.

Outlook: the human bottleneck is now visible

The article concludes that the true scarcity in modern software development is human attention and judgment, not code writing. As LLMs automate the mechanical parts, the value of experienced engineers rises, and the industry must treat the broken reward loop as an engineering problem, not a personal failing.

“If you’re feeling overwhelmed, simultaneously more productive and less happy, know that you’re not alone. The team building the tools you’re probably using is feeling it too.” – article author

Developers should acknowledge the fatigue, share strategies, and push tool builders (like Pydantic AI and Logfire) to create better ergonomics for the human‑in‑the‑loop.

Key takeaways

LLMs increase output but shift the bottleneck to supervision, causing mental fatigue.
The reward structure of programming is broken: fewer micro‑wins, more cognitive load.
Core engineering expertise—taste, architecture, and distilled judgment—remains the differentiator.
Mitigation tactics include single‑session workflows, pre‑mortems, structured outputs, and engineered micro‑rewards.
Recognizing and addressing the human‑reward‑function problem is essential to prevent burnout as AI‑augmented development becomes the norm.