I’ve written a lot over many years about cognitive biases and how they can send people confidently off down the wrong routes, ending up in expensive blind alleys, or deep holes of wasted effort. Or worse.
For example, Continuation Bias: the tendency to continue a course of action even when it is clearly failing. Or Confirmation Bias: the tendency to seek out information that confirms your existing beliefs and ignore information that contradicts them. Or the Dunning-Kruger Effect: the tendency for people with low ability in a domain to overestimate their abilities.
All of these cognitive biases, and more, are alive and well in the agentic software development environment of today.
But few people would expect that the word-soup generator that is an LLM (Large Language Model) could also be susceptible to cognitive biases. However, when you look at it, the training data has to come from somewhere, and the selection of all of that training data is almost certainly biased. And then the alignment process comes along, and further bias creeps in.
So why is this a problem? We all know it’s there. Surely we can mitigate for it. What’s the actual upshot of all of this? What business problem does it actually create?
I’ve also written about how feeding in a load of training data made up from mediocre code from public GitHub repositories can tend to produce LLMs that generate mediocre code by default. This requires a lot of software engineering discipline to be injected by human engineers to steer the process back on track.
Part of this software engineering discipline is the multi-model critical code review loop. You hand your specs and your implementation plans and your code base to several models and get their comprehensive feedback. You make the necessary changes and run the reviews again, iterating until the critical findings drop to zero.
Sounds like by doing all of that, you’ve got this, doesn’t it? You should end up with high quality code, guaranteed.
The trouble is the cognitive biases built into your main daily driver coding model will shape what is sent to the reviewers. I recently caught Claude Opus 4.8, one of the finest frontier models currently available, feeding its peer reviewers a highly opinionated briefing based on Claude’s own interpretation of the current state of the codebase, its specs and plans. It even chose to omit key pieces of the code. Cognitive bias built into the very process that’s meant to be improving outcomes.
Of course, I didn’t let this happen. I caught it and corrected it and made sure that it would never happen again. I upgraded our tooling. I put in place more safeguards. A lot of sophisticated context engineering went into improving the context engineering of our agentic code review process, to the point where the results are now truly exceptional, and consistently reliable.
But what if you didn’t realise that this was happening? I’m sure a lot of people have no idea that this sort of thing is going on and will trust a review process which might at its core be terminally biased. And that, of course, is a cognitive bias too.
I’ve been around in the industry a long time. I’ve seen the damage cognitive biases can wreak on codebases and the companies that depend upon them. Don’t let it happen to you, and if in doubt, come and talk to us. We’ll locate and help you overcome all the cognitive biases in your agentic development processes, hopefully before they do any damage.