LLM coding feels faster — and more exhausting

Programming with LLMs is now useful enough to matter — and unsettling enough to wear people down. In a new essay, Pydantic argues that developers are being pushed into a strange new role: less hands-on builder, more exhausted supervisor of machines that can generate plenty of plausible code but still miss the point.

Author Laura Summers says that tension is easy to miss if the industry focuses only on productivity gains. At Pydantic, which builds tools for data validation, AI agents, and production observability, the team is also feeling the strain.

She recalls a colleague, Douwe, describing how he wakes up to thirty pull requests every morning, each submitted overnight by someone’s AI workflow, and has to make rapid judgment calls on all of them. The obvious temptation is to let AI review the AI-generated code too. But as Douwe put it:

“at that point, what am I still doing here?”

Summers says the fatigue is not just about volume. It is the mental cost of keeping the intended design in your head while a model produces “mostly-correct” output that still needs close review. She describes spending close to two full days writing and refining a plan for an LLM, only to watch it pull from the wrong plan or invent components that did not exist.

Recommended reading

Google Pics lands in Workspace on August 18

That, she argues, creates a new kind of burnout: the fatigue of supervision. The satisfying parts of programming — solving the problem, understanding the logic, feeling in control — are partly automated away, while the draining parts expand.

She links that to a broader increase in work intensity, citing a Berkeley Haas study highlighted by Simon Willison. The pattern is familiar: one more prompt, one more tweak, one more feature before logging off. Summers says she recently stayed up until nearly 2am because she felt she was close to getting a plan right.

The essay also points to a social cost. Working with LLMs can turn programming into an unusually solitary loop, replacing conversations with coworkers and small shared wins with another round of prompts. That can weaken collaboration, especially in teams that do not already have a strong communication culture.

Later, Summers compares today’s shift to the turmoil around responsive design around 2009, when designers and frontend developers had to give up fixed-width, pixel-perfect layouts for more fluid systems.

Her argument is not that software engineering is disappearing. It is that the work is being reshaped, quickly. In a world where more people can produce code that compiles, the differentiators become taste, architectural judgment, and the ability to tell when something merely looks right.

Pydantic’s team says some new practices are emerging from that shift. Summers describes running pre-mortems with a fresh LLM session to identify why a plan might fail. She also cites an engineer who built a tool to extract rules from thousands of past code review comments into an AGENTS.md file, turning years of implicit judgment into reusable guidance.

Her bottom line is blunt: the bottleneck was never just writing code. It was always human attention and engineering judgment. Those remain scarce — and, for now, tired.