The conversation about AI coding productivity keeps asking whether developers can go faster. The more interesting question is what happens once they do.
Simon Willison put it plainly in a recent post:
“The more time I spend working with coding agents, the more convinced I am that they make software engineering even harder.”That is not a dismissal of the tools. Willison uses them constantly and says so. His point is that getting real value from coding agents requires extraordinary discipline and knowledge. One reader pushed back, warning that without deep expertise it is difficult to tell correct output from plausible nonsense. Willison’s response: “You’re making the exact same point as me.”
Faster and harder at the same time
Geoffrey Huntley described his experience with coding agents as “incredibly taxing” even as an experienced operator. He reported roughly 16-hour days over the preceding 12 days, noting explicitly that this was his choice, not a job requirement. That qualifier matters. These are not productivity measurements. They are observations from people using the tools enthusiastically. The enthusiasm is part of the story: as more becomes possible, people attempt more.
Hillel, another reader in the thread, summarized it cleanly: “It doesn’t get easier, you just get faster.”

The UC Berkeley research
UC Berkeley researchers Aruna Ranganathan and Xingqi Maggie Ye studied AI use at a 200-person technology company over eight months. The work included observation and more than 40 interviews across functions.
What they found: employees expanded their responsibilities, fit prompting into former pauses, and kept more work running simultaneously. Much of it was voluntary. The problem was how that momentum reset expectations. As Ye explained, “what was once extra effort becomes standard performance.”
This was qualitative research at one company, not a universal proof. But it describes a recognizable pattern: a burst of experimentation becomes the ordinary workload against which everyone is measured.
What to do with the gains
Willison’s own example is worth noting. He and Alex Garcia ran a security audit of Datasette using several coding agents. For most issues, one person wrote tests demonstrating the problem while the other implemented the fix. Two humans examined each issue alongside agents using different models. The AI helped surface useful work. The humans supplied the process for completing it.
The article’s practical recommendations for engineering leaders:
- Ask where the time actually went: did a change reach customers sooner, or did review spill into evenings?
- Give engineers permission to spend some gains on reducing future complexity, not just shipping new features.
- Before turning a burst of output into a standing headcount assumption, confirm whether the team sustained it within a normal workday, including review and maintenance.
- If the bigger roadmap only works because engineers extended their hours, some of that productivity gain is coming from additional labor, with AI serving as taskmaster.
The core argument is that AI raises the stakes of not having engineering discipline, not that it lowers them. Companies budgeting as though AI has already delivered both a larger roadmap and a smaller need for senior engineers may be counting the same gain twice.

