Remediation resists automation for a structural reason: it is the only step in the sequence that changes running software. Endor Labs chief executive Varun Badhwar's account is that any proposed fix can introduce regressions or break dependencies in ways that are hard to predict before the change ships, which turns each patch into an engineering exercise requiring testing and validation rather than a ticket to be closed [7]. Scanning carries none of that liability, which is why its cost curve fell and remediation's did not.
The ratio is the part worth doing arithmetic on. If discovery is running ahead of remediation by more than 16 to one, as research cited in the report estimates [5], then 15 of every 16 findings, roughly 94%, remain open for reasons of throughput rather than judgement [11]. The maintainer sample gives that queue a shape: more than 1,400 acknowledged reports at about a 90% validation rate works out to something near 1,260 findings that a competent reviewer agreed were real [4][12], with only a small share patched during the reporting period [4].
Where the popular framing needs correcting is the assumption that triage is the bottleneck. On Badhwar's telling, prioritisation is already going the way of detection: systems can correlate exploit intelligence, weigh reachability and explain likely business impact in seconds, work that previously had analysts assembling context from several tools by hand, with human judgement retained for risk acceptance rather than for the mechanics [9]. If that holds, triage throughput is the second commoditising step. The scarce capability is the ability to ship a tested change into production.
Badhwar is a vendor chief executive with an interest in relocating the hard problem to whatever he is closest to; he previously built Prisma Cloud at Palo Alto Networks after the RedLock acquisition, and he writes here in a Forbes Councils slot [1]. Yet the two figures he leans on are not his own telemetry. They come from J.P. Morgan's "Patchmageddon" report, which draws on work from Anthropic, Mozilla and Cloudflare and concludes that AI-assisted discovery has moved from theoretical to operational [2]. They remain unaudited numbers: the 16-to-1 estimate is attributed only to unnamed additional research, and the patched share is given as "a small percentage" with no figure and no stated length for the reporting window [13].
There is also a population mismatch that the argument does not resolve. The capacity being measured is that of open-source project maintainers, who understood the flaws existed and agreed they warranted attention but lacked the engineering hours to keep up [6][14]. Whether an enterprise with paid engineers and release automation sits at 16 to one, or at four to one, is not something this evidence shows. Treat the ratio as directional and the direction as credible.
That leaves a concrete trade-off for anyone allocating a security budget this quarter. Detection spend is predictable and lands in the security line; remediation spend is variable, because AI can generate code changes but every iteration consumes compute, engineering review and tokens, and safe fixes often take several attempts plus automated testing and human validation [8]. Adding inflow this quarter therefore books a cost next quarter in an engineering team the security budget does not control, which is a sequencing decision before it is a tooling one.
