--- title: There Is Still No Silver Bullet | daily.dev description: An essay revisits Fred Brooks' 1986 'No Silver Bullet' essay, arguing its core claim still holds forty years later: no single tool can deliver a tenfold... canonical: https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: There Is Still No Silver Bullet | daily.dev og:description: An essay revisits Fred Brooks' 1986 'No Silver Bullet' essay, arguing its core claim still holds forty years later: no single tool can deliver a tenfold... og:url: https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o og:image: https://api.daily.dev/og/posts/1TzMxbQ3O.png og:image:alt: There Is Still No Silver Bullet og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # There Is Still No Silver Bullet **[Lobsters](https://daily.dev/sources/lobsters)** · 12 min read · 0 upvotes · 0 comments ## Summary An essay revisits Fred Brooks' 1986 'No Silver Bullet' essay, arguing its core claim still holds forty years later: no single tool can deliver a tenfold productivity gain because tools only compress the 'accident' (representation, syntax, boilerplate) while the 'essence' (deciding what to build) remains untouched. The piece applies this to LLM coding assistants, arguing they're powerful accident-compressors but explain why senior engineers report only modest gains — their work is mostly essence. It cites a 2025 METR randomized controlled trial where experienced developers using AI were measured 19% slower despite feeling 20% faster, and critiques the phrase 'code was never the hard part' as misreading where essence work actually happens (often at the keyboard). It closes with practical habits: track how much of your week is essence vs accident, point AI deliberately at the accident, and grow designers rather than prompters. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Did AI assistance actually make experienced developers faster in the METR randomized controlled trial? No, it made them 19% slower. Sixteen experienced open-source developers working in their own mature codebases were randomly assigned tasks with and without AI assistance in 2025; despite measuring 19% slower, the developers themselves estimated afterward that AI had sped them up by about 20%, a roughly 40 percentage point gap between felt and measured speed. _Developers weighing AI coding tool claims against real measured impact can track findings like this on daily.dev._ ### What is Fred Brooks' essence versus accident distinction in software engineering? Essence is the conceptual construct of software: the interlocking concepts, data relationships, and decisions about what a system should do, which Brooks argued is the genuinely hard part. Accident is the labor of representing that construct: syntax, build tooling, and boilerplate. Because tools can only compress the accident, no tool can deliver a 10x productivity gain unless accident makes up nine tenths of the job. _Engineers deciding where AI tools genuinely help versus just feel faster can follow this debate on daily.dev._ ### Why did the METR follow-up study in 2026 find a different result than the 2025 study on AI coding productivity? The February 2026 METR follow-up flipped the sign to a statistically inconclusive speedup, but the study itself explained that wider AI adoption made the effect nearly impossible to measure cleanly: developers refused to join studies barring AI use, and 30 to 50 percent admitted holding back tasks they expected AI to handle well, skewing results toward AI looking better even before accounting for the modest size of the reported gains. _Teams sorting hype from evidence on AI coding productivity studies can follow the ongoing data on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 14 comments across lobsters, hackernews (as of 2026-09-14). **TL;DR:** Discussion centers less on the essay's thesis directly and more on a tangent about non-programmers using AI to build one-off tools, with people debating whether this reveals a failure of software design/end-user programming or an economic-incentive problem; one HN reply pushes back on the essence/accident framing itself. **Sentiment:** 15% positive · 55% mixed · 30% skeptical **The case for** - AI lets non-programmers build custom tools for their own specific workflows in hours instead of waiting on engineering time. - LLM-driven coding works reasonably well for problems that are bounded and well-described, similar to writing. **The pushback** - The ease of vibe-coding niche tools mainly exposes how badly siloed and non-interoperable mainstream software has been for decades. - Past attempts at end-user programming (HyperCard, AppleScript) were abandoned for economic reasons, not technical ones, and there's skepticism that a trillion-dollar AI investment will do better. - Even 'easier' bounded problems like coding still have plenty of unknown unknowns, so the essence/accident split may be oversimplified. - Engineering time is expensive, so many easily-automatable workflows never get addressed even when known about. **By community** - lobsters (mixed): Commenters largely sidestep the essay's core argument to debate why non-programmers now vibe-code personal tools, split between blaming software silos/economics and noting dev time is too costly for niche automations. - hackernews (mixed): Very light engagement, with one reply questioning the essay and another offering a nuanced pushback on the essence/accident distinction as applied to LLM coding. **Hottest debate:** Whether non-programmers successfully vibe-coding their own tools proves the essay's thesis or instead reveals a deeper failure to build interoperable, user-centered software. **Open questions** - Would properly implemented end-user programming tools have made today's AI-assisted vibe-coding trend unnecessary? - Is it economically rational to invest engineering time in the many small workflow automations that individuals currently do by hand? **Highlights** > One thing it probably means is that we've done a terrible job identifying opportunities where someone's workflow could be trivially improved with software, so they had to do it themselves. > — [bmo on lobsters · 11 points, 3 comments](https://lobste.rs/s/pf0hfr/there_is_still_no_silver_bullet#c_fp2h1z) > In today's computing world, "applications" -- whether they be online or on the computer -- are unfortunately siloed. It's been this way for a long time now. There was a lot more promise in the late 80s and 90s, where end user programming as a technique was taken quite seriously (I'm thinking of things like HyperCard, or how the desktop publishing industry made extensive use of AppleScript workflows). This type of thing was abandoned because mainstream computing came to think it was not important. It was, it should be noted, also not that profitable. It's harder to sell little pieces of software if people can just stitch up a solution quickly. > — [darth-cheney on lobsters · 2 points, 1 comments](https://lobste.rs/s/pf0hfr/there_is_still_no_silver_bullet#c_0zk1or) > You acknowledge that interoperability and a user-centered design were dropped not because of technical reasons alone but because of the economic incentives to build silos. I am not convinced things will change for the better when the purported solution is predicated on a trillion and a half dollars in investment looking for a return. > — [ggpsv on lobsters · 3 points, 1 comments](https://lobste.rs/s/pf0hfr/there_is_still_no_silver_bullet#c_ezyah0) > Just thinking out loud but the difference between the essence & accident is unknown unknowns. The whole point of the essence is to reduce the unknown unknowns to a manageable number that can be somewhat controlled and to highlight and prioritize the known unknowns. I get why people are saying “coding was never the hard part” but I think they mean once you know what to build and why there are fewer places to completely screw up so it’s “easy”. I don’t agree though - there are plenty of places to screw up coding and unknown unknowns exist there too! A better way to frame all of this is that LLMs work for things like coding bc they are somewhat bounded (like writing) once you have a good description of the problem. These types of problems aren’t “easy” but they are “easier” to solve bc they have a shape with edges that can be defined. Nuance, however, is not what sells ad space or drives valuations. > — [pmpmpmpm on hackernews](https://news.ycombinator.com/item?id=49299161) > except it's anything but trivial workflows: it's very specific, individual workflows that match pretty much each individual's way of working and tasks at a given point in time. > — [jcelerier on lobsters · 3 points](https://lobste.rs/s/pf0hfr/there_is_still_no_silver_bullet#c_zchlah) **Source threads** - [lobsters](https://lobste.rs/s/pf0hfr/there_is_still_no_silver_bullet) · 8 points · 10 comments - [hackernews](https://news.ycombinator.com/item?id=49296324) · 6 points · 4 comments ## Similar posts on daily.dev - [Let’s talk about LLMs](https://daily.dev/posts/let-s-talk-about-llms-ibmomy8y5) · Planet Python · 1 upvotes · 0 comments - [It's OK. Do Your Thing](https://daily.dev/posts/it-s-ok-do-your-thing-cnwny6ial) · Lobsters · 0 upvotes · 0 comments - [AI Coding Assistants Haven’t Sped up Delivery Because Coding Was Never the Bottleneck](https://daily.dev/posts/ai-coding-assistants-haven-t-sped-up-delivery-because-coding-was-never-the-bottleneck-rvq2iif5k) · InfoQ · 0 upvotes · 0 comments - [The Future of Software Development is Software Developers](https://daily.dev/posts/the-future-of-software-development-is-software-developers-clpbexose) · Hacker News · 8 upvotes · 2 comments --- Tags: [#llm](https://daily.dev/tags/llm), [#productivity](https://daily.dev/tags/productivity), [#ai-coding](https://daily.dev/tags/ai-coding) [View this post on daily.dev](https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"There Is Still No Silver Bullet","url":"https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o"},"datePublished":"2026-08-14T23:24:18.898Z","dateModified":"2026-09-14T07:05:30.210Z","description":"An essay revisits Fred Brooks' 1986 'No Silver Bullet' essay, arguing its core claim still holds forty years later: no single tool can deliver a tenfold...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/58c9e83d708ad9a324ca5e71c93ec9d1?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/58c9e83d708ad9a324ca5e71c93ec9d1?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Lobsters","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Lobsters","logo":"https://media.daily.dev/image/upload/s--tl8v_Fku--/f_auto,t_logo/v1698841318/logos/lobste.jpg","url":"https://daily.dev/sources/lobsters"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"llm,productivity,ai-coding","timeRequired":"PT12M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Lobsters","item":"https://daily.dev/sources/lobsters"},{"@type":"ListItem","position":3,"name":"There Is Still No Silver Bullet"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/there-is-still-no-silver-bullet-1tzmxbq3o#faq","mainEntity":[{"@type":"Question","name":"Did AI assistance actually make experienced developers faster in the METR randomized controlled trial?","acceptedAnswer":{"@type":"Answer","text":"No, it made them 19% slower. Sixteen experienced open-source developers working in their own mature codebases were randomly assigned tasks with and without AI assistance in 2025; despite measuring 19% slower, the developers themselves estimated afterward that AI had sped them up by about 20%, a roughly 40 percentage point gap between felt and measured speed. Developers weighing AI coding tool claims against real measured impact can track findings like this on daily.dev."}},{"@type":"Question","name":"What is Fred Brooks' essence versus accident distinction in software engineering?","acceptedAnswer":{"@type":"Answer","text":"Essence is the conceptual construct of software: the interlocking concepts, data relationships, and decisions about what a system should do, which Brooks argued is the genuinely hard part. Accident is the labor of representing that construct: syntax, build tooling, and boilerplate. Because tools can only compress the accident, no tool can deliver a 10x productivity gain unless accident makes up nine tenths of the job. Engineers deciding where AI tools genuinely help versus just feel faster can follow this debate on daily.dev."}},{"@type":"Question","name":"Why did the METR follow-up study in 2026 find a different result than the 2025 study on AI coding productivity?","acceptedAnswer":{"@type":"Answer","text":"The February 2026 METR follow-up flipped the sign to a statistically inconclusive speedup, but the study itself explained that wider AI adoption made the effect nearly impossible to measure cleanly: developers refused to join studies barring AI use, and 30 to 50 percent admitted holding back tasks they expected AI to handle well, skewing results toward AI looking better even before accounting for the modest size of the reported gains. Teams sorting hype from evidence on AI coding productivity studies can follow the ongoing data on daily.dev."}}]} ```