LLM coding is faster — and wearing developers down

Pydantic says many developers are living through a contradiction: LLM-assisted programming is genuinely useful, and genuinely destabilizing at the same time. In a post by Laura Summers, the company behind tools for data validation, AI agents, and production observability argues that ignoring that tension risks burning people out.

Summers frames the shift as bigger than the old promises of low-code and no-code tools. Those systems hinted that software creation might become easier, but often produced messy output under the hood. This time, she argues, the gap between promise and reality has narrowed enough to make the change feel real — and unsettling.

At the center of the piece is a problem Pydantic says many teams now recognize: the work has moved from writing code to supervising machines that write plausible code at high volume. Summers describes spending nearly two full days refining instructions for an LLM, only to watch it veer off course by reading the wrong plan or inventing components that did not exist. The issue, she writes, is often not raw capability but coherence.

Her colleague Douwe, who maintains the Pydantic AI framework, described waking up to thirty PRs every morning, many opened overnight by someone else’s AI workflow, and having to make quick calls on all of them.

Recommended reading

FBI eyes Nvidia and Google TPU AI systems

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

Why LLM supervision feels worse than coding

Summers argues that LLM tools have automated many of the small rewards that made programming satisfying: solving a logic problem, watching code compile, and feeling direct control over the result. In their place is what she calls “the fatigue of supervision” — holding the intent in your head while reviewing large amounts of mostly-correct output.

She links that feeling to a Berkeley Haas study highlighted by Simon Willison, which found that AI tools can increase the intensity of work. The dynamic is familiar: one more prompt, one more feature, one more attempt to get the plan exactly right. Summers says she recently stayed up until nearly 2am doing exactly that.

The result is not just exhaustion but isolation. Programming with an LLM, she writes, can replace moments of collaboration with a private loop of prompting, reviewing, and retrying. That can weaken team communication just when reassurance from other people matters most.

What still matters in software engineering

Summers compares the moment to the shift to responsive design around 2009, when designers had to give up fixed-width, pixel-perfect layouts and adapt to systems that flowed across devices. The parallel is not exact — she notes that the current transition is unfolding in months, not years — but she sees a similar pattern: craft is changing, not disappearing.

What survives, she argues, is expertise that goes beyond producing code that looks right. The differentiators become taste, nuance, architectural judgment, and the ability to make contrarian calls based on experience. Teams are also developing new practices around LLM use, including pre-mortems that ask a fresh model session to assume a plan has already failed and explain why. Summers also cites an internal tool built by one engineer that pulled rules from thousands of past code review comments into an AGENTS.md file so an LLM could follow years of accumulated judgment.

Pydantic’s conclusion is not that software engineering is ending. It is that the bottleneck was never code production itself, but human attention and engineering judgment. Those are now more visibly scarce — and more valuable. As Summers puts it, the humans are still in the loop. They are just tired.