--- title: RAG is dead, MCP is obsolete, and other takes the GitHub... description: A GitHub Podcast episode pushes back on five recurring AI hot takes: whether RAG is dead (no, it still improves grounding and reduces token waste), whether... canonical: https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: RAG is dead, MCP is obsolete, and other takes the GitHub Podcast is tired of | daily.dev og:description: A GitHub Podcast episode pushes back on five recurring AI hot takes: whether RAG is dead (no, it still improves grounding and reduces token waste), whether... og:url: https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk og:image: https://api.daily.dev/og/posts/kZEgvo8zk.png og:image:alt: RAG is dead, MCP is obsolete, and other takes the GitHub Podcast is tired of 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. # RAG is dead, MCP is obsolete, and other takes the GitHub Podcast is tired of **[Trends](https://daily.dev/sources/trends)** · 3 min read · 4 upvotes · 0 comments ## Summary A GitHub Podcast episode pushes back on five recurring AI hot takes: whether RAG is dead (no, it still improves grounding and reduces token waste), whether Agent Skills killed MCP (no, they're complementary), whether all AI code needs review (depth should scale with risk), whether companies should mandate AI use in hiring (judgment matters more than mandates), and whether needing to fine-tune implies bad code (not necessarily). The overall argument is that hot-take framing flattens nuanced tradeoffs into false binaries, and the more useful question, raised separately by Geoffrey Litt, is what infrastructure changes are needed now that code is cheap to write. ## Content The typing bottleneck is gone, and the bottleneck moved to review. Nobody agrees on what to do about it. The numbers are ugly. LinearB's 2026 benchmarks show AI-generated PRs merging within 30 days at 32.7%, versus 84.4% for human-written ones. Faros AI's data across 22,000 developers found one bank saw a 441% rise in review time and 243% more incidents per PR. Speed didn't disappear, it just relocated downstream. **The skeptics say AI still writes bad code.** @devongovett: "Working code and *good* code are two very different things." He routinely ends up with half of what the agent produced, functionally identical but simpler. @omarsar0 agrees: agents "don't give a crap" about optimal versus suboptimal, and "it's really easy to produce absolute slop." One developer went further and quit AI tools for a month after a coworker caught a fundamentally flawed AI-written test in a PR they'd approved without really understanding. **Others say the code is fine, the alignment isn't.** One essay argues agents already write fewer bugs than humans. What humans add is fit with a company's taste and strategy, which it frames as the argument against DHH-style vibe-coding maximalism. **Then there's the "nobody reads it" camp.** Addy Osmani predicts routine SaaS code will rarely get line-by-line review within two years. His caveat: review exists for accountability, so trust has to shift to independent checks (specs, tests, reference implementations) not written by the same model. @housecor already lives there: "My job no longer involves writing code." He picks tasks, writes prompts, and builds verifiers. **The knowledge-sharing casualty.** Review was also how juniors learned and teams built shared mental models. Aviator's piece calls the resulting gap "cognitive debt": code ships faster while teams understand their own systems less. A separate essay describes shipping AI-assisted code the author couldn't explain the next day. **Institutions are writing rules.** The Linux kernel now requires human sign-off on every AI-assisted submission, with documented provenance and a submitter who can explain the code in detail. The GitHub Podcast's take on "should you read the code": yes, but scale depth with risk. The agent failure catalog from DoltHub reads like a rap sheet: The Commentator, The CI Murderer, The Test Fix (changing tests instead of code). Meanwhile Orca Security found an AI platform's own scan declared a weekend-built app production-ready when row-level security was broken. The pattern: everyone agrees review can't stay as it was. The fight is over whether humans move up to intent and verification, or quietly stop looking. ## Questions this post answers ### Is RAG (retrieval-augmented generation) dead now that long-context models exist? No, RAG is not dead. It still improves grounding and reduces wasted tokens compared to stuffing everything into a long context window. Long-context models and retrieval solve overlapping but different problems, so the claim that long context makes RAG obsolete resurfaces periodically but doesn't hold up when the two approaches are compared directly. _Developers weighing RAG against long-context approaches can follow ongoing takes on daily.dev._ ### Did GitHub's Agent Skills replace or kill MCP? No, Agent Skills and MCP solve different problems and can be combined rather than one replacing the other. The idea that one technology killed the other oversimplifies how they actually complement each other in practice. _Anyone deciding between agent tooling options can track how MCP and Agent Skills evolve together on daily.dev._ ### Should every piece of AI-generated code be manually reviewed before merging? Review depth should scale with the risk of the code, not be applied uniformly. A trivial one-line change can be rubber-stamped, but AI-generated authentication logic or other high-risk code should never be shipped without a thorough human read-through. _Teams setting AI code review policy can compare risk-based approaches like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 2 discussions and 449 comments across lobsters, hackernews (as of 2026-09-29). **TL;DR:** The discussion is dominated by a long, heated argument over whether heavy AI-agent coding without reading/reviewing code is viable, with most participants pushing back hard on one commenter's claim of never reading code for six months, citing hidden bugs, fragility at scale, and eroded understanding. **Sentiment:** 15% positive · 30% mixed · 55% skeptical **The case for** - A few argue AI can implement common patterns like 2FA better than average developers and speeds up iteration dramatically. - Some say AI is useful for rapid prototyping and validating design ideas quickly before a cleanup pass. - One commenter reports genuine productivity gains on a mature product, implementing years-old feature requests in a month. **The pushback** - Multiple commenters found that AI-generated code, even when reviewed carefully, contained subtle production-breaking bugs (dropped messages, clock drift, missing backpressure). - People argue that not reading or testing code you ship is an abdication of responsibility, especially for security-sensitive features like 2FA. - Several note that AI models still hallucinate, miscount code usages, and confidently make things up, undermining trust. - Critics say a lone developer's untested toy app is not evidence that 'code doesn't matter anymore' at real scale with paying users. - Some feel AI-generated code is overly defensive/verbose, adding unnecessary guards and abstractions that make review harder. **By community** - lobsters (mixed): No comments were provided, so no discernible take could be formed beyond the point count. - hackernews (heated): A sprawling, contentious back-and-forth pits skeptics who insist on reading/testing code against a proponent who claims to ship untested, unread AI-written code successfully, with most participants pushing back skeptically. **Hottest debate:** Whether it's acceptable to ship code you've never read or tested because AI wrote and 'validated' it, versus the view that this is reckless abdication of responsibility. **Open questions** - Does this vibe-coding approach hold up once an app has real paying users depending on it, rather than remaining an untested toy? - How should teams verify AI-written code when no one on the team has actually read or understood it? - Will future language/tooling features (capability types, formal verification, static analysis) replace manual code review as the primary safeguard? **Highlights** > No. Haven't typed a line of code or read any code for over 6 months now. And I used to love coding and be a competitive programmer, but this is how "coding" goes nowdays. I have a mental model of what it would do, and how it would work, and I ask questions to confirm things and tell it to watch for specific gotchas. Then simply test the feature myself a bit. Security-wise, I think the latest cyber models are better than me anyway at finding vulnerabilitates and pentesting such features. Plus 2FA is a very common pattern, so it likely has in the training dataset many really good implementations. > — [XCSme on hackernews · 5 comments](https://news.ycombinator.com/item?id=49855549) > That’s not what you want at all. I mostly vibe coded a queuing system to replace something we’re using at work (last week. Spent about $1500). Then I meticulously went through the code. It was much harder to review because it was ultra defensive and included guards for tons of edge cases that weren’t possible. Unnecessary abstractions for possible extension later. Useless indirection. Probably 3x as much code as there would have been if I’d written it by hand. I didn’t one shot this. I kept a pretty tight leash on the AI. I had probably a dozen markdown files with of plans that I created over hours of back and forth with the AI and reviewed before each implementation round. I had automated reviews and quality gates etc… What I found in review was that it was full of very subtle bugs that would have bitten hard in prod. Committing offsets asynchronously that would lead to dropped messages. Clock drift bugs that would lead to dropped messages or write amplification storms. Lack of back pressure in some stages of the pipeline that would cause notes to get silently OOM killed. Weird over-insistence on never crashing in most places that would mask systemic errors. If I’d just shipped it without review, it would have mostly worked. But at the scale it’s going to be used (tens of thousands of messages per second) it would have caused production issues for months while we tracked down each of these issues. > — [sarchertech on hackernews · 1 comments](https://news.ycombinator.com/item?id=49856310) > That is a cool app. But if you’d said you’d made it by hand in a few months I would have believed you. If I had a working software factory like you describe, I’d expect you to have hundreds of apps of that level of complexity in a year. > I don't even know how "vibe-coding" works in a team environment, because for me now it feels like it's "ideas to app" directly, so dumping by brain/ideas directly into a functional product. But you don’t have any users much less paying users, so you have no idea if this system works when you do. > — [sarchertech on hackernews · 1 comments](https://news.ycombinator.com/item?id=49858112) > > Haven't typed a line of code or read any code for over 6 months now > I ask questions to confirm things Oh my. As someone who reads the code, I can tell you, asking questions to confirm things is inadequate. The models lie to me, daily. Every day I have two experiences: 1. I’m blown away by what it can do 2. I say, ”wait, you said this, but the code shows that, so you were just going to leave that endpoint without requiring any authentication??” and I get the “you’re absolutely right, that was my mistake, and you’re right to call it out” song and dance. Daily. It also adds all kinds of bloat to code, tests, and “documentation”. I’d say I spend ~30% of my dev time picking lines of code or documentation and asking, “why does this exist?” and “what would break if we deleted this line?” and then arguing with it and removing things. > — [halfcat on hackernews · 1 comments](https://news.ycombinator.com/item?id=49856222) > > The code they supplied to me has NEVER worked or was so convoluted that I threw it away and did it myself. For me, it's like reading prose with "Not X, not Y, just Z": it's technically correct, but grates like fingernails on a chalkboard. I have real trouble sometimes, reading what SOTA (Fable, etc) generate - no isolation or partitioning at all. The worst was the planning an AI does. When I plan something, it'll be split according to data structures "An object to hold this, an intermediary for the obejct to talk to ORM, a serialiser for it that does this", etc. The "plans" from SOTA are sometimes just hilarious. It'll go "phase one, implement these user-facing features. Phase two, implement those user-facing features", etc. That's not a plan, it's an aspiration! A roadmap maybe. A plan, in my way of working, is a blueprint of where all the data goes, with algorithms connecting them. With AI, the data is incidental, the algorithms are incidental, only the goal (in the form of tests) remain. It'll work out some spur-of-the-moment idea around data at the time of writing. So yeah, I do what you do and throw their stuff away. Currently having more success laying down a skeleton manually and then asking them to add a single feature at a time. That's with SOTA models as of September-26-2026. > — [lelanthran on hackernews · 4 comments](https://news.ycombinator.com/item?id=49857564) **Source threads** - [lobsters](https://lobste.rs/s/ivbx5f/one_month_without_ai) · 17 points · 3 comments - [hackernews](https://news.ycombinator.com/item?id=49855018) · 175 points · 446 comments ## Similar posts on daily.dev - [Agentic Code Review](https://daily.dev/posts/agentic-code-review-0ue8fcsa1) · Addy Osmani · 146 upvotes · 14 comments - [As AI helps us write more code, who’s catching the bugs?](https://daily.dev/posts/as-ai-helps-us-write-more-code-who-s-catching-the-bugs--swtlsnqbi) · LeadDev · 1 upvotes · 1 comments --- Tags: [#github](https://daily.dev/tags/github), [#ai-coding](https://daily.dev/tags/ai-coding), [#mcp](https://daily.dev/tags/mcp), [#rag](https://daily.dev/tags/rag) [View this post on daily.dev](https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk) ```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":"RAG is dead, MCP is obsolete, and other takes the GitHub Podcast is tired of","url":"https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk"},"datePublished":"2026-09-23T03:08:52.128Z","dateModified":"2026-09-29T20:24:17.701Z","description":"A GitHub Podcast episode pushes back on five recurring AI hot takes: whether RAG is dead (no, it still improves grounding and reduces token waste), whether...","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":0,"discussionUrl":"https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":4},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"github,ai-coding,mcp,rag","timeRequired":"PT3M"} {"@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":"RAG is dead, MCP is obsolete, and other takes the GitHub Podcast is tired of"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/rag-is-dead-mcp-is-obsolete-and-other-takes-the-github-podcast-is-tired-of-kzegvo8zk#faq","mainEntity":[{"@type":"Question","name":"Is RAG (retrieval-augmented generation) dead now that long-context models exist?","acceptedAnswer":{"@type":"Answer","text":"No, RAG is not dead. It still improves grounding and reduces wasted tokens compared to stuffing everything into a long context window. Long-context models and retrieval solve overlapping but different problems, so the claim that long context makes RAG obsolete resurfaces periodically but doesn't hold up when the two approaches are compared directly. Developers weighing RAG against long-context approaches can follow ongoing takes on daily.dev."}},{"@type":"Question","name":"Did GitHub's Agent Skills replace or kill MCP?","acceptedAnswer":{"@type":"Answer","text":"No, Agent Skills and MCP solve different problems and can be combined rather than one replacing the other. The idea that one technology killed the other oversimplifies how they actually complement each other in practice. Anyone deciding between agent tooling options can track how MCP and Agent Skills evolve together on daily.dev."}},{"@type":"Question","name":"Should every piece of AI-generated code be manually reviewed before merging?","acceptedAnswer":{"@type":"Answer","text":"Review depth should scale with the risk of the code, not be applied uniformly. A trivial one-line change can be rubber-stamped, but AI-generated authentication logic or other high-risk code should never be shipped without a thorough human read-through. Teams setting AI code review policy can compare risk-based approaches like this on daily.dev."}}]} ```