Code Got Faster. Finding Bugs Got Faster. Retesting Did Not.

Sonar's January 2026 survey puts AI at 42% of all committed code. Over the same period, pull request review times rose 91%.

Those two numbers are the whole story, and they are not really about code.

Generation got cheap. Judgment did not. So the queue moved from writing to reviewing, and it will keep moving to whichever stage still requires someone to look at a thing and decide. That rule has now run three times in the software security pipeline. The third time, it landed on retest.

Retest is where a person has to decide whether a reported finding is still there after someone shipped a fix. Several platforms will retest a finding today, provided their own engine is what found it. None of them will take the finding a human wrote up in a report, which is what a consultancy's queue is mostly made of. RiftX does exactly that, unattended, and returns a verdict with the evidence behind it. The rest of this post is why that gap opened and why it is where it is.

The rule nobody states out loud

Every stage of shipping software is either generation or judgment. Generation produces an artifact. Judgment decides whether the artifact is acceptable.

AI has been extraordinarily good at generation and merely useful at judgment. That asymmetry does not eliminate constraints. It relocates them, and it relocates them in a predictable direction: toward whichever judgment step is downstream of the generation step that just got cheap.

You can watch this happen inside a single repository. Code volume up, review time up 91%, and only 49% of organizations have specific guardrails for AI-generated code at all. The generation side sprinted. The approval side stayed human, stayed serial, and became the thing everyone waits on.

The same pattern then ran at a larger scale, one layer out.

Stage one: writing the application stopped being the slow part

By early 2026 the numbers are not in dispute. Roughly 42% of committed code is AI-authored across the industry, near 30% of new code at large technology companies, and as high as 95% at small startups. Eighty-nine percent of engineering leaders report productivity gains.

Whatever you think of the code, more of it is arriving, faster, from fewer people.

Stage two: finding the bug stopped being the slow part

Security assessment became the obvious constraint, and capital went at it hard.

In August 2025, XBOW became the first machine to reach number one on HackerOne's United States leaderboard, on real bug bounty submissions against real targets. HackerOne subsequently separated human and machine rankings, which is the clearest possible admission that the old ordering had stopped describing anything. XBOW raised $75M that June and $120M in March 2026 at a valuation above $1B.

Then in November 2025 it shipped Pentest On-Demand: published per-test pricing from $4,000 for lightweight applications to $8,000 for complex ones, report inside five business days, human expert review included so it clears frameworks like PCI that require it.

Astra, Horizon3.ai and Pentera are running versions of the same play from different starting points. The details differ. The direction does not.

A penetration test used to be a scheduling problem measured in weeks and a procurement problem measured in months. For a growing share of applications, it is now four thousand dollars and five days.

Stage three: the queue arrived somewhere nobody was watching

Here is the part that did not move.

A retest is what happens after the report. Someone shipped a fix, and a person has to decide whether the finding is still there. Industry scoping guides put it at roughly thirty minutes of a tester's time per finding, blended across trivial and hard cases. That number is approximately where it was five years ago, because the work is still a human reading a report and driving a browser.

So the arithmetic runs one way. Findings per period went up. Minutes per retest stayed flat. Headcount did not move, because retest is bundled into the engagement fee at most firms rather than sold, which means it never appears in a staffing case as revenue that justifies a hire.

An estimate, and you should treat it as an estimate. A pentester at roughly 75% utilization handles 20 to 30 engagements a year, so a 50-pentester firm runs something like 80 to 125 engagements a month. Cross-checked against published engagement volumes, that lands around 50 retests a month reaching the queue. The derivation is triangulated from utilization benchmarks rather than reported directly, because no firm publishes this number. It is a closely held operational metric, and I would rather show you the derivation than assert a figure.

Every retest capability on the market is locked to its own findings

I want to be accurate here, because it would be easy and wrong to claim this is unaddressed.

Horizon3.ai ships 1-click verify, which re-runs NodeZero against a weakness it already identified. Pentera retests through its continuous validation model. XBOW tells customers to retest fixes immediately and trigger tests on demand. Astra tracks remediation and assigns issues to developers. These work, and they work well.

They work on findings the platform itself produced.

That is the property worth staring at. Retest capability today ships as a feature of a finder, which means it inherits the finder's boundary. NodeZero re-runs NodeZero's detection. XBOW re-runs XBOW's test. Neither is built to accept the other's finding, and neither is built to accept one a person wrote by hand.

Read the middle row again, because it is the whole problem. A human is currently the only source-agnostic retest capability that exists. That is precisely why the queue lands on the most expensive people in the building.

What that boundary costs in practice

This is not a hypothetical edge case. It is most of the work.

A firm running an AI platform on some engagements and manual testing on others has two retest queues and automation on one of them. A finding from an engagement eighteen months ago, delivered by a vendor the client no longer uses, belongs to nobody's tool. A client tested by firm A who hires firm B for the retest is outside every product on the market, and independent retest is often the entire point, since auditors and regulators want confirmation from someone other than whoever implemented the fix. Bug bounty submissions, customer-reported issues, findings inherited through an acquisition: same story.

What all of these share is that the report is the only artifact, and it was not written by the thing being asked to check it. Steps to reproduce, a payload, a screenshot, a severity rating, an opinion. There is no detection to re-run. There is a narrative to interpret.

None of this is a criticism of the platforms. Closing the loop on your own output is the correct thing for a finder to build, and it would be strange if they had built something else. It just means the retest queue a consultancy actually carries is untouched by all of it.

RiftX takes the finding as the input. It does not care what produced it.

The cost is the interrupt, not the hours

If you price the retest queue in hours, the argument collapses. Fifty retests at thirty minutes is 25 hours a month. For a 50-person firm that is a rounding error, and I am not going to pretend otherwise.

The hours are not the cost. The arrival pattern is.

Edgescan's 2025 data puts mean time to remediate critical and high severity application vulnerabilities at 74.3 days. The median time to resolve a pentest finding sits around 67 days. Retest windows in vendor policies run 30 to 90 days.

So the retest does not arrive at the end of the engagement, while the application is still loaded in someone's head. It arrives roughly two and a half months later, on a senior tester who is halfway through a different client, about a finding they wrote in another quarter. Before any testing happens they have to reconstruct the target, the account, the state, and what past-them meant by step four.

Fifty of those a month is not 25 hours of work. It is fifty context switches landing on the most expensive people in the building, none of them schedulable, all of them interrupting the deep testing those people were actually hired for.

And it recurs. Industry survey data puts ghost finding recurrence, issues that come back after being closed, near 60%. Cobalt's 2025 State of Pentesting puts the overall remediation rate at 48%, rising to 69% for serious and critical findings. Retest is not a gate you pass once. It is a standing obligation, and CREST and OWASP both mandate it as a phase while prescribing no number of rounds, which means the number is whatever the client asks for.

Finding a bug and confirming a fix are different problems

The obvious question, if you have read this far, is why the finders will not simply absorb this. Some of the answer is business scope. Most of it is that the two tasks are shaped differently.

A pentest agent succeeds by finding one path. It can try ten thousand things and needs a single one to land. Failure is cheap and success is self-evident: the payload fired.

A retest that returns Fixed is asserting a negative. It is claiming no path exists, and for a general target that is not provable. Every attempt that fails is evidence of nothing in particular. The reported payload going quiet is the weakest possible signal, because payloads go quiet for reasons that have nothing to do with the fix.

One run in our own logs does exactly that. Job 76b86a7a, a reflected XSS retest against a search parameter: the reported payload ;alert(1)-- went inert at step three, and the finding still came back Not Fixed eighteen steps later, on a bare <script>alert(1)</script> in the same parameter. The response carried the value back with no encoding on it at all, which means the fix that silenced the reported string had never been an encoding fix. That string was inert on its own merits, in that context, patch or no patch.

Any system that treats reproduction steps as the definition of the bug returns Fixed at step three, confidently, and is wrong. That is the failure mode a replay cannot escape, and it is why this is a different product rather than a feature.

What RiftX is

RiftX is an unattended retest product. Every job is a retest.

You give it a finding that already exists, with whatever steps to reproduce the report carried. It re-tests that finding against the live target and decides for itself whether the finding still reproduces, which is Not Fixed, or the fix holds, which is Fixed. When the evidence does not close, it returns Needs Review rather than guessing.

It does not scan. It does not look for new issues. It has one question and it answers that question, which is the whole reason it can be trusted with the answer.

What comes back

A verdict is not useful unless you can hand it to a client, which means the reasoning has to be checkable by someone who disagrees with it.

Every job seals a bundle: the HAR capture, a recording, screenshots, the reasoning behind the verdict, and an independent audit pass over the same evidence. The auditor is always on and can only move a verdict in one direction, down to Needs Review. It cannot promote anything.

The severity we return is derived from the captured evidence rather than carried over from the report, because the report's severity is the reporter's opinion about a finding whose current state is the thing you asked us to establish.

What we will not claim

Across the 328 regression scenarios we score the retest loop against, 20 came back Not Fixed against a fix that had actually held, and 10 returned Needs Review.

Those are errors and I am publishing them, because the direction they skew in is the design working. A false Not Fixed costs a tester twenty minutes to overturn. A false Fixed closes a live vulnerability and puts your name on the document that closed it. The errors point toward the recoverable failure, deliberately.

Needs Review is not a gap that got left in. It is the outcome the whole design bends toward when the evidence does not close, and a tool with only two possible answers will hand you one of them every time, including on the runs where it had no business being sure.

That run sealed twenty one steps, from the first navigation to the verdict, into a bundle a client can be handed. What one contains, file by file, is on the evidence page.