Quoting Kenton Varda

Simon Willison's blog quoted Kenton Varda, the tech lead for Cloudflare Workers, who declared a moratorium on AI-written PR descriptions, commit messages, and tickets within his team. The reason? These AI-generated texts were “worse than useless.” It sounds counterintuitive—at a time when AI-assisted programming tools are everywhere, why would a senior engineering manager put the brakes on AI?

Kenton’s critique is remarkably precise: AI-generated change descriptions go to great lengths to describe code details—what lines were changed, what function names were used, how logical branches unfold—information that reviewers can easily see by glancing at the diff. What he truly misses is the “high-level framing”: why was this change made? What design rationale does it follow? How does it fit into the larger system architecture? In other words, AI floods reviewers with low-hanging surface details while stripping away the abstract context that requires human judgment.

This reveals a deep flaw: current AI remains a “statistical model of code” rather than an “engineering-understanding agent.” Its training data consists overwhelmingly of code itself and brief code comments. High-quality PR descriptions, design documents, and architectural decision records (ADRs)—texts rich in business logic and trade-off reasoning—are vastly underrepresented on the internet. Consequently, when generating text, AI tends to reproduce the pattern it sees most: a detailed, implementation-oriented explanation, rather than the high-level synthesis it has rarely encountered.

Consider an analogy: you hire a new employee who has not participated in any project background, product logic, or architecture discussions. They only study the codebase in isolation, then write a weekly report: “I changed line 52 in user.js from if (age > 18) to if (age >= 18), and refactored two functions in order.js.” Technically true, but for the team it’s information garbage. What you really need is: “To fix the boundary case in minor age verification, I aligned the age-checking logic and decoupled the order flow, paving the way for future promotional rule extensions.”

Kenton’s moratorium signals that AI-assisted programming is moving from a “hype trial phase” to a “rational tooling phase.” We are no longer just amazed that “AI can write code”; we are now scrutinizing whether the code and text it produces truly boost team productivity or create new cognitive load. An often-overlooked truth is that the hardest part of software development is not typing code—it’s communication. Code is meant for humans to read, change descriptions are written for human reviewers, and architecture designs must eventually become shared understanding. When AI intervenes in these collaborative human steps without grasping intent or aligning perception, the automated content it generates can actually reduce information density and increase communication overhead.

So what should developers take away from this? First, learn to assign AI the right tasks: repetitive, templated, detail-oriented work with little contextual demand—like generating unit test stubs, writing function-level comments, or extracting repeated code—let AI handle those. But work that requires abstract thinking, a big-picture view, and human alignment—like writing PR descriptions, designing system architecture, or creating decision records—is better led by humans, with AI at most serving as an assistant that offers rough drafts. Second, cultivate a “sense of rhythm” for AI usage within your team: just because you can use AI doesn’t mean you should. Sometimes turning it off and thinking through a problem on your own is actually faster.

Finally, let’s revisit the phrase “worse than useless.” It’s not that AI did anything factually wrong; it’s that it created an illusion of informativeness. When a reviewer sees a lengthy PR description, they subconsciously assume all critical information is present, and their guard drops. The truly important design intent—omitted entirely—might be the biggest risk AI brings to the engineering workflow. On the road to intelligent software development, perhaps the first lesson is to be wary of automation that appears smart yet offers no real insight.