AI Is Finding Bugs Faster Than Humans Can Triage

There's a specific kind of dread that open source maintainers describe when a security researcher shows up in their issue tracker. Even the legitimate reports require work—reproduction, triage, coordination with downstream users, CVE filing, patch review, release management. It's an enormous amount of unpaid labor for projects that are already running on fumes. Now imagine that pipeline getting fed by an AI that generates a hundred reports to surface two real bugs.

That's not a hypothetical. That's roughly where we are.

A recent video from the Low Level YouTube channel does a clean job explaining why AI has gotten so effective at finding vulnerabilities—and it's worth sitting with the mechanics before jumping to the implications. The creator's argument breaks into three parts: static analysis, pattern recognition, and automation. On their own, none of these are new. Together, at the scale AI enables, they're a different animal.

The Bandwidth Problem

The limiting factor in traditional vulnerability research has always been human reading speed. A researcher working through a large codebase is bounded by how fast they can ingest and contextualize code—loading it into working memory, building a mental model of data flow, tracking where untrusted input touches sensitive operations. It's slow, and the bigger the codebase, the more that limitation bites.

AI doesn't have this constraint in the same way. As the Low Level creator puts it: "You can point your model at like a 400,000 line code base, and it will just boop, yep, I get it." That's not magic—it's just a computer with a lot of VRAM. But the practical effect is that the comprehension phase of vulnerability research, which for humans can take weeks, compresses to minutes.

What happens after that is where it gets interesting. Vulnerability patterns are, at their core, patterns. A memcpy with a user-controlled length parameter and no bounds validation is a buffer overflow waiting to happen. It doesn't matter whether that pattern appears in 50 lines of code or 500,000—the AI that has already ingested the full context can trace data from source to sink across the entire codebase in a way that a human specialist, necessarily siloed into their domain of expertise, structurally cannot.

The Low Level creator makes a point here that I think gets underappreciated: human vulnerability researchers have to choose specialties—IoT, hypervisors, browser sandboxes—not because they lack curiosity, but because the prerequisite knowledge for each domain is enormous. Knowing how V8's internals work well enough to find a sandbox escape is a years-long investment. AI collapses that ramp-up, at least to a functional level. It can pull chipset spec sheets, learn an obscure RTOS startup sequence, and orient itself in an unfamiliar binary in minutes.

This is the capability that Anthropic's own security research team documented this year, reporting hundreds of zero-day vulnerabilities across various targets using LLM-assisted research. That's not a researcher using AI as a fancy grep. That's AI operating as a genuine research accelerant at a scale that human researchers couldn't match.

The False Positive Problem Is an Open Source Governance Problem

Here's where my angle on this diverges from the standard AI capability coverage.

The Low Level creator is honest about the failure mode: AI hallucinates bugs. It reports vulnerabilities with complete confidence in findings that don't hold up to scrutiny. The creator describes trying to use AI to find a known vulnerability in the Linux kernel's SMB handler—and while it did eventually surface real findings, the AI produced somewhere between a hundred and two hundred bug reports alongside them. Most were phantom.

When that pipeline is being run by a well-resourced security team with dedicated triage capacity, a high false positive rate is annoying but manageable. You throw ASan harnesses at the candidates, you instrument the code, you prove or disprove each finding programmatically. The Low Level creator describes exactly this workflow: use AddressSanitizer or QEMU-ASan to build a harness, have the AI write a fuzzer to test its own hypothesis, filter the noise automatically. Expensive in compute, but tractable in labor.

Now think about what happens when these tools get democratized—and they already are. Bug bounty hunters, security students, hobbyists with a Claude API key and a weekend. They point these pipelines at open source projects. The AI generates its hundred candidate reports. Some subset of those get filed as issues or disclosed via email. And they land in the lap of a maintainer who is, with depressing regularity, one exhausted volunteer trying to keep a project they wrote years ago from becoming a liability.

The Linux kernel has a security team. The OpenSSL project has a security team. But the long tail of critical infrastructure in open source—the libraries that quietly get pulled into everything—often doesn't. The question of who triages AI-generated vulnerability reports at scale is not a technical question. It's a governance and labor question, and the community hasn't answered it yet.

Vercel's DeepSec AI code auditing approach gestures at one answer—build the triage automation into the toolchain itself, so AI is both generating and filtering findings before they escape into the wild. That's promising for commercial projects with the resources to adopt it. It does nothing for the maintainer of a widely-used FOSS library who's already behind on issues.

The Amplification Argument and Its Discontents

The Low Level creator lands on the optimistic framing: "Using these AI tools, we can take our already cracked, really, really smart VR people, and we can turn them into a hundred copies of themselves." Amplification, not replacement. The skilled researcher's intuition drives the process; AI scales the execution.

I understand why this framing is appealing. And I'm not going to pretend the alternative—AI systematically displacing security researchers—is clearly inevitable. It isn't.

But "amplification not replacement" is also exactly what you'd expect to hear at the beginning of an automation wave, before the economics work themselves out. The security research community is already having this conversation, and it's not comfortable. Junior VR roles—the ones where researchers build the foundational skills before they develop the intuition that makes them useful to this human-in-the-loop model—are the first to look dispensable. If AI can do competent source-to-sink analysis on a fresh codebase in minutes, what's the training pipeline for the next generation of researchers who are supposed to develop that intuition themselves?

The creator's honest answer is: "It still takes a skilled human to drive these things, and that will never change, in my opinion." That's a genuine belief, not a dodge. But "in my opinion" is doing real work in that sentence. The research community has watched "it still takes a skilled human" prove true right up until it didn't, in field after field.

What I keep coming back to is the asymmetry of this particular moment. The tools that let a skilled researcher multiply their output tenfold are the same tools that let a less-skilled researcher generate a flood of low-quality reports that consume the attention of the maintainers those researchers are ostensibly trying to help. The capability is real. The coordination mechanisms to deploy it responsibly—inside open source communities that are already stressed, already under-resourced, already asking maintainers to absorb costs they never signed up for—those don't exist yet.

AI finding bugs in software we've depended on for decades is genuinely valuable. The question is who pays the cost of all the bugs it thinks it found.