Dunning-Kruger in the age of AI

I was lucky enough to take a 2 month sabbatical recently. I spent much of it skiing in the French Alps. But intense ski days often give rise to peaceful afternoons by a fire. It was during these afternoons that I found myself tinkering with the latest AI coding tools - Codex, Cursor, Amp - building personal projects.

The tools have indeed got dramatically better. If you haven’t been following closely, models crossed a threshold in November 2025 in which output went from mostly wrong to mostly right (at least in terms of working code). Combine these strong models with increasingly capable harnesses for giving them access to tools, and you get something that feels like magic. Agents reading product specs from Linear and raising a PR in GitHub when done, with minimal intervention.

But this is not another puff piece for Opus 4.6 4.7. There are enough of those already!

You don’t know what you don’t know

This advance in model capability has shifted the onus of building a working app from knowing the answers yourself to knowing the right questions to ask. And as a non-engineer, I’m fooling myself if I think I know the right questions. I can’t interrogate security, scalability, reliability or maintainability. I can’t assess if code is written logically and can be added to easily. I can’t confidently work out if my personal app could serve real customers at scale without falling over.

I’m not the first to write about the Dunning-Kruger effect in the context of AI, but I think it’s a message that bears repeating. Especially with breathless warnings that “software engineers could go extinct” from those who should probably know better.

By Diego Moya - - File:Dunning–Kruger_Effect.svg, CC BY-SA 4.0, Link

People tend to focus on the left-hand side of the graph - the part that shows those with low skills in a domain overestimating their abilities. But the other side of the coin applies here too. I’ve spent time since returning to work speaking to extremely talented engineers, listening to them explain real-world nuance; how AI helps sometimes, and other times writes code that works but ignores conventions, uses obtuse logic or otherwise creates headaches for future maintainers.

As product people, therefore, we should be challenging our engineering leaders on how they are ensuring the bar is kept high for code quality even as Claude Code adoption rises.

To be a 1x engineer or a 10x PM

An open debate in the product world right now is whether product managers and designers should use AI coding tools to ship to production. As usual, the complete answer is nuanced and depends on size of company, scarcity of engineers and complexity of feature.

But generally, it is hard to argue with my former Monzo colleague (now VP Engineering & Data at Zego) Markos Mylonakis or, indeed, Anthropic’s Head of Growth Amol Avasare: empowering engineers to do their job better seems preferable to empowering PMs to do an engineering job poorly. Plus, if you are successful at doing that, there is going to be a whole lot more PM work. All those extra products & features still need to find product-market fit, meet regulations and have a viable business case.

Prototyping is a different story. There is huge upside to PMs using a working prototype to have better discussions with cross-functional partners. It cuts later iteration cycles to be able to experience the feel of a prototype on your device rather than looking at static screens, with all the second-order interactions that entails. I already see us making better product decisions at Monzo thanks to prototypes.

Overall, though, I struggle to see the “builder PM” archetype becoming the dominant flavour of product manager in tech companies beyond Series A. The reports of the death of software engineering are greatly exaggerated.

Hyper-personal apps, but not the SaaS-pocalypse

There is a category of software where the Dunning-Kruger gap doesn’t matter so much: low-stakes tools for personal or small group use. Oliver Roeder at the FT wrote a great column recently about vibe-coding “by some distance the best word processor I have ever used”. He noted that “given its extensive tailoring, it is possible that it would fit no one in the world except for me.”

This is a real opportunity with current model capabilities. For example, I built myself a kitchen planner during my sabbatical: a library of my favourite recipes with import capabilities, a meal plan for the week ahead, and a shopping list generated off the back of that. It might well have value beyond me, but other people would want it to work differently, spawning feature requests and bloat that would undermine my own use case. So I built my own.

The stakes couldn’t be lower. The allowlist has two users. If there’s a security vulnerability, the blast radius is my weekly meal plan. While the efficiency is questionable here - I spent time on it just as much to learn by doing as for the end result - it’s an example of real value from AI coding. In enterprise terms, this could look like a new class of micro apps for automating tiresome processes. Perhaps the optimal solution would be a brand new implementation, but the home-spun solution can deliver real benefits in a pinch.

This doesn’t mean that SaaS is dead. There was a noticeable market panic - the SaaS-pocalypse - in February 2026 as investors worried that the build vs. buy calculus had shifted so far that enterprises would simply replace their SaaS spend with AI agents. Hello again, Dunning-Kruger!

At scale, enterprises are simply too risk-averse and security-conscious to see a vibe-coded CRM as a genuine replacement for Salesforce. Competent CTOs are aware that the alluring functionality of a replacement thrown together in days hides the substantial maintenance burden that they currently pay their SaaS partners to shoulder. At the margin, and at smaller scale, there will be more pressure on some categories of SaaS to justify their value. But the industry is far from dead.

Another polarised discourse for our divided world

If you follow the AI conversation at all, you’ll have noticed the extreme ends of it. Venture capitalists breathlessly predict the obsolescence of entire professions. Sceptics dismiss every advance as hype. There is very little middle ground.

I think this polarisation is driven less by factual disagreement than by how emotive the implications are. This is a technology that is simultaneously:

• Overhyped egregiously by those with incentives to sell
• Magical in a way that would have seemed like Sci-Fi 5 years ago
• Genuinely threatening to displace or unalterably change entire classes of profession
• Meaningfully flawed in potentially important ways
• Existentially uncertain to an unknowable extent

It is more important to understand the emotional side of the debate than to treat it as a simple matter of factual consideration, to be solved by increasing energy efficiency or reducing hallucination rates. It’s vital to speak to people in your teams and engage in nuance.

What this means for product leaders

AI coding tools are real and getting better fast. This blog post will be outdated by next month. But the opportunity is more nuanced than the prevailing narrative suggests. You should:

• Update your understanding regularly. If you tried these tools a year ago and walked away unimpressed, try again. If you’re not an engineer, be humble about what you can and can’t evaluate.
• Consider whether your org really needs more people writing code. In most environments, helping engineers to work more effectively with AI will be higher leverage than encouraging non-engineers to write production code.
• Encourage PMs to prototype. Give people the space to replace the long written artifact with an interactive demo. If there are no good options onboarded, maybe try to find a tool you can get your CTO to buy in to (there are plenty).
• Embrace the hyper-personal. Look for opportunities to build bespoke apps for specific workflows, now that the cost of doing so has dropped. Be critical about whether security, scalability and maintainability are important to the use case or not.
• Remain sceptical of sweeping narratives. The SaaS-pocalypse, the death of engineering, the displacement of entire professions: these make for compelling LinkedIn posts, but poor strategy.
• Take the emotional dimension seriously. Don’t assume everyone around you shares your views about this technology. If you’re bullish, take the time to understand why people are concerned - don’t dismiss them as Luddites. If you’re bearish, interrogate the “why” behind that - creating false dichotomies like “it can’t one-shot this new feature, so it’s useless” undermines your well-founded misgivings.