The conversation between Asgaut Mjølne Söderbom and Ola Hast lands at a moment when much of the industry is treating AI coding tools as a foregone conclusion. Their experience, distilled in the podcast, is refreshingly contrarian: Claude Code is good for everything else, but not for the actual coding. That distinction matters. It suggests the bottleneck in brownfield codebases is not the mechanical act of writing lines but the human judgment required to navigate inherited complexity. This is not a Luddite stance. It is a practical observation that pair engineering and mob programming still deliver something AI cannot: shared context and collective memory. As we consider how to verify your AI's understanding, the value of these human-centric practices becomes even clearer.
There is a temptation to frame this as a generational clash, but that would miss the point. The engineers are not rejecting AI. They are rejecting the idea that AI replaces the need for the messy, slow, collaborative work that keeps legacy systems alive. Söderbom and Hast have moved past continuous deployment and pair engineering, which tells you they are not afraid of change. Their caution is earned from experience, not fear of the unknown. This aligns with the growing sense that AI/ML job requirements are shifting underfoot, as seen in navigating AI/ML job requirements, where the lines between software engineering and machine learning are blurring. The takeaway is that adaptability remains the core competency, whether you are working with a legacy monolith or a fresh codebase.
What makes this stance interesting is the quiet confidence behind it. The engineers are not claiming AI is useless; they are claiming it is useful in the wrong places. That is a more sophisticated position than the hype cycle usually allows. It echoes the sentiment in talking to my AI clone, where the author questions the technology after direct engagement. The pattern is consistent: those who spend real time with AI tools end up more skeptical, not less. This should give us pause before we hand over the keys to automated code generation. The human edge is not about being faster or more accurate. It is about being able to say no when the tool offers a confident but wrong answer.
The practical implication for teams is straightforward. Do not let the allure of AI-driven velocity push you into abandoning the rituals that built the codebase in the first place. Mob programming is not a relic. It is a defensive mechanism against the creeping opacity that AI introduces. The next time you are tempted to let an AI agent untangle that thorny legacy module, ask yourself who will understand the solution six months from now. The answer, if you rely solely on the machine, is no one. That is the open question we should all be watching: as AI tools get better at producing code, will we get worse at understanding it? The engineers' experience suggests the risk is real. For anyone building on brownfield systems, the most productive investment may not be the latest model but the time spent with your team, working through the problem together.