Let's talk about LLMs (Bennett)

James Bennett's April 2026 post on b-list.org is a 6,000-word application of Fred Brooks' No Silver Bullet to the LLM coding hype cycle. Bennett — a longtime Django core contributor — is skeptical but not nihilistic. The argument is narrower and sharper than most anti-LLM pieces in the wiki: LLMs can't produce an order-of-magnitude productivity gain in software development because the bottleneck isn't code generation speed, and Brooks' 1986 math proves it.

The theoretical argument

Bennett's core move is to take Brooks' essential/accidental distinction seriously as a quantitative constraint rather than a rhetorical flourish. Brooks' claim was that no single development could produce a 10x productivity gain within a decade. The reasoning: software difficulty splits into essential (the conceptual construct — specification, design, testing of the abstract entity) and accidental (the representation labor — syntax, memory management, build systems). If accidental difficulty is less than 90% of total, even reducing it to zero can't yield 10x.

Bennett thinks this ceiling is much lower than Brooks stated it. In mature domains — his own career is mostly database-backed web apps — he suspects accidental difficulty is already well under 50%. Rails' scaffolding could generate CRUD apps from a schema twenty years ago; modern frameworks reduced accidental difficulty further; LLMs are working on the tail.

He reinforces this with Brooks' other famous estimate, from Mythical Man-Month chapter 2: only about 1/6 (17%) of software task time is spent on coding itself. Even if LLMs reduce coding to zero, the theoretical ceiling is still well under 2x. The Tailscale CEO quote Bennett pulls out makes the same point more bluntly: if Claude writes code in 3 minutes instead of 30, you still face the same 5-hour code review queue afterward.

Bennett also notes that Brooks himself anticipated "automatic programming" as a candidate silver bullet, quoting Parnas that "automatic programming always has been a euphemism for programming with a higher-level language than was presently available." Generating code from natural-language specs is precisely the task LLMs are promoted for. Brooks argued higher-level languages were past the point of producing revolutionary gains; Bennett extends the same argument to LLMs.

The empirical argument

Bennett then turns to recent data, deliberately using reports that LLM advocates recommend to him:

DORA 2025 ("State of AI-assisted Software Development") headlines look positive but unravel on inspection. DORA claims increased throughput but also increased delivery instability — a combination of change fail rate ("deployments that require immediate intervention") and rework rate ("unplanned deployments after production incidents"). DORA found no moderating effect — instability still damages product performance and burnout. The chart on page 38 appears to show instability gains exceeding throughput gains.

DORA also claims "productivity" and "code quality" improvements, but those are self-reported by survey respondents. Bennett cites the METR early-2025 study as the killer counterexample: developers expected LLMs to speed them up by 24%, were actually slowed down in measured tasks, and — after directly experiencing the slowdown — still perceived a 20% speedup. Self-reported productivity is worthless; the gap between perception and measured reality is consistent and large.

CircleCI 2026 ("State of Software Delivery") is more blunt. Main-branch merge success rates dropped to 70.8%, the lowest in 5+ years, against a recommended benchmark of 90%. Year-over-year, recovery time on a broken main branch is up 13%; on broken feature branches, up 25%. CircleCI does the math: for a team pushing 5 changes/day, moving from 90% to 70% means going from one showstopping breakage every two days to 1.5 per day — about 250 additional debug/blocked-deployment hours per year at 60-minute recovery, or 12 full-time engineers at 500 changes/day.

Both reports' "capabilities models" for extracting value from LLMs — strong version control, small batches, internal platforms, user focus — are table stakes any successful team should already have. Bennett's surgical-team analogy: if the new technique works best on teams that also wash their hands before operating, that's not really a finding about the new technique. Much of the DORA advice traces back to the Joel Test, the Agile Manifesto, and software engineering literature going back to the 1970s.

The case study

The most concrete recent data point is Cloudflare's LLM-driven rebuild of Next.js. This is a best-case setup: a competent team, a well-documented and heavily-tested target framework, adversarial multi-agent workflow (one agent writes, another reviews, another addresses review comments). Result: the initial public release couldn't run a default Next.js application and shipped with security issues. Cloudflare's own disclosure post contained the line Bennett pulls out as the post's most quotable summary:

AI is now very good at getting a system to the point where it looks complete.

