A post on the GitHub Blog discusses five popular assumptions about using artificial intelligence in software development, including that generated code does not need to be read, that RAG is over, and that Skills have made the Model Context Protocol (MCP) obsolete. The author argues that the value of these statements lies not in their abbreviated formulations being correct, but in breaking down their conditions and limitations when applied to actual work.
Responsibility for Code Does Not Shift to the Model
The article’s basic rule is that developers should review code to the point at which they can explain the result and take responsibility for it. This does not mean examining every line with the same depth; a change to a production authentication system deserves a different review from a simple CSS experiment.
Review may begin before the agent writes any code, by understanding the current implementation, identifying dependencies and edge cases, and creating a plan. In other cases, the resulting code requires direct scrutiny of error handling, permissions, data access, performance, accessibility, and tests. According to the article, AI changes where the effort is spent, but it does not eliminate the work itself.
The Most Important Skill Is Good Judgment
The post rejects the idea that companies will not hire people who do not use AI at all, but acknowledges that a growing number of teams ask candidates how they use these tools. The strongest signal, according to the argument, is not enthusiasm for the tool itself, but the ability to explain when a developer uses it and when they work manually, how they review its outputs, and how they balance speed, quality, security, and maintainability.
Avoiding AI may become an obstacle at a company that builds its products with AI or relies heavily on it, but complete dependence on it is not a better solution. The goal is to keep a human in the loop and maintain a clear explanation of what the developer trusts and what they do not.
MCP, Skills, and RAG Have Complementary Roles
The article distinguishes between the three tools. MCP provides a standardized way for agents to access and invoke tools and data, while Skills provide packaged knowledge about the team’s way of working, project modification rules, or established conventions. Because Skills are often written in Markdown, their readability by humans is part of their usefulness.
RAG, or retrieval-augmented generation, brings relevant information from outside the model’s training data into the system, such as documentation, support history, product details, internal knowledge, and codebase context. Good retrieval helps the model start from context closer to the answer, while reducing the search space and the likelihood of providing an incomplete response.
Therefore, the author does not believe that Skills killed MCP or that RAG is dead; an agent may use MCP to access a tool, follow a Skill to apply project-specific instructions, and use retrieval to obtain supporting context. Conflict between these components overlooks how they can work together in a single workflow.
Maintainability Faces a New Test
The post also discusses the idea that needing to train a model on a particular codebase necessarily means the code is poor. There are legitimate reasons for custom training, but a model’s inability to understand a codebase may reveal a problem that a new colleague would face as well.
Clear structure, consistent naming, readable tests, useful abstractions, and up-to-date documentation make code easier for both agents and humans to understand. The editorial reading here is that AI tools do not exempt teams from software engineering practices; they may instead make maintainability defects more visible.
From Discussion to Experiment
The article concludes by calling for opinions to be tested in practice rather than replacing each opinion with an opposing one. It cites the Pollinations AI project, where contributors can earn credits called pollen by improving the project, and the Avian Visitors project, which documents an electronic-ink display that listens to birds and turns their visits into changing artworks using a microphone, Raspberry Pi, 3D-printed components, and generated images.
These projects do not settle every AI debate, but they produce evidence and reveal trade-offs. The material’s main limitation is that it offers a general guiding framework and examples, not comparative measurement results proving the superiority of a specific workflow. Its recommendations should therefore be treated as test points for practice, not final rules.