Hot takes are everywhere in AI conversations right now. They’re sharp, memorable, and designed for engagement. ‘You still need to review AI-generated code.’ ‘Every developer should master prompt engineering.’ ‘RAG is dead.’ ‘Fine-tuning is obsolete.’
The problem with hot takes is they sound like conclusions when they’re really just starting points. At the surface level, they don’t matter much. You agree, disagree, repost, maybe argue for a few minutes, then move on. Sometimes the take is directionally right. Sometimes it’s complete nonsense. Neither tells you how to actually work.
But here’s what does matter: what happens when you stop reacting and start pulling them apart.
The Real Work Behind the Take
Take the hot take ‘You’re responsible for all AI-generated code.’ True, but it’s also incomplete. You are responsible for the code, but that doesn’t mean every generated line deserves the same level of attention. A production authentication refactor demands a different review process than a CSS experiment. A codebase you’ve maintained for ten years shapes your instincts differently than one you opened this morning.
The implication is that reviewers need context and judgment, not blanket rules. Pretending every change carries the same risk isn’t rigor. It’s just a bad use of time.
Sometimes the real work starts before the agent writes anything. You read the current implementation, map the dependencies, identify edge cases, and make a plan. By the time the first implementation exists, you already understand what it should do and where it could go wrong. Other times, the generated code itself needs most of your attention. You inspect error handling, permissions, data access, performance, accessibility, and tests.
AI moves the effort around. It doesn’t make the work disappear.
What We’re Actually Building
Another hot take: ‘Developers who refuse to use AI are falling behind.’ The reality is more nuanced. More teams are asking candidates how they use AI, and that makes sense. These tools are becoming part of software development. But no one thinks every developer needs the same workflow, tools, or level of enthusiasm.
The better question isn’t whether you use AI. It’s whether you can explain how you use it. Can you describe when you reach for the tool and when you work manually? Can you articulate how you review generated code? Can you talk honestly about speed, quality, security, and maintainability tradeoffs? Can you change your process as the tools change?
That kind of fluency is becoming part of the craft. Companies building AI products or using AI heavily in their engineering workflow might reasonably expect developers to engage with these tools. But total dependence and total refusal are rarely good answers. The answer that matters is clarity about how you work.
Standards, Skills, and What Comes Next
The Model Context Protocol gives agents a standard way to connect to tools and data. That standard matters when you want systems to work together reliably. Skills are closer to packaged expertise. A skill can explain how a team works, how a project should be changed, or which conventions matter. Since skills are often written in Markdown, people can actually read them.
You don’t need to pick a winner between them. Use standards for shared interfaces. Use skills for context, process, and best practices. The combination is more interesting than the argument.
Retrieval-augmented generation isn’t dead. It’s just not the newest thing people want to post about. RAG gives an AI system relevant information outside the model’s training data: documentation, support history, product details, internal knowledge, codebase context. Without good retrieval, the model wastes tokens, slows down, and produces incomplete answers. Good retrieval helps the model start closer to the answer. Learn more about how RAG shapes AI development.
Agents, skills, MCP, and RAG can all exist in the same workflow. An agent might use MCP to access a tool, follow a skill for project-specific instructions, and use retrieval to find supporting context. These things aren’t fighting each other.
The Maintainability Pressure Test
Here’s an idea worth testing: AI-assisted development rewards codebases that make their intent obvious. If your codebase confuses both people and models, that’s a maintainability problem. Clear structure helps. Consistent naming helps. Readable tests, useful abstractions, and current documentation help. Those things make a codebase easier for an agent to understand, but more importantly, they make it easier for a person to review, debug, and extend.
There are real projects experimenting with these questions. Pollinations AI created a generative platform where contributors earn credits by improving the project. Avian Visitors built a bird-listening e-ink display that combines a microphone, Raspberry Pi, e-ink screen, generated images, and thoughtful documentation. These projects don’t settle every AI debate. They create evidence, expose tradeoffs, and give other people a place to start. Explore more about open-source approaches to AI.
AI will keep producing strong opinions because the tools are changing quickly and we’re still figuring out our workflows. The better response to an interesting take isn’t another take. It’s to build something, document what happened, and give everyone something real to learn from.
What would happen if we treated hot takes not as conclusions but as questions worth testing?