Developer argues four years of LLM adoption has not improved software quality, cost, or security

The event is a single blog post by Joshua Barretto, dated 14 Aug 2026, tagged "ai", carried by one feed (Lobsters). It is a structured personal essay laying out six reasons for remaining skeptical of LLMs in software work rather than a product announcement, study, or policy document. The concrete change is therefore the publication of a fully argued dissenting position at a moment when the industry has spent several years and significant capital on LLM tooling. Read in isolation the post has no corroborating outlets, so it functions as a perspective piece rather than a news event in the usual sense.

The empirical core of the argument is specific. The author anchors his case in a stated time horizon ("4 years") and a stated spend ("$1.5 trillion"), and observes that software has not become cheaper, faster, more capable, or more secure. He rejects the metrics most LLM studies actually use - lines written, PRs merged, features added - as proxies with no causal link to top-level productivity. For a working engineer, the question this raises of their own organisation is which proxy metric is being used to justify the LLM rollout, and whether anyone has checked the rollout against cycle time, defect rate, or on-call load rather than activity counts.

The most testable part of the post is the hands-on evidence. The author reports receiving LLM-generated pull requests across multiple open-source projects that sit in the dependency trees of FAANG companies, and his claim is concrete: the mergeable proportion of those PRs is still well below human-written ones, and frontier models have missed issues that a human reviewer found soon after. An engineer auditing their own repository can reproduce that comparison by tracking merge rate, rework rate, and post-merge defect rate for human versus LLM-assisted PRs over a quarter, rather than relying on vendor or analyst summaries.

The author extends the empirical case into a structural argument: LLMs are a vehicle for making software work fungible and weakening worker bargaining power, and the right response for an individual engineer is to refuse the commoditisation and specialise instead. This is the least testable portion of the essay from the material provided, since it is a thesis about industry direction rather than a measurement. It is also the part most likely to be contested, and a reader who disagrees with the labour framing can still extract value from the empirical section, and vice versa.

What the available material does and does not support is worth being explicit about. The post is a personal blog carried by a single feed, so there is no cross-outlet corroboration, no benchmark, and no vendor statement in the package. The empirical claims rest on the author's first-hand observations of his own projects, which by definition are not representative of the industry. What the post does provide, and what a working engineer can take from it, is a structured set of failure modes - bad PRs, missed issues, mismeasured productivity - that are concrete enough to investigate in their own environment before treating the LLM productivity case as settled.