The specific failure mode is illustrative: the LLM was "feature-first" — decide which feature to port, then bring over the Next.js tests for that feature. That approach gives you happy-path coverage but misses regression tests for edge cases that don't map cleanly to any one feature. Next.js has a dedicated test directory for "what happens when middleware files lack required exports"; that test never got ported because middleware was "already covered" by other tests. The fail-safe behavior was silently lost. This is a concrete example of the read-the-code-yourself warning: LLM output that looks complete can be missing the invariants that made the original safe.

Bennett mentions in passing that the recent leaked Claude Code source has drawn similar commentary — a team that should be best-positioned to extract revolutionary gains from LLMs isn't managing to.

The "left behind" rebuttal

Bennett treats "adopt now or be left behind" as the weakest pro-LLM argument. His decomposition:

• If the skeptical position wins, late adoption has zero cost. You pick up whatever incremental tool LLMs become (like TDD, or pair programming, or IDE boilerplate) when it becomes useful, or never.
• If the skeptical position loses, the silver bullet must attack essential difficulty by definition — because the math rules out attacking accidental difficulty alone. Any silver bullet that attacks essential difficulty would render today's LLM-prompting skillset obsolete, since today's skillset is precisely "how to specify and design software in a form an LLM can consume." So current experience isn't protective.

Bennett also flags the rhetorical move: "it's going to happen whether you like it or not" and "it's undeniable that…" try to shift the burden of proof from the claimant to the skeptic. The burden belongs on the side making the revolutionary claim.

The democratization rebuttal

The "LLMs will let non-programmers write software" claim runs into an internal contradiction. LLM advocates simultaneously argue that (a) successful LLM coding requires significant skill — prompt engineering, context management, multi-agent orchestration, knowing when to trust output — and (b) it will democratize software development for people without programming experience. These can't both be true. If LLM coding is a skilled practice, it's not democratizing; if it's democratizing, the skills gap argument disappears.

Bennett also brings in Dijkstra on "the foolishness of 'natural language programming'" — natural language is ambiguous in ways that make it structurally unsuited to specifying programs, so some form of formal specification language will always be required. And the 3D printing analogy: hyped as a universal democratizer, ended up a niche hobby.

The scariest failure mode: non-programmer LLM users producing software that seems to work, deployed in fields with privacy/confidentiality requirements (healthcare, legal, finance), where the failure surfaces months later as a data breach or a silently wrong financial model.

The prescription

Work on fundamentals. Version control, comprehensive test suites, continuous integration, meaningful documentation, fast feedback cycles, iterative development, focus on users, small batches. These are the practices the DORA and CircleCI reports keep circling back to. They've been known for decades but remain rare in practice. Teams without them can't absorb any increase in code output, LLM or otherwise.

If LLMs turn out to be transformative, teams with strong fundamentals are best-positioned to benefit. If they don't, those teams are still better off. It's the strictly dominant strategy.

Related pages

This post ties together most of the LLM-skeptic thread in the wiki:

• cult-of-vibe-coding — Bram Cohen's parallel case: refusing to read AI-generated code is dogfooding gone cult
• building-syntaqlite-ai — 8 years, 3 months with AI, vibe coding failure, disciplined rewrite — the experiential version of Bennett's argument
• log-distributed-llms — multi-agent coding as a distributed consensus problem; Bennett's Cloudflare example is what FLP/Byzantine limits look like in practice
• llm-enshittification — the Gentoo developer's broader anti-LLM case (data theft, labor, copywashing)
• ai-great-leap-forward — corporate AI mandates as ritualized production
• subprime-ai-crisis — the economics side: if productivity gains are mixed, the financial model collapses
• ai-bubble-pale-horses — checklist of bubble-deflation signs; Bennett's empirical data is consistent with several of them
• no-silver-bullet — the Brooks concept Bennett is invoking
• peril-of-laziness-lost — Cantrill's philosophical complement: human laziness (the drive to simplify) is the mechanism that attacks essential difficulty, and LLMs lack it
• if-ai-writes-your-code-why-use-python — Mitchem's opposing case: the artifacts (TS-in-Go, Carlini's Rust C compiler, Kling porting Ladybird's JS engine) are the kind of dense-accidental-complexity work Brooks would predict is most amenable to LLM gains; whether that generalizes is the question