--- title: Primeagen says vibe coding discourse lost the plot, and... description: Primeagen argues the vibe coding debate has devolved into unproductive camps when the real answer is context-dependent. His core point: the right approach... canonical: https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Primeagen says vibe coding discourse lost the plot, and he's not wrong | daily.dev og:description: Primeagen argues the vibe coding debate has devolved into unproductive camps when the real answer is context-dependent. His core point: the right approach... og:url: https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n og:image: https://api.daily.dev/og/posts/53XsQ2T6N.png og:image:alt: Primeagen says vibe coding discourse lost the plot, and he's not wrong 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. # Primeagen says vibe coding discourse lost the plot, and he's not wrong **[Trends](https://daily.dev/sources/trends)** · 2 min read · 3 upvotes · 3 comments ## Summary Primeagen argues the vibe coding debate has devolved into unproductive camps when the real answer is context-dependent. His core point: the right approach depends on what you're building and how much technical debt you can tolerate. He criticizes years of abstraction that trained developers to ignore underlying complexity, and warns against treating AI-assisted coding as a universal replacement for thoughtful engineering. The emerging community consensus aligns with this — vibe coding suits prototypes and throwaway scripts, but falls short for production-critical software. Those who overclaimed are quietly walking it back. ## Content The policy era has arrived. In the span of a few weeks, the Linux kernel's staging tree, the Linux wireless subsystem, NetworkManager, Godot, Rust, GNOME's extensions portal, and Codeberg have all published formal stances on AI-generated contributions. The details vary, but the direction is the same: maintainers are done absorbing the cost. The proximate cause is volume. Linux networking maintainer Jakub Kicinski counted 1,092 patches tagged for his subsystem in nine days, with 37% being fixes — a ratio that only makes sense if something is generating code faster than it can understand it. Johannes Berg (Linux wireless) responded with a "three second review" rule: if a patch isn't obviously correct at a glance, it gets ignored. No feedback, no back-and-forth. Greg Kroah-Hartman went further in staging, banning LLM patches outright on the grounds that staging exists to teach humans the contribution process, not to give AI something to clean up. The security angle is getting less attention than it deserves. Andreas Kling put it plainly: "We're now in an age of near-zero-cost code generation. Malicious actors can flood a project with a thousand benign PRs to make one malicious change disappear into the noise. 'pwomise you didn't use AI' is not a serious security strategy." Most of the policies being written are about maintainer bandwidth. Almost none of them address this. The economics underneath all of this are what Will McGugan captured best: open source runs on social reciprocity. Someone asks for help, a maintainer helps, a relationship forms. "When I get 5 pages of text with headers culminating in a hallucinated 'Root Cause'," he wrote, "nobody is asking me for a favor. A robot is instructing me to do something." Charlie Marsh made the same point from the reviewer side: reviewing a PR used to be an investment in a contributor. With agents, that's gone. The Rust policy is probably the most carefully scoped response so far — LLMs are fine for analysis and refinement, not for generating code changes, with mandatory disclosure and a higher review bar for anything AI-touched. Codeberg went blunter: projects that are *mostly* AI-generated code are banned, full stop. What's forming isn't consensus exactly. It's a floor. The question of where the ceiling goes — whether any AI contribution is ever welcome, under what conditions — is still wide open. ## Questions this post answers ### What is the Rust core team's official policy on LLM-generated contributions? Rust's core teams published a formal LLM policy that requires disclosure when LLM output is submitted for review, mandates that submissions include tests, and flatly bans LLM-authored changes to soundness-critical code. The policy distinguishes between a developer using an LLM as a tool versus submitting raw LLM output for others to review — the latter carries a higher bar. _Rust contributors navigating this policy track its real-world enforcement on daily.dev._ ### Why is the Linux kernel removing old drivers instead of just ignoring AI-generated patches for them? Linux kernel maintainers are removing drivers for obsolete hardware because AI agents continuously generate patches targeting that code, creating a stream of low-quality submissions maintainers must triage. Deleting the code eliminates the surface area entirely, which maintainers consider less costly than indefinitely fielding the noise from automated patch generators. _Kernel contributors watching how maintainers reshape contribution norms follow the fallout on daily.dev._ ### What is the security risk of AI agents flooding open source projects with pull requests? Near-zero-cost code generation lets malicious actors submit thousands of benign-looking PRs to bury one malicious change in the noise. Maintainer Andreas Kling argues that informal promises not to use AI are not a serious security strategy, and most current policies address maintainer annoyance rather than this attack vector, leaving the security angle largely unaddressed. _Teams responsible for open source security posture keep up with emerging threats like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 278 comments across hackernews, lobsters (as of 2026-08-08). **TL;DR:** The community is broadly frustrated with the phenomenon of people forwarding raw LLM outputs to colleagues instead of engaging themselves — dubbed 'meat proxying' or 'slop grenades' — seeing it as lazy, cognitively burdensome, and a sign of broader intellectual decline accelerated by AI tools. rust-lang/rust is adopting an LLM policy: The community broadly respects the policy's thoughtfulness — especially the explicit anti-harassment rule for LLM users — while debating enforceability, the create/refine distinction, and whether disclosure requirements will invite gatekeeping of new contributors. **Sentiment:** 22% positive · 32% mixed · 46% skeptical **The case for** - Using LLMs to research and then synthesizing the answer yourself can genuinely save time and get people to better answers faster. - The explicit rule prohibiting harassment of LLM users was widely praised as unusually fair and not seen in comparable policies. - Some commenters note that forwarding an LLM response can represent real work: reformulating the question, steering the model, and filtering its output. - The policy's core distinction — LLMs fine for analysis/refinement, not for creation — was seen as a clear, principled bright line. - AI tools can democratize access to answers for people who lack the expertise to find them otherwise. **The pushback** - People are forwarding raw, unverified LLM output to colleagues and expecting them to read and validate it, offloading cognitive work entirely. - Concern that disclosure requirements will enable false accusations and gatekeeping of new contributors who have no community connections to defend themselves. - LLM-generated text is often verbose, jargon-heavy, and hard to parse, increasing cognitive load on the recipient. - The create/refine distinction is philosophically fuzzy — analysis, distillation, and suggestion are themselves acts of creation. - This behavior is being encouraged or modeled from the top of organizations, making it hard to push back. **By community** - hackernews (skeptical): Commenters are overwhelmingly critical of 'meat proxying' and AI slop culture, sharing frustrating workplace anecdotes and debating whether this signals a deeper cognitive decline. **Hottest debate:** Whether forwarding a Claude response to a colleague constitutes legitimate, value-adding work or is simply lazy buck-passing. **Open questions** - How should individuals disclose when they used an LLM to answer a question asked of them? - How will moderators practically distinguish LLM-generated code from human code written by someone who simply writes in a polished style? - Will organizations develop norms or policies that discourage raw LLM output sharing, or will management pressure push the other way? - What is the concrete onboarding path for a new contributor who wants to use LLM-generated code but knows no reviewers to pre-arrange it with? - Is the observed decline in IQ scores and critical thinking causally linked to technology use, and will AI accelerate it further? **Highlights** > > the code itself is the smallest and in some ways least important part of the change. We care much more about authors understanding what the code does, planning how it will change in the future, and deciding what it should look like. The code itself cannot help with any of those. This struck me so hard I just wrote a post to my team about it. Yesterday I reviewed an LLM-generated PR from a teammate that did identify and fix the source of a bug, but did so in a ridiculous way that resembled a Rube Goldberg device. I don’t know whether the co-worker reviewed the change at all before creating the PR. > — [snej on lobsters · 1 points](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy#c_jmmye6) > Please put summaries/TL;DR on comms like these. I don't really care if it was written by a clanker or not. I want to know how am I expected to behave without needing to sieve through pages and pages of text like I'm dealing with a government. IMO. In generally every formal-ish communication should follow a progressive disclosure style, where it starts with a most concise summary, then progressively gets into more and more details that people can read on a per-need/interest basis. > Rust’s new LLM policy says: > > * **Private use is fine:** understanding code, brainstorming, summarizing, and reviewing your own work. > * **Public LLM-written prose is generally banned:** issue text, PR descriptions, comments, docs, diagnostics, and substantive code comments. > * **LLM-assisted reviews and bug discovery are allowed with disclosure**, but humans must verify findings and make decisions. > * **LLM-generated code PRs are allowed only by prior agreement**, with disclosure, strong tests, human understanding, and usually only for non-critical code. > * Contributors must disclose relevant LLM use, but reviewers should not publicly accuse people based only on writing style. > > The goal is to protect reviewer time, accountability, and genuine technical understanding. Seems reasonable to me. > — [dpc\_pw on lobsters · 1 points](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy#c_hyr2v2) > I deal with this all day long at work and it’s exhausting. People almost acting like no one has thought of it “I asked Claude what happened, and it spit out this 300 line response. Can you read it for me and see if it’s right?” What kills me is you might expect this from a busy high level manager that doesn’t really understand the technical details and they just point the AI to an error they got. They don’t know how to interpret the response, so they ask someone who work on the thing. It’s still kinds annoying because you could just ask, but whatever. But to get these from junior and senior engineer for the areas they work in and expect someone else to read it for them? It’s crazy behavior. How can someone serious even think that’s ok. > — [eddythompson80 on hackernews · 7 comments](https://news.ycombinator.com/item?id=49152018) > I just can’t understand why this is not a fireable offense. Like, I can see getting a strong warning the first time somebody notices you do this, then if you persist you’d have to be let go. Just like anybody else who is clearly not doing their job. Why would you tolerate this sort of behavior at your company? > — [jasonkester on hackernews · 4 comments](https://news.ycombinator.com/item?id=49152301) > I wrote about a year ago: https://blog.gpkb.org/posts/just-send-me-the-prompt/ Sending LLM outputs to people is worse than useless, because you don't even know what they prompted with. For all you know it was "write me a paragraph justifying my opinion". > — [globular-toast on hackernews · 1 comments](https://news.ycombinator.com/item?id=49152491) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49151933) · 102 points · 182 comments - [hackernews](https://news.ycombinator.com/item?id=49179039) · 61 points · 72 comments - [lobsters](https://lobste.rs/s/czvkjy/rust_lang_rust_is_adopting_llm_policy) · 104 points · 24 comments ## Similar posts on daily.dev - [AI Can No Longer Rampage Through Rust's Code Repo](https://daily.dev/posts/ai-can-no-longer-rampage-through-rust-s-code-repo-npr4hm4wd) · It's Foss · 11 upvotes · 0 comments - [96% of codebases rely on open source, and AI slop is putting them at risk](https://daily.dev/posts/96-of-codebases-rely-on-open-source-and-ai-slop-is-putting-them-at-risk-zihu4vvqv) · The New Stack · 0 upvotes · 0 comments - [AI Contributions and Maintainer Load in Open Source](https://daily.dev/posts/ai-contributions-and-maintainer-load-in-open-source-acgatvw21) · Planet Python · 0 upvotes · 0 comments --- Tags: [#productivity](https://daily.dev/tags/productivity), [#ai-coding](https://daily.dev/tags/ai-coding), [#vibe-coding](https://daily.dev/tags/vibe-coding) [View this post on daily.dev](https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n) ```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":"Primeagen says vibe coding discourse lost the plot, and he's not wrong","url":"https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n"},"datePublished":"2026-07-31T15:03:17.859Z","dateModified":"2026-08-08T00:22:23.613Z","description":"Primeagen argues the vibe coding debate has devolved into unproductive camps when the real answer is context-dependent. His core point: the right approach...","isAccessibleForFree":true,"articleSection":"Trends","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":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":3,"discussionUrl":"https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":3}],"keywords":"productivity,ai-coding,vibe-coding","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"Primeagen says vibe coding discourse lost the plot, and he's not wrong"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/primeagen-says-vibe-coding-discourse-lost-the-plot-and-he-s-not-wrong-53xsq2t6n#faq","mainEntity":[{"@type":"Question","name":"What is the Rust core team's official policy on LLM-generated contributions?","acceptedAnswer":{"@type":"Answer","text":"Rust's core teams published a formal LLM policy that requires disclosure when LLM output is submitted for review, mandates that submissions include tests, and flatly bans LLM-authored changes to soundness-critical code. The policy distinguishes between a developer using an LLM as a tool versus submitting raw LLM output for others to review — the latter carries a higher bar. Rust contributors navigating this policy track its real-world enforcement on daily.dev."}},{"@type":"Question","name":"Why is the Linux kernel removing old drivers instead of just ignoring AI-generated patches for them?","acceptedAnswer":{"@type":"Answer","text":"Linux kernel maintainers are removing drivers for obsolete hardware because AI agents continuously generate patches targeting that code, creating a stream of low-quality submissions maintainers must triage. Deleting the code eliminates the surface area entirely, which maintainers consider less costly than indefinitely fielding the noise from automated patch generators. Kernel contributors watching how maintainers reshape contribution norms follow the fallout on daily.dev."}},{"@type":"Question","name":"What is the security risk of AI agents flooding open source projects with pull requests?","acceptedAnswer":{"@type":"Answer","text":"Near-zero-cost code generation lets malicious actors submit thousands of benign-looking PRs to bury one malicious change in the noise. Maintainer Andreas Kling argues that informal promises not to use AI are not a serious security strategy, and most current policies address maintainer annoyance rather than this attack vector, leaving the security angle largely unaddressed. Teams responsible for open source security posture keep up with emerging threats like this on daily.dev."}}]} ```