Build1 publisher2 min readPublished
GitHub's review rule for AI code stops where you can explain and own the outcome
GitHub's podcast companion post argues that a production authentication refactor and a CSS experiment need different review, and it puts the same conditional test to "RAG is dead" and "Skills killed MCP".
The Engineer · Build desk
What happened
- GitHub published a post alongside its latest GitHub Podcast episode that takes four current AI hot takes and asks of each one under what conditions the claim actually holds.
- It tiers the effort by what the change touches, putting a production authentication refactor on a different review process from a CSS experiment.
- Against "Skills killed MCP", the post separates the two: the protocol gives agents a standard way to call tools and fetch context, while Skills package a team's conventions as readable Markdown.
- Against "RAG is dead", it argues that a model without good retrieval falls back on training data or burns time searching, wasting tokens and raising the odds of an incomplete answer.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision A stopping rule tied to explaining and owning the outcome makes the sign-off a question about the reviewer, so teams have to decide which engineers can own which subsystems.
- cost Moving review upstream into reading the implementation and mapping dependencies means the time is spent before any diff exists, out of reach of pull-request metrics.
- constraint Anyone consolidating on Skills alone still needs a wire format for tool calls, since explaining access in readable Markdown is a different job from granting it.
- capability Framing the retrieval argument as tokens and latency makes "RAG is dead" something a team can settle on its own workload.
"Review until you can explain and own the outcome" is the post's entire rule for AI-generated code [3]. It is a stopping condition, and what it costs depends on who is reading. GitHub's post says a codebase you have maintained for 10 years steers your instincts differently than one you opened this morning [6]. The same diff therefore has two different review costs depending on which engineer picks it up. "Pretending every change carries the same risk is not rigor. It is just a bad use of time," the post said [11].
Some of that effort lands before generation. The post describes reading the current implementation, mapping the dependencies, identifying edge cases, and making a plan, so that the first implementation arrives against an understanding you already hold [7]. When the weight falls on the output instead, it names six things to inspect: error handling, permissions, data access, performance, accessibility, and tests [8][9]. "AI moves the effort around. It does not make the work disappear," according to the post [10].
The other two takes answer to the same question the post opens with: under what conditions is this true [2]. The Model Context Protocol gives agents a standard way to connect to tools and data [12]. Skills are closer to packaged expertise, often written in Markdown so people can read them too, and the post treats that readability as part of their value [13]. "MCP can provide access. Skills can explain how to use that access well," the post said [14]. For Skills to have killed the protocol, you would have to have wanted only the instructions.
On "RAG is dead", the post argues from cost. Without good retrieval, the model relies on what it already knows or spends extra time searching for context, which wastes tokens, slows the work, and makes incomplete answers more likely [16]. Both halves of that are measurable on a given workload: token spend and wall-clock time for an agent that searches, against the cost of keeping an index current and the answers it grounds [15]. The post does not include such a measurement; it is a companion to a podcast episode [1].
The hiring claim is the one where the post concedes the most ground. More teams are asking candidates how they use AI, and refusing to touch it may make you a bad fit at a company that builds AI products or uses AI heavily in its engineering workflow [17]. The post says the stronger signal is judgment: whether you can explain when you use AI and when you work manually, and how you review what it generates [18].
What to watch
- Whether GitHub follows the argument with token and latency numbers comparing agentic search against a maintained retrieval index.
- Whether the tiering idea shows up in GitHub's own tooling as a risk label on pull requests, with review depth attached to it.
- Whether hiring loops start asking candidates for a written account of how they review generated code, as the post's judgment signal implies.