The most dangerous words in software engineering aren’t “this is broken.”

They’re “this can never happen.”

For 27 years, a subtle flaw sat quietly inside OpenBSD’s TCP code. The developers assumed a certain condition was mathematically impossible, so they never protected against it. Then Claude Mythos came along and proved them wrong.

Think of Mythos like Sheldon Cooper from The Big Bang Theory.

Sheldon looks at normal human behavior and points out the things that don’t actually make sense — the social rules and assumptions everyone else just accepts without questioning. Mythos does the exact same thing with code. It doesn’t get tired. It doesn’t shrug and say “yeah, that’s probably fine.” It follows pure logic, even when the conclusion feels ridiculous.

Where most of us might glance at a piece of code and think, “nobody would ever do that,” Mythos asks a different question: “But what if they did?” And then it finds a way.

That’s what happened with the 27-year-old bug. Humans assumed one number could never be in two contradictory places at the same time. Mythos didn’t accept that assumption. It found the mathematical trick (signed integer overflow) that made the “impossible” condition possible.

This is more than just an interesting technical story. It’s a warning.

If an AI can find a bug that sat undetected for nearly three decades in one of the most carefully reviewed codebases in the world, what else is hiding in the systems we rely on every day? The real risk isn’t only the bugs we already know about. It’s the ones sitting behind assumptions we’ve never seriously challenged.

That’s why this matters for every software team, not just cybersecurity engineers.

Attackers who gain access to similar capabilities will be able to find these kinds of flaws faster than most traditional security processes can respond. The old model of “it’s been stable for years, so it’s probably fine” is becoming a liability.

This is forcing us to change how we work:

  • We’re using AI-powered analysis as a regular part of our development and review process — not just as an occasional experiment
  • We’re deliberately going back and examining older, “trusted” code paths that we previously considered low risk
  • We’re training ourselves to actively question every “this can never happen” assumption instead of accepting it by default
None of this is about panic. It’s about updating our instincts.

The teams that learn to question their own assumptions more aggressively will be better prepared for what’s coming. The ones that keep relying on “it’s always worked this way” will eventually get surprised.

The age of trusting that “if it hasn’t been found yet, it’s probably secure” is ending.

Curious — how are you and your teams starting to think about this?