Hot AI Debates: Is RAG Dead? Do Skills Replace MCP?

The latest episode of the GitHub Podcast poses some sharp questions that are generating heated debate in AI engineering circles: Do developers still need to read every line of AI-generated code? Is RAG (Retrieval-Augmented Generation) obsolete? And does Anthropic's new Skills concept spell the end of MCP (Model Context Protocol)? These topics may seem scattered, but they cut to the heart of several core challenges in deploying large language models today.

Note: This article is based on podcast preview materials published on the official GitHub blog. Since the original source only provides topic teasers, the analysis below draws on broader industry context to offer a deeper reading of each question.

Should You Still Read Every Line of AI-Generated Code?

With tools like Copilot and Claude Code making "AI writes, humans review" the new normal, a practical question has surfaced: when AI generates hundreds or thousands of lines of code at once, do developers still need to review it line by line the way they used to?

Proponents of "you must read the code" argue that humans are ultimately accountable — understanding the logic is essential for tracking down bugs and owning maintenance responsibilities. Blindly trusting generated output accumulates technical debt. The opposing camp contends that as test coverage, type checking, and runtime validation improve, human attention should shift toward higher-level architectural and behavioral verification rather than getting bogged down in every implementation detail.

At its core, this debate reflects a shift in software engineering's trust boundary — moving from "code correctness" toward "behavioral verifiability." A reasonable middle ground might be: core business logic and security-sensitive code still warrants careful reading, while boilerplate, scaffolding, and tests can rely more heavily on automated checks.

Is RAG Really Dead?

"RAG is dead" has become one of the more controversial takes in the community lately. The argument rests on two main points: first, model context windows keep expanding — now routinely hitting hundreds of thousands or even a million tokens — seemingly allowing you to "just stuff everything in"; second, the rise of agents and tool calling lets models retrieve information proactively rather than depending on pre-built vector stores.

But declaring RAG dead is clearly premature. No matter how large the context window gets, you still face costs, latency, and the well-documented attention degradation problem of finding a needle in a haystack. Stuffing massive document collections into a context is not only expensive — it doesn't necessarily outperform precise retrieval. RAG's value lies in providing models with timely, traceable, and updatable external knowledge at relatively low cost.

A more accurate framing is that RAG isn't dying — it's evolving. From simple "vector recall + concatenation" to hybrid retrieval, reranking, and composite architectures that integrate with agent retrieval capabilities. It's transitioning from a standalone technique into a capability module within intelligent agent systems.

---

The core idea behind RAG (Retrieval-Augmented Generation) is to retrieve relevant document chunks from an external knowledge base before sending a prompt to the model, then include those chunks as context — enabling the model to answer questions beyond its training data. Traditional implementations typically involve two stages: an offline phase where documents are chunked, embedded, and stored in a vector database; and an online phase where the user query is embedded, relevant chunks are retrieved via approximate nearest-neighbor search, and then appended to the prompt. This design allows the knowledge base to be updated independently of the model, and each retrieval provides traceable source citations — something pure parametric knowledge cannot offer. Current directions include Hybrid Search (combining dense vector retrieval with keyword search), Reranking (using cross-encoders to re-score retrieved results), and adaptive RAG architectures where agents dynamically decide when and what to retrieve during inference.

---

Will Skills Kill MCP?

The third question carries the most technical tension. MCP (Model Context Protocol), as an open protocol connecting models with external tools and data sources, was widely seen as a candidate standard for AI application interoperability. The emergence of the Skills concept — letting models extend their capabilities through predefined skill packages — has raised concerns about whether the two are in competition.

In reality, they operate at different levels of abstraction. MCP is more like a communication and integration protocol, specifying how a model accesses external resources. Skills lean more toward an organizational format for capability encapsulation, bundling the knowledge and operations needed for specific tasks into packages the model can invoke. In principle, Skills can be built on top of MCP rather than replacing it.

The "Skills kills MCP" narrative mostly reflects community anxiety about who will own the ecosystem standard — in a rapidly iterating AI toolchain, who becomes the de facto standard is still very much undecided. Rather than one replacing the other, it's more accurate to say that different abstraction layers are finding their respective places.

---

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024, designed to standardize how AI models interact with external tools and data sources. The design philosophy resembles that of USB-C — regardless of whether the underlying tool is a filesystem, database, or web API, any tool that implements an MCP server can be discovered and invoked by the model through a unified protocol, without needing custom integration layers for each tool. The protocol defines three primitives — Resources, Tools, and Prompts — and communicates via a standardized JSON-RPC message format. Skills, by contrast, are closer to a "higher-level abstraction": they package the knowledge, action steps, and tool calls needed to accomplish a particular class of tasks into capability units that the model can activate on demand. The two operate at different abstraction levels — MCP handles "how to connect," while Skills handle "what can be done once connected" — so they are not technically mutually exclusive.

---

What These Debates Tell Us

Looking at all three questions together, a common thread emerges: AI engineering is in a phase of rapid methodological reconstruction. Tools, protocols, and best practices are all in flux, and yesterday's consensus can be challenged today.

For developers, rather than chasing every "XX is dead" clickbait conclusion, the better move is to understand the fundamental problem each technology solves — code review is about trust and accountability; RAG is about the cost and timeliness of knowledge supply; MCP and Skills are about system extensibility and interoperability. Understand the underlying needs, and you won't be swept away by surface-level slogans.

Conclusion

The questions the GitHub Podcast raises don't have definitive answers, but they precisely capture the real confusion facing AI developers today. Technological evolution is never a simple matter of replacement — it's a dynamic balance of different solutions across different contexts. Staying attuned to trends while not blindly following the hype is the most grounded posture you can take in a field changing this fast.