Hot takes are everywhere in AI conversations right now. They’re sharp, confident, and designed to spark reactions. But I’ve noticed something: the takes that stick around aren’t the ones that make the boldest claim. They’re the ones that force you to ask better questions.
A hot take works best when it’s wrong in interesting ways. Not completely nonsensical, but directionally bold enough that you want to pull it apart. Under what conditions is this actually true? What context got left out? What assumptions does it rest on? That friction between the take and reality is where learning happens.
Code Review Doesn’t Disappear With AI
One hot take I keep seeing: “You don’t need to review AI-generated code.” This is simultaneously too dismissive and too generous. You absolutely still need to review it. But not every generated line deserves the same attention.
A production authentication refactor and a CSS experiment aren’t equivalent risks. A codebase you’ve maintained for ten years steers your instincts differently than one you opened this morning. Pretending all changes carry the same weight isn’t rigor, it’s wasted effort.
The real rule is simpler: review until you can explain and own the outcome. Sometimes that work starts before the agent writes anything. You read the current implementation, map dependencies, identify edge cases, and plan the approach. By the time code gets generated, you already understand what should happen and where it could break. Other times the generated code itself needs most of your attention: error handling, permissions, data access, performance, accessibility, tests.
AI shifts the effort around. It doesn’t make the work disappear. And that’s actually useful information for how you should approach your workflow.
AI Fluency Is Different From AI Dependence
Another take: “You must use AI or you’ll be left behind.” The pushback is predictable: “You shouldn’t need AI to be a good developer.” Both miss something important.
More companies are asking candidates how they use AI. That’s reasonable. These tools are becoming infrastructure for software development. But no one thinks every developer needs identical workflows or the same enthusiasm for specific tools.
What actually matters is fluency. Can you explain when you use AI and when you don’t? Can you describe how you review generated code? Can you talk honestly about speed, quality, security, and maintainability? Can you adapt your process as the tools change?
If a company builds AI products or relies heavily on AI in engineering workflows, refusing to engage at all probably makes you a poor fit. That’s not controversial. But total dependence and total refusal are both rarely good answers. The better answer is a clear explanation of how you work, what you trust tools to do, and where you stay in control.
Standards, Skills, and Context Working Together
I see a lot of arguments about what matters: the Model Context Protocol versus skills, RAG versus fine-tuning, agents versus workflows. The framing is usually competitive, like you pick one winner.
You don’t need to. MCP provides standards for how systems connect to tools and data. That matters when you want reliable interactions. Skills capture packaged expertise, often in readable Markdown. MCP handles access, skills handle context and best practices. RAG grounds responses in actual information instead of hallucinations. Agents orchestrate actions.
They all work in the same workflow. An agent uses MCP to access a tool, follows a skill for project-specific instructions, and retrieves relevant context through RAG. Treating these as competing choices misses how people actually build with AI.
The same pattern shows up in code quality. Modern models have seen countless frameworks, patterns, and conventions. If a model struggles with your codebase, there’s a decent chance a new teammate will too. Clear structure helps. Consistent naming helps. Readable tests and current documentation help. Those things make codebases easier for agents to understand, but more importantly, easier for people to review, debug, and maintain.
Building Evidence Instead of Taking Sides
AI conversations will keep producing strong opinions because the tools are changing fast and we’re all still figuring out workflows. Instead of picking permanent sides in every debate, test the ideas. Build something. Document what happened.
Projects like Pollinations AI experiment with generative platforms where contributors earn credits by improving projects. Others like Avian Visitors combine microphones, Raspberry Pis, e-ink screens, and generated images into something real. These projects don’t settle every AI debate. They create evidence, expose tradeoffs, and give other people a place to start.
Read enough code to own the result. Build enough AI fluency to explain how you work. Use standards when they help reliable interactions. Use skills when context matters. Keep retrieval-augmented generation when grounded information improves the system. Treat codebases that confuse both people and models as maintainability problems.
The best take isn’t the one that wins arguments, it’s the one that makes you ask better questions about what you actually build.