An AI autofix tool will not clear your vulnerability backlog, because the backlog is not a fix-generation problem. It is a capacity-allocation problem. A single, unreplicated August 2026 preprint, arXiv 2608.28509, reports that 94-100% of arriving issues in the trackers it studied enter queues already at or above capacity. If that holds, adding supply on the fix side just pushes the bottleneck to review and merge bandwidth, and the practical work is budgeting, sequencing, and dropping, not buying.
What did the preprint actually find?
The paper’s core empirical claim is that vulnerability remediation queues are saturated: in the primary issue trackers analyzed, 94-100% of new arrivals enter queues estimated to be at or above capacity. That is an author-reported figure from one preprint, Rethinking Vulnerability Remediation as a Capacity Allocation Problem, and it has not been independently replicated as of 2026-08-31. Treat it as a hypothesis with unusually good packaging, not as a settled base rate.
The study’s data comes from large public systems: Apache Jira, Mozilla Bugzilla, Red Hat security errata, five public Jira organisations, and an npm dependency graph. These are exactly the environments where queue dynamics can be observed at volume, and they are also environments whose arrival rates may look nothing like your team’s. A 12-person platform team with a private Jira and one security engineer is not Mozilla Bugzilla. The transfer from “public trackers are saturated” to “your tracker is saturated” is an inference you have to make with your own numbers.
The mechanism the paper proposes is flow control. A queue at or above capacity does not drain no matter how the items inside it are sorted. Arrival rate meets or exceeds service rate, so the backlog grows, and the marginal effect of any prioritisation scheme shrinks toward cosmetic. Under those conditions the paper finds two levers that still matter, both reported as associations rather than demonstrated causes: transitions from overloaded to draining queues are associated with shorter resolution times, and severity-first sequencing reduces critical-item delay at fixed capacity. Capacity reservation, setting aside budget that critical items can consume on arrival, is reported to reduce prolonged critical-item delays.
The paper’s own conclusion is the framing this article takes seriously: vulnerability remediation should be treated as a flow-control and capacity-allocation problem rather than solely a ranking problem. Ranking is what CVSS gives you. Flow control is what most security programs do not do.
Why doesn’t “found means fixed” clear the backlog?
Because “found” and “fixed” are separated by a queue, and the queue is the part that is full. GitHub’s homepage currently markets built-in application security with the line “found means fixed, use AI to find and fix vulnerabilities so your team can ship more secure software faster,” per GitHub’s homepage. It is clean copy. It is also a claim about two endpoints that skips the middle: someone has to read the proposed fix, decide it is correct, decide it does not break anything, review it, and merge it. That middle is staffed by engineers whose hours do not scale with the scanner’s detection rate.
Automated fix generation expands one specific resource: candidate patches. It does not expand verification bandwidth, review bandwidth, or merge bandwidth. If the preprint’s saturation finding generalises, then the queue was already at or above capacity before the tool arrived. Feeding more candidate fixes into a saturated queue does not drain it. It raises the arrival rate.
This is the asymmetry the vendor pages do not address. Neither the GitHub nor the Snyk homepage discusses verification, review, or merge capacity, which is precisely the constraint the preprint says binds. That silence is not an oversight; it is the shape of the sales pitch. Fix generation is the part a tool can demo in ninety seconds. Review capacity is an org-chart and headcount problem, and no homepage headline sells headcount planning.
Snyk’s framing runs the same play from the risk side. Snyk’s homepage claims that 65-70% of production code is now AI-generated and that nearly half contains vulnerabilities, with no methodology shown on the page. It also claims AI attacks chain multiple vulnerabilities autonomously with no human in the loop, again with no evidence or citation provided on the page. These numbers may be directionally true or badly off; the page does not give you a way to tell. What they unambiguously do is argue that the arrival rate of findings is going up. If arrival rate is the problem and capacity is fixed, a tool that increases detection and fix candidates without touching review bandwidth makes the queue longer, not shorter.
It is worth noting Snyk’s incentives, because they are public. Per Wikipedia’s Snyk entry, the company reported US$220 million in revenue against a net loss of US$176 million in 2023. A vendor spending at that rate to acquire a market has every reason to frame the market’s problem as one its product solves. That does not make the product bad. It makes the homepage a pitch, and pitches should be read as pitches.
Interestingly, Snyk’s own product description concedes the paper’s point by accident. The company says its AI Security Platform validates inside the tools teams already use: IDEs, CI/CD pipelines, and AI coding assistants including Claude Code, Cursor, and Codex. Validation inside the workflow is a review-bandwidth intervention. The product sits where the constraint is, even while the marketing copy sells the fear side of the equation.
Should you sort the backlog by CVSS or by exploitability per engineer-hour?
Sort by neither alone: use exploitability to decide what is worth an engineer-hour at all, then sequence severity-first inside the capacity you actually have. The preprint supports severity-first sequencing specifically at fixed capacity: it reduces critical-item delay when the fix budget cannot grow. It does not show that severity-first ordering shrinks the backlog, because at or above capacity nothing shrinks the backlog except more capacity or fewer arrivals.
CVSS severity sorting has a known failure mode in a saturated queue: it is a global ranking applied to a local rationing problem. A CVSS 9.8 on an internal build tool with no network path and a CVSS 7.5 on an internet-facing authentication service compete for the same engineer-hours. Pure severity sort takes the 9.8 first. Exploitability-weighted ordering, factoring exposure, known exploitation, and reachability, takes the 7.5. The preprint’s contribution is to make the capacity side explicit: whichever ordering you choose, it operates inside a fixed quarterly fix budget, so the real decision is which items get hours, not which items have scary scores.
The practical composite is exploitability per engineer-hour: expected risk reduced divided by the hours the fix will consume, including verification and merge time, not just patch-writing time. This is where autofix tools distort intuition. If a tool cuts patch-writing time for a class of fixes from four hours to twenty minutes, teams mentally reclassify those fixes as nearly free. They are not. The verification and review time is unchanged, and in some cases grows, because an engineer must now audit a patch they did not write. The denominator in exploitability per engineer-hour should be measured at the merge, not at the diff.
How do you build the triage table?
Build it as a rationing instrument, not a report: rows are backlog items or classes of items, columns are the inputs to the hours decision, and the table ends with an explicit rule for what gets dropped. The point of the table is to make the quarterly fix budget visible as a finite number of engineer-hours and to force every item to justify its consumption of those hours.
A working version looks like this:
| Backlog class | Exploitability signal | Fix cost (eng-hours, to merge) | Risk reduced per hour | Disposition |
|---|---|---|---|---|
| Internet-facing, known-exploited, reachable code path | High | 4-8 | Highest | Patch now; consumes reserved capacity |
| Internet-facing, high CVSS, no known exploit, reachable | Medium-high | 4-12 | High | Severity-first within quarterly budget |
| Internal-only, high CVSS, no external path | Low | 2-6 | Low per hour | Defer to budget remainder |
| Low/medium severity, unreachable or mitigated by config | Very low | 2-6 | Near zero per hour | Drop candidate; document and close |
| Third-party dependency bump with clean upgrade path | Varies | 1-2 (autofix-assisted) | Moderate | Batch into routine merge windows |
The hour estimates in this table are illustrative structure, not measurements. Fill them in from your own merge-time data. The column that does the work is risk reduced per hour, because it converts the backlog from a list of scary scores into an allocation problem with a defensible answer.
Three rules make the table function as policy rather than decoration. First, size the quarterly fix budget before ordering anything: a number of engineer-hours, agreed with engineering management, treated as hard. Second, reserve capacity explicitly for critical items, the mechanism the preprint associates with reduced prolonged critical delays. A reserve means a critical arrival displaces scheduled work instead of joining the back of a saturated queue. Third, write drop criteria for the tail you will never patch: severity below a threshold plus no reachable path plus no known exploitation, closed with a documented rationale. An explicit drop is a decision. An item that sits untouched for six quarters is a decision nobody made.
What changes when you buy Copilot autofix or Snyk?
The supply side changes; the binding constraint does not. An autofix tool reduces the cost of producing a candidate patch. If your queue was below capacity, with idle reviewers waiting for fixes to review, that is a genuine throughput gain. If the preprint’s saturation finding describes your environment, and the 94-100% figure says saturated queues are the norm in the trackers studied, then the constraint was never patch production. It was the engineers who verify, review, and merge.
This reframes what a purchase decision should evaluate. The question is not “how many vulnerabilities does it fix” but “how does it change the engineer-hours per merged fix.” A tool that generates patches requiring full human review of unfamiliar code may reduce patch-writing time while leaving total hours per merged fix nearly flat. A tool that validates findings inside the IDE or CI pipeline, which is how Snyk describes its own platform, attacks the verification side directly and is at least pointed at the constraint the preprint identifies. Neither GitHub’s nor Snyk’s homepage provides the numbers to compute hours-per-merged-fix for their tools, so a team evaluating either should run the measurement themselves before and after adoption.
The deeper shift is where the planning burden lands. If fix supply is cheap and review bandwidth is scarce, then security debt management is a review-capacity planning problem: how many engineer-hours per quarter go to remediation, how they are reserved and sequenced, and what gets dropped. That is a staffing and budgeting conversation with engineering leadership. “We bought autofix” is not an answer to it, and a vendor homepage that says “found means fixed” is, at best, describing the easy half of the pipeline.
How strong is the evidence?
Weak enough to hedge, strong enough to act on carefully. Every quantitative claim in the capacity-allocation frame comes from one preprint, arXiv 2608.28509, author-reported, unreplicated, observational. The central 94-100% at-or-above-capacity figure is an estimate over public trackers with their own selection effects: projects visible enough to run public trackers may have systematically higher arrival rates than a private product codebase. The queue-transition finding, that moving from overloaded to draining is associated with shorter resolution times, is explicitly an association. Reverse causality is plausible: teams that resolve quickly may be the ones whose queues drain, rather than draining queues causing quick resolution. The severity-first and capacity-reservation results carry the same observational caveat.
The vendor-side evidence is weaker still. GitHub’s “found means fixed” is a slogan. Snyk’s 65-70% AI-generated-code statistic and its autonomous-attack-chain claim arrive with no methodology on the page, per the homepage itself as fetched on 2026-08-31. No independent evaluation of Copilot autofix or Snyk’s remediation tooling was part of the evidence base for this article, so nothing here should be read as a measurement of either product’s real-world effect on backlogs.
None of this makes the capacity frame useless. Queue saturation is falsifiable in your own environment with data you already have: arrivals per month, merges per month, median time from finding to merge. If your arrival rate has met or exceeded your merge rate for four consecutive quarters, you do not need the preprint to tell you which regime you are in. The preprint’s value is giving that observation a vocabulary and a set of levers, severity-first sequencing and capacity reservation, that have at least observational support behind them.
What should you actually do?
Plan review capacity, not fix supply. Concretely, and in order: size a quarterly fix budget in engineer-hours and get it agreed as a hard constraint; sequence the backlog severity-first within that budget, weighting by exploitability per engineer-hour rather than CVSS alone; reserve explicit capacity so critical arrivals displace scheduled work instead of queueing behind it; and write drop criteria that close the tail you will never patch, with a documented rationale per item so the decision survives the person who made it.
Then, and only then, evaluate autofix tooling, with the evaluation metric set to hours per merged fix measured at your own merge pipeline. A tool that expands fix generation into a saturated review queue adds arrivals to a system that, per the one available preprint, is already at or above capacity in 94-100% of observed cases. The vendors selling “found means fixed” will not plan your review bandwidth for you. That part was always yours.
Frequently Asked Questions
How do I verify if my specific team is in the saturated queue regime described by the preprint?
Calculate your monthly arrival rate of new vulnerabilities against your monthly merge rate for the last four quarters. If arrivals consistently meet or exceed merges, you are in the saturated regime where prioritization has minimal impact on total backlog size, regardless of the preprint’s public tracker data.
Why does the preprint’s data from large OSS trackers like Mozilla Bugzilla not directly apply to a private 12-person engineering team?
Public trackers like Apache Jira and Mozilla Bugzilla have systematically higher arrival rates due to global visibility and lack of internal triage filters. A private team’s arrival rate is constrained by internal detection scope, meaning the 94-100% saturation figure is an upper bound, not a guaranteed baseline for smaller, closed environments.
What specific metric should I track to determine if an AI autofix tool is actually improving throughput rather than just shifting work?
Track ‘hours per merged fix’ from the moment a patch is proposed to the moment it is merged, splitting the data by whether the patch was human-written or tool-generated. If tool-generated patches show a flat or increased total hour count compared to human-written ones, the tool is not expanding verification bandwidth, only patch generation.
How does Snyk’s 2023 financial performance influence the credibility of its homepage claims about AI-generated code vulnerabilities?
Snyk reported a net loss of US$176 million against US$220 million in revenue in 2023, indicating a heavy spending strategy to acquire market share. This financial context suggests that homepage statistics, such as the claim that 65-70% of production code is AI-generated, function as marketing arguments for purchase rather than neutral, methodologically verified measurements.
