Should you read the code, is RAG dead, and did Skills kill MCP?

Five AI claims, examined

Hot takes compress complicated subjects into one confident sentence. That works for engagement and poorly for understanding — but the value shows up once you stop reacting and start asking what conditions make the claim true, what context is missing, and what happens when it meets real work.

"You don't need to read AI-generated code"

You do. You remain responsible for the code.

That does not mean every generated line earns equal scrutiny. A production authentication refactor and a CSS experiment are not the same risk, and a codebase you have maintained for 10 years steers your instincts differently than one you opened this morning. Uniform rigor is not rigor; it is wasted time.

The useful rule: review until you can explain and own the outcome. Sometimes that work happens before the agent writes anything — reading the current implementation, mapping dependencies, identifying edge cases, making a plan, so the first implementation lands in a mind that already knows what it should do and where it could break. Other times the generated code itself takes most of your attention: error handling, permissions, data access, performance, accessibility, tests.

AI relocates effort. It does not remove it. The skill being tested is knowing where the risk lives.

"Companies won't hire you if you don't use AI"

Closer to true than false, but flattened. More teams ask candidates how they use AI, which is unsurprising as the tools become part of software development. What they should not expect is one workflow, one toolset, or one level of enthusiasm.

Judgment is the stronger signal: can you say when you use AI and when you don't, describe how you review generated code, talk plainly about speed, quality, security and maintainability, and adapt as the tools change? A developer building AI products or working in an AI-heavy engineering org may genuinely be a poor fit if they refuse to touch the tools — that is not controversial. Total dependence and total refusal are both weak positions. The answer worth giving is a clear account of how you work, what you trust the tools to do, and where you keep yourself in the loop.

"Skills killed MCP"

They address different problems. The Model Context Protocol standardizes how agents connect to tools and data — structured ways to call tools, fetch context, and take action, which matters when systems have to interoperate reliably. Skills are closer to packaged expertise: how a team works, how a project should be changed, how a tool should be used, which conventions matter. They are often written in Markdown, so people can read them; that readability is part of the point.

MCP supplies access, skills explain how to use that access well. Standards for shared interfaces, skills for context and process. No winner has to be declared.

"RAG is dead"

RAG is not dead; it is simply no longer the newest thing to post about. Retrieval-augmented generation supplies relevant information from outside the training data — documentation, support history, product details, internal knowledge, codebase context.

Skip retrieval and the model falls back on what it already knows or burns extra time searching for context, which wastes tokens, slows the work, and invites incomplete answers. Good retrieval starts the model nearer the answer, narrows the search space, and grounds the response in information that matters. Agents, skills, MCP and RAG coexist in one workflow: an agent reaches a tool through MCP, follows a skill for project-specific instructions, and retrieves the supporting context. Framing them as antagonists misses how people actually build.

"If you need to fine-tune for your codebase, your code is bad"

Valid reasons to fine-tune exist. Still, modern models have absorbed an enormous range of frameworks, patterns, naming conventions and architectures. If a model cannot make sense of your codebase, a new teammate probably struggles too.

AI is another pressure test on maintainability, sitting alongside code review, testing, onboarding, and whoever debugs this six months from now. Clear structure, consistent naming, readable tests, useful abstractions and current documentation all help — first for the person reviewing, debugging and extending the code, and incidentally for the agent. AI-assisted development rewards codebases that make their intent obvious.

Evidence beats another take

The tools are changing fast and most of us are still assembling our workflows, so strong opinions will keep arriving. You don't owe any debate a permanent side.

Two projects show the alternative. Pollinations AI experiments with a generative AI platform where contributors earn credits — pollen — by improving the project: opening and solving issues, contributing models, completing quests. It raises live questions about incentives, quality, scale, and what open source contribution looks like when AI lowers the barrier to entry. Avian Visitors goes another direction entirely: a build log for a bird-listening e-ink display that turns balcony visitors into changing wall art, combining a microphone, Raspberry Pi, e-ink screen, 3D-printed parts and generated bird images, with documentation to match.

Neither settles an AI debate. Both produce evidence, expose tradeoffs, and hand someone else a starting point.

Read enough code to own the result. Build enough fluency to explain your process. Use MCP where a standard interface earns its keep, skills where context and process matter, RAG where grounding improves the system. Treat code that confuses both people and models as a maintainability problem. Then do something with what you learn.