You're not as smart as you think you are

Nobody sets out to ship a SQL injection. Nobody opens their editor thinking "today I'll hardcode a secret." It happens because, in the moment, you were sure the code was fine. You wrote it. You understood it. Why would you need a tool to double-check your own thinking?

That confidence is the problem. Not your skill - your certainty about your skill, at the exact moment you have the least perspective on it: right after you wrote the code, while you still remember why every line seemed like a good idea.

The Dunning-Kruger effect isn't about other people

Everyone's heard of Dunning-Kruger. Everyone assumes it's about the junior dev who doesn't know what they don't know.

It's more uncomfortable than that.

The effect doesn't disappear with experience. It just changes costume. Seniority swaps "I don't know enough to be wrong" for "I know enough that I couldn't be wrong" - and the second version is sneakier, because it doesn't feel like a blind spot. It feels like expertise.

Ten years in doesn't make you immune to writing a regex with catastrophic backtracking, or concatenating a query string because the PR is due in twenty minutes and the parameterised version means touching three files. It just makes you more confident while you do it.

Self-review is a rigged game

Ask any engineer to review their own PR and they'll find the typo, the unused import, the missing semicolon. Ask them to find the security smell they didn't know was a security smell, and they can't. Not because they're careless, but because you cannot spot a blind spot from inside it. That's literally what makes it a blind spot.

This is why code review exists. But code review has the same failure mode one layer up: a reviewer skimming a 400-line diff at 5pm isn't auditing for danger. They're pattern-matching against what looks familiar. "LGTM" is a confidence statement, not a verification step.

Everyone in the chain is doing their best thinking under time pressure. And best thinking under time pressure is exactly when overconfidence does the most damage.

"It's fine, I just wrote it" is not a security control

There's a specific flavour of certainty that hits right after you finish a function. You just held the whole thing in your head, so it feels correct. That feeling has nothing to do with whether it is correct. It's proximity bias, not accuracy. The bug that ships is very often in the file you were most recently, most confidently, done with.

Static analysis doesn't have that problem, because it doesn't have a self. It doesn't remember writing the code. It has no ego invested in the code being fine. It just checks the pattern against the rule, every time, regardless of who wrote it or how sure they were.

Your brain after writing a function: "This is fine."
Iris Code after scanning that same function: "This has three security smells and a hardcoded secret."

Both of you are confident. Only one of you is checking.

Now multiply that by every line you didn't write

Everything above assumes you wrote the code yourself. In 2026, that assumption is increasingly wrong.

Microsoft reports that 30% of code in its repositories is now AI-generated. Google has cited figures as high as 75%. Anthropic says 70-90% of its own code is written by AI. GitHub Copilot's telemetry shows a 46% code share across its entire user base. Whether the true industry number is 25% or 50%, the direction is obvious: a growing chunk of every codebase was never in a human's head to begin with.

Here's why that matters for everything we just talked about.

Veracode tested over 100 LLMs across four languages and found that 45% of AI-generated code introduces OWASP Top 10 vulnerabilities. AI-generated code carried 2.74x more vulnerabilities than human-written code. By mid-2025, AI-generated code was adding over 10,000 new security findings per month across studied repositories - a 10x jump from six months earlier.

And the worst part? The overconfidence problem gets worse, not better. A Stanford user study found that developers using AI assistants wrote significantly less secure code while simultaneously rating their output as more secure. 58% of developers report trusting AI-generated code without testing it. The Dunning-Kruger section above was about the gap between your confidence and your accuracy. AI-generated code widens that gap, because now you're confident about code you didn't even write - you just skimmed it, thought "yeah, that looks right," and hit approve.

The old overconfidence problem was: "I wrote this, so it's fine."
The new one is: "An AI wrote this and it looks fine, so it's definitely fine."

Same blind spot. Less justification. More code.

Your codebase isn't improving just because it feels like it

This one shows up at the team level. Ask a team lead whether code quality improved this quarter and you'll get a confident "yeah, definitely" - because the last few PRs they remember were clean, and recency bias does most of the heavy lifting in a vibe-based assessment.

Whether the average file across the whole workspace actually got healthier is a different question. And it's one that memory is terrible at answering honestly.

This is why trend tracking isn't a nice-to-have. A number that's measured the same way every time - and doesn't care how the quarter felt - is the only way to tell "we got better" from "we got better at forgetting the bad parts."

Iris Code's baseline mode takes this further: it locks in a snapshot of where you are today and only blocks new regressions against it. Existing debt doesn't hold the team hostage, but nothing new gets to hide behind good vibes either. Progress you can see, not progress you assume.

The fix isn't more discipline. It's less trust.

The usual advice is "be more careful." This advice has never once worked, for the same reason "just remember to fix it later" has never once worked. You can't discipline your way out of a blind spot. Discipline still routes through the same confidence that created the blind spot in the first place.

What actually works is removing your judgment from the loop at the one moment it's least reliable: right after you finish writing something and are certain it's fine.

That's not a dig at your ability. It's just how brains work between your eyes and a screen full of code you just authored. Every engineer's brain does this. The fix is structural, not personal.

Detection works best when it doesn't ask your opinion first

Iris Code scores your code on every save - security smells, complexity, secrets, dependency risk - without asking whether you think the file looks fine. It doesn't know how confident you were when you wrote it. It doesn't care. That's the point: the check runs the same way whether you're three minutes into the codebase or three years in.

For teams, the same principle scales: gateMaxSecuritySmells and baseline-mode gates turn "I'm pretty sure this is fine" into a number that either passes or doesn't. Enforced the same way for everyone, on every push, with no exceptions for seniority or good vibes.

You're a good engineer. That was never the question. The question is whether "I'm sure this is fine" is a fact about your code or a feeling about your confidence.

Most of the time, it's the second one. And now something else is checking, so it doesn't have to be you.