Two feelings show up constantly in technical work, and they point in opposite directions. The first is the small buzz of 'this is clever.' The second is the cold prickle of 'I'm not sure.'
They feel like the same kind of thing, internal states with a confident emotional charge. But one is usually a false positive and the other is usually a true negative. Cleverness is a signal to invert. Doubt is a signal to obey. Telling them apart is most of the discipline.
Ease Feels Like Truth
There's a well-replicated finding in cognitive psychology called the fluency-truth effect: when a statement is easier to process, people are more likely to judge it true. The manipulations that produce this are almost insulting in how superficial they are. Higher colour contrast. A cleaner font. Rhyme. Repetition. None of them touch whether the claim is correct, and all of them move the needle on whether you believe it.
Fluency isn't a stupid heuristic. In ordinary environments, true things genuinely are encountered more often and explained more coherently, so ease carries real predictive value. That's exactly what makes it dangerous. It's a generally reliable signal that fails hardest in situations engineered to be fluent without being correct, polished prose, confident delivery, well-formatted code.
Fluency Sets the Brake on How Much You Verify
The effect doesn't stop at what you believe. It controls how much thinking you do next.
Valerie Thompson's work names the mechanism the Feeling of Rightness. When an answer surfaces, it arrives bundled with a sense of how right it is — and that sense is generated largely by how fluently the answer came to mind, not by any checking. A strong Feeling of Rightness tells you to stop and move on. A weak one flags that something deserves a second look.
So the thing deciding whether you verify is a feeling about how smoothly the answer arrived. Nothing in that loop measures whether it's correct.
Why Cleverness Inverts
Software folklore got here decades before the psychology had a vocabulary for it. Kernighan's line: debugging is twice as hard as writing the code in the first place, so if you write it as cleverly as you possibly can, you have, by construction, written something you aren't sharp enough to debug.
Read through the fluency loop, that stops being a moral warning and becomes mechanical. The pleasure of cleverness fires on intricacy — novelty, density, a trick only you can currently see. But intricacy is precisely what lowers fluency for the next reader, including you in six months.
One distinction is worth holding onto. Clever-intricate is "only I can see how this works." Elegant-simple is "now anyone can see how this works." The diagnostic question is why it feels good. If the honest answer is "because it's subtle," that's the invert-me signal. If it's "because it made a hard thing obvious," that's a different and more trustworthy pleasure.
Why Doubt Is Honest
Doubt is the mirror image, and it's the more truthful of the two. Where cleverness is confidence you haven't earned, doubt is an accurate report that you're running on claims you can't presently vouch for. What the docs say. What you assume the function does. What was true last release.
The feeling is right. Where people go wrong is in how they discharge it. Doubt resolved by reassuring yourself — rereading your own code until it looks fine — is doubt ignored with extra steps. Doubt resolved by checking — running it, printing the value, opening the source, writing the failing test — is doubt working as designed.
Rozenblit and Keil showed that people believe they understand how everyday things work in far more detail than they do, and the illusion collapses the moment they try to explain step by step. Doubt is the early warning for the gap between "I get this code" and "I could predict what this line returns."
Where AI Raises the Stakes
An Ai coding assistant doesn't introduce a new failure mode. It industrialises the existing one.
Consider what the model optimises for: fluent, confident, well-structured output. Those are precisely the surface properties that manufacture a high Feeling of Rightness — not in the model, in you. A clean, plausible, well-commented diff trips your this-looks-right response by proxy. The polish is real. The correctness is a separate question the polish cannot answer.
The evidence lines up. In a controlled study, developers with access to an AI assistant wrote less secure code than those without — and were more likely to believe their code was secure. Confidence up, quality down.
The model produces claims. It cannot produce evidence about your system, because it never ran against your system. The evidence loop is the part only you can close, and the feeling that tempts you to skip it is exactly the false positive the model is unusually good at inducing.
This sharpens with agentic loops. Once a system reads state, writes state, and consumes its own output on the next iteration, its correctness depends entirely on what it reads. Point the loop at its own prior output and you have built an efficient machine for generating self-consistent, confident error. Point it at ground truth — run the test and read the actual failure, open the real file, hit the live API — and the same architecture converges toward correct.
What to Do About It
Don't act on the feeling. Act on what the feeling is pointing at.
- Pleased with how clever it is → simplify until it's boring
-
"This is obviously right" → find the one edge case that would prove it wrong, and run that
-
A clean AI diff you want to just accept → read it, run it, trace the actual output
-
Doubt you keep talking yourself out of → convert one claim into evidence
-
"I basically understand this" → try explaining it line by line; the gaps are where the bugs are
One caveat, because obeying doubt costs something. Not every claim is worth converting. Spend verification where how likely you are to be wrong times how much being wrong would cost is high, and let genuinely low-stakes claims ride. A governor that fires on everything is its own failure mode.
Fluency is the feeling of a claim. Friction is the feeling of evidence. Friction is the one to trust, because evidence is supposed to cost something.
Go check.
The longer version, with the research, the four-quadrant map of confidence against grounding, and the full mapping between human cognitive biases and documented agent failure modes, is here.
If your team is building or working alongside AI systems and wants to get this right, we'd love to talk. Praecipio helps organizations design AI implementations that amplify the people behind the work.
Aaron Bockelie is Head of AI Engineering and Research at Praecipio.
