Why Comprehensibility Is About to Become a Security Property — And What to Do About It Now
Security failures live in the gap between what code is supposed to do and what it actually permits. AI is closing that gap
Comprehensibility Is a Security Property Now
NateBJones made a claim recently that I think deserves more attention than it’s getting: “Comprehensibility is about to become a security property.” Not a nice-to-have. Not a code quality metric. A security property — in the same category as memory safety or input validation. The argument is built around the meaning layer vs implementation layer gap, and once you see it, you can’t unsee it.
The specific trigger was Mozilla’s blog post “Zero Days Are Numbered.” Anthropic gave Mozilla early access to Claude Mythos, pointed it at Firefox, and the result was 271 vulnerabilities identified in a single release cycle — Firefox v150. For context, a previous collaboration with Claude Opus 4.6 found 22 security-sensitive bugs in Firefox v148, 14 of them high severity. Mythos found more than twelve times as many. In one cycle.
Firefox is not a toy codebase. It’s one of the most security-hardened open-source projects in existence — dedicated fuzzing infrastructure, sandboxing, memory safety work, internal security teams, bug bounty programs, years of accumulated paranoia. If Mythos can surface 271 vulnerabilities there, the question isn’t “is this impressive?” The question is: what does this mean for how we think about code quality?
The Gap That Attackers Have Always Lived In
One coffee. One working app.
You bring the idea. Remy manages the project.
Here’s the core idea, stated plainly. Code has two layers. There’s what it means — the intent the author had, the semantic structure, the promises the API makes, the behavior the tests describe. And there’s what it permits — the actual execution paths, the edge cases, the parser disagreements, the implicit assumptions that turn out to be wrong.
Security failures live in the gap between those two layers.
The author writes a parser that accepts one format. The implementation, under adversarial conditions, allows two parsers to disagree — and the attack lives in the space between what they agree on. The author meant X. The code allows Y. The attacker finds Y.
This is not a new observation. But what’s new is who can find Y at scale.
Human security researchers have always been adversarial readers of code. They ask: what does this code allow, regardless of what the author thought they wrote? That’s the whole craft. Vulnerability research is adversarial interpretation. You read the code like an essay and look for the interpretation the author didn’t intend but the implementation permits.
What Mythos appears to do — and what Google’s Project Naptime and Big Sleep, and OpenAI’s Codex Security are all converging on — is automate that adversarial reading at machine scale. The Mythos research loop, as described by Mozilla, is: read code → form hypothesis → use tools → generate test cases → reproduce issue → refine → explain. That’s not a static analysis pass. That’s the research loop of a senior security engineer, running in parallel across the entire codebase.
DARPA’s AI Cyber Challenge tested autonomous systems finding and patching vulnerabilities across large codebases. OpenAI’s Codex Security is explicitly built around: understand the codebase, build a threat model, validate issues in a sandbox, propose patches for human review. The shape is consistent across all of them. These systems are learning to interrogate code, not just write it.
Why Legibility Is Now Load-Bearing
Here’s where the argument gets interesting, and where I think most people are missing the implication.
If AI systems are becoming the primary mechanism for adversarial code review, then the quality of that review is bounded by how well the system can reason over your code. And reasoning over code is much easier when the code is legible.
Narrow modules are easier to constrain. Explicit API boundaries are easier to test. Small interfaces are easier to verify. Clear specifications give the model something it can satisfy. Good tests give the model feedback loops. Technical debt, in this framing, becomes security debt — not metaphorically, but directly. Messy code may be structurally resistant to the AI tools that could make it safer.
This is the claim that I find most important: illegible code doesn’t just slow down human reviewers. It degrades the quality of AI security review. A system that humans cannot understand is going to be harder for an AI researcher to understand as well. The meaning layer collapses. The model can’t form good hypotheses about what the code is supposed to do, so it can’t reliably find the gap between intent and implementation.
Hire a contractor. Not another power tool.
Cursor, Bolt, Lovable, v0 are tools. You still run the project.
With Remy, the project runs itself.
This creates a feedback loop that runs in the wrong direction if you let it. AI makes it cheap to produce code. Cheap code production means more code, faster. More code faster means more accumulated complexity. More complexity means less legibility. Less legibility means worse AI security review. Worse security review means more vulnerabilities in the code that AI just made cheap to produce.
The way out of that loop is treating comprehensibility as a first-class engineering constraint — not because humans like readable code (though they do), but because readable code is what makes adversarial machine-scale scrutiny possible.
What’s Actually Buried in the Mythos Story
The non-obvious detail here isn’t the vulnerability count. It’s the eval recommendation that comes out of this analysis.
Most agentic pipeline evals today are roughly 80% functional correctness and maybe 20% code hygiene or architecture. That ratio is backwards for security purposes. The recommendation is that at least 50% of your agentic pipeline evals should cover code hygiene and architecture — not just “does it work?” but “is it legible enough to be defended?”
This means things like: maximum lines per function, dependency handling standards, which language expressions you’ll tolerate and which you won’t (every language has idioms that are notoriously unreliable for security researchers), module boundary clarity, interface surface area. These aren’t aesthetic preferences. They’re the conditions under which adversarial review — human or machine — can actually work.
The practical implication is that when you’re writing evals for your agentic pipelines, you’re not just writing tests for correctness. You’re writing tests for interpretability. You’re asking: can a security researcher — human or AI — read this code and form accurate hypotheses about what it allows?
This connects directly to how specs get written. The recommendation is blunt: write better specs. Specificity is the enemy of technical and security debt. A good file for code has a verb that goes with it — it does a thing. If you can’t state clearly what a module is supposed to do, you can’t write a good eval for it, and you can’t expect adversarial review to reliably find the gap between intent and implementation. Tools like Remy take this seriously at the architecture level — you write your application as an annotated spec, and the full-stack code is compiled from it, keeping the source of truth in the meaning layer rather than buried in implementation details.
The Meaning Layer Is Where Humans Are Going
There’s a version of this story that’s just “AI is better at security than humans now, engineers are obsolete.” That version is wrong, and it’s worth being precise about why.
What Mythos is good at is exhaustively searching the consequences of code. Given a codebase, it can find the gap between what the code means and what the code permits, at a scale and speed that humans can’t match. That’s the implementation layer — what the code actually does.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
What Mythos cannot do is decide what the code should mean. It can’t decide what promises a system should make to its users. It can’t decide what failures are morally acceptable. It can’t decide what authority a user should have. It can’t hold the product intent in its head and notice when a tiny architectural decision creates a security problem three layers down. It can’t understand the organizational context that makes one tradeoff right and another wrong.
That’s the meaning layer. And that’s where human judgment is going — not disappearing, but concentrating.
The valuable engineer in this world is the person who can turn product intent into crisp specifications within the code hygiene practices of the business. Who can decompose a system into verifiable boundaries. Who can design APIs that minimize authority leakage. Who notices when a system is becoming illegible and understands why that matters. This is actually closer to what senior engineering was always supposed to be — the more experienced an engineer becomes, the less their value comes from typing every line, and the more it comes from defining the abstractions and noticing the hidden couplings.
AI doesn’t make that ability disappear. It just changes where you apply it.
What to Do Before This Becomes Standard
The timeline matters here. The prediction is that open-source models will reach Mythos-like security capability by end of 2026. There’s already evidence that GPT-5.5 shows some of the same security-sniffing attributes as Mythos, though without the same side-by-side case study on security. The argument is that we have roughly a 4-5 month window — a “golden refactor window” — before AI security tools become standard infrastructure.
After that window closes, messy illegible code doesn’t just have the problems it always had. It becomes structurally resistant to the tools that could make it safer. The cost of fixing that compounds.
So what do you actually do right now?
First, audit your eval coverage. If your agentic pipeline evals are mostly functional correctness, shift toward 50% code hygiene and architecture. Write evals that enforce legibility constraints — function length, interface surface area, dependency handling, module boundaries. These evals serve double duty: they make human review easier today, and they make AI security review easier in six months.
Second, invest in specs. Not as documentation that trails implementation, but as the source of truth that precedes it. If you can’t write a clear spec for what a module is supposed to do, that’s a signal that the module’s meaning layer is underspecified — which means the gap between intent and implementation is wide, which means it’s a security surface. Understanding how AI agents work at the level Mythos operates helps clarify what “clear spec” actually means in practice.
Third, think about modularity in your pipeline. If you have a principal engineer reviewing code today, make that role modular. The review function — adversarial interpretation of code against the spec — is the thing that Mythos-like systems will take over. Build your pipeline so that function can be swapped. The human role doesn’t disappear; it moves to reviewing what the AI security system found and deciding whether the overall meaning of the software matches the product intent.
Day one: idea. Day one: app.
Not a sprint plan. Not a quarterly OKR. A finished product by end of day.
Fourth, start applying adversarial review to what you have. The 271 vulnerabilities in Firefox v150 didn’t appear because Firefox got worse. They were always there. The question is whether you find them before an attacker does. If you have access to capable models today — and understanding what Claude can do for AI agents is a reasonable starting point — you can start running adversarial review on existing code now, not waiting for Mythos-equivalent capability to be universally available.
For teams building agentic workflows, platforms like MindStudio make it practical to chain models together for this kind of multi-step review — you can compose a pipeline that reads code, builds a threat model, generates test cases, and surfaces findings without writing the orchestration infrastructure from scratch.
The Trust Model Is Already Shifting
The deeper implication of the Mythos story is about what we trust and why.
We’ve always trusted human-written code because human judgment was the only thing capable of producing and understanding software at the correct level of abstraction. The engineer wrote the implementation, imagined the edge cases, reviewed the diff, carried the system in their head. Tools helped, but the core act was a human craft.
That’s changing. Not because humans are getting worse at writing code, but because machines are getting better at adversarially reading it. And once machines can exhaustively search the consequences of code better than humans can, human authorship stops being the trust anchor. It becomes one more source of unverified risk.
The new trust anchor isn’t “a good engineer wrote this.” It’s “this implementation survived adversarial machine-scale scrutiny.” That’s a different claim, and it requires a different kind of evidence — not a code review sign-off, but a verified process with documented findings.
We’ve been through versions of this before. We stopped trusting developers to casually write cryptography. We stopped trusting manual memory management in large classes of software once safer alternatives became practical. We stopped trusting handrun production deploys without automation and rollback and observability. In each case, human skill didn’t disappear — human execution lost the presumption of safety. The responsible human role moved to a higher level of abstraction.
Code itself may be next. Not all code, not tomorrow, not in the sense that programmers vanish. But the default assumption that human authorship implies safety is eroding. The question is whether you’re building your engineering culture to handle that erosion gracefully, or whether you’re going to be surprised by it.
The WAT framework for structuring agentic projects — Workflows, Agents, and Tools — is one way to think about how to decompose the problem so that the security review function is explicit and modular rather than implicit and fragile. The goal is a pipeline where the meaning layer is owned by humans, the implementation layer is verified by machines, and the evidence of that verification is something a senior engineer can inspect and certify.
That’s the world we’re building toward. The cost of implementation is going to zero. The cost of confidence in implementation is not. Start building for the second one.
