The harness, not the model
In short: Mozilla's earlier attempts at AI bug-hunting used GPT-4 and Sonnet 3.5 in read-only mode and drowned in false positives. The April 2026 result came from letting the model write and run its own test cases against AddressSanitizer — a judge that cannot be argued with. The gain came from the verification loop, not the model, and it still took over a hundred people to absorb the output. Whether this transfers to your company depends on one question: does your work have an equivalent of that judge, and if not, can you build one?
In April 2026 Mozilla shipped 423 security fixes for Firefox in a single month. Through the whole of 2025 the figure had run between twenty and thirty a month. It was sixty-odd in February 2026, seventy-odd in March, and then the graph goes vertical.
Mozilla's own write-up attributes 271 of those 423 to an agentic pipeline built around Anthropic's Claude Mythos Preview: 180 rated sec-high, 80 sec-moderate, 11 sec-low. The remainder came in the ordinary way — 41 reported externally, 111 found internally by other means.
Among the findings were a twenty-year-old bug in XSLT and a fifteen-year-old
flaw in the <legend> element. This is a codebase that has been read by
thousands of skilled engineers, fuzzed continuously for over a decade, and
audited by an industry of security researchers with money on the line.
That is the headline, and the headline invites the wrong conclusion.
Mozilla had already tried this, and it had already failed
The part worth your attention is buried in the middle of the engineering post. Mozilla ran earlier experiments using GPT-4 and Claude Sonnet 3.5 to look for the same class of bug. Those experiments showed promise and were abandoned: in Mozilla's words, the high rate of false positives made them impractical to scale. Static analysis alone, without dynamic testing, was not enough.
So the same organisation, the same codebase, the same ambition, capable models — and no result.
What changed in 2026 was not only that the model got better at reading code. It was that the model was allowed to check its own work. The new pipeline gives it the interfaces to create and run reproducible test cases, built on top of the fuzzing infrastructure Firefox already had, parallelised across ephemeral VMs. A candidate bug either triggers AddressSanitizer or it does not.
That is the whole mechanism. A model that asserts produces work for humans. A model that can test its own assertion produces findings.
It still took more than a hundred people
Mozilla is direct about this, and it deserves quoting rather than paraphrasing: over 100 people contributed to shipping that release — writing and reviewing patches, building and scaling the pipeline, triaging, testing the fixes and managing the release process for each bug.
The pipeline generated leads at a rate no human team could match. Absorbing those leads still required a large, competent, well-organised engineering organisation. Nothing here suggests a security team was replaced. What happened is that a bottleneck moved: from finding candidate flaws to processing them.
The second piece of evidence points the same way
There is a much larger dataset saying something structurally identical. Anthropic's Economic Index report of June 2026 compares how people work across different surfaces — chat on one side, the agentic Claude Code on the other.
The behaviour is not remotely alike. The median session that produced a blog post took one prompt in Claude Code and thirteen rounds in chat. And the finding that matters for anyone choosing a tool: even when you control for the model being used, the agentic surface shows measurably more delegation — 0.26 additional autonomy points on a five-point scale. Claude Code runs Opus 54% of the time against 10% for chat, but the gap survives comparing like with like.
Read that next to Firefox and you get the same sentence twice, from completely different evidence: how the work is wired up moves the outcome more than which model sits in the middle of it. One is a case study of a hundred engineers; the other is a pattern across millions of sessions.
The condition that decides whether this transfers to you
Here is the caveat that most write-ups of the Firefox result leave out, and it is the one that determines whether any of this applies to your company.
Vulnerability discovery is an unusually lucky domain. It comes with a free, automatic, incorruptible referee. A memory-safety bug either crashes under a sanitiser or it does not. That means a machine can fire thousands of hypotheses at the wall and have virtually all of them discarded without a human ever reading them. The cost of a wrong guess rounds to zero.
Almost no business process works like that. A mis-coded invoice does not crash. A contract clause with the wrong indemnity cap does not segfault. A support reply that quietly promises something you do not offer passes every automated check you have.
What to do with this on Monday
Look for work that already has a referee. Reconciliations where two systems must agree. Anything with a schema, a checksum, a validation rule or a test suite. Data entry where a downstream system rejects what is malformed. This work is unglamorous and it is where the transferable version of the Firefox result lives.
If there is no referee, building one is the project. Not the model selection, not the tool licence. Writing down what "correct" means for one process, in a form a machine can check, is the piece of work that everything else depends on — and it is the piece almost every stalled pilot skipped.
Budget for the humans who absorb the output. Mozilla needed a hundred people to consume what one pipeline produced. Scale that thought down honestly to your own team before you promise anyone a throughput number.
Record the before, this month. Do not substitute how it feels. When METR measured experienced developers in 2025 they came out 19% slower and believed they had been 20% faster — a 39-point gap, in expert, motivated people. And the comparison is expiring: when METR went back with newer tools they had to abandon the question, because developers would no longer work without the tools even at $50 an hour. Whatever your baseline is, it is easier to capture today than it will be in six months.
The honest summary
The Firefox number is real, it is verified by Mozilla's own engineers, and it is one of the most striking results published so far. It is also not evidence that buying a better model will do anything for you.
What produced it was a domain with an automatic definition of correctness, a harness that let the model test itself against that definition, infrastructure that already existed, and a hundred people ready to act on the output. Take away any one of those four and you get Mozilla's earlier attempt: promising, noisy, abandoned.
The returns are still not in the model. They are in what you build around it.
Frequently asked questions
What actually changed in AI between 2025 and 2026?
The clearest single change is that models were given the ability to test their own claims rather than only assert them. Mozilla had tried AI bug-hunting before with GPT-4 and Claude Sonnet 3.5 in read-only mode and abandoned it because the false-positive rate made it impossible to scale. The April 2026 pipeline let the model build and run reproducible test cases on Firefox's existing fuzzing infrastructure, so every reported bug either crashed under AddressSanitizer or was discarded automatically.
Did AI replace Mozilla's security team?
No, and Mozilla is explicit about this. More than a hundred people contributed to the effort — writing and reviewing patches, building and scaling the pipeline, triaging findings, testing fixes and managing the release process. The pipeline produced leads at a rate no human team could match; consuming those leads still took a large organisation.
Does the 2025 research showing developers got slower still apply?
Its headline number does not describe today's tools, and it never claimed to. The durable finding is different and still holds: the participants were 19% slower and believed they had been 20% faster, which means self-reported productivity is not evidence of anything. In February 2026 the same researchers reported they could no longer assemble a control group at all, because developers refused to work without the tools.
Why did this work for security bugs specifically?
Because vulnerability discovery comes with a free, automatic and incorruptible referee. A memory-safety bug either crashes under a sanitiser or it does not, so a machine can generate thousands of hypotheses and have almost all of them thrown out without a person reading them. Most business processes have no equivalent. A mis-coded invoice does not crash.
How do I know whether my process can be automated this way?
Ask what plays the role of the sanitiser. If a second system must agree, if there is a schema, a reconciliation, a checksum or a test suite, you already have a referee and you are closer than you think. If correctness is only ever established by a person reading the output, building that referee is the project — not the model selection.
About the author
Filip has spent his career between media and technology — filming for ŠKODA, Pilsner Urquell and Range Rover, then co-founding a startup in San Francisco, working with a YC-backed company and serving as CIO at Renato. He built ZEUS Legal AI and now runs the systems Salamon Capital operates on.