Speed Was Never the Bottleneck. Trust Was.

Which makes most of the current conversation slightly off target. The pitch is speed. The constraint is belief.

What actually got faster

Google’s 2025 DORA State of AI-assisted Software Development report surveyed nearly 5,000 technology professionals and found that 90% now use AI at work, with more than 80% believing it increased their productivity. It also found something less quotable: higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability.

The word doing the work in that sentence is “and.”

More change is arriving, and more of it is going wrong. Those are not contradictory findings. They are what happens when you make one half of a two-half process dramatically cheaper. A software pipeline produces changes and it evaluates them. AI industrialized production. Evaluation is still a person reading something and deciding whether to believe it.

The same report found that 30% of developers report little to no trust in the code AI generates. Note that this is not a rejection. Adoption sits at 90% while confidence sits well below it. People are shipping work they do not fully believe, because the alternative is shipping less. That gap is not a culture problem to be trained away. It is an accurate reading of the situation.

The merge gate is a trust gate

Every security fix, whoever or whatever wrote it, ends at the same question: do we ship this.

That question was never about typing speed. It is about whether the person approving the change can tell that it does what it claims. Which is precisely the thing AI made harder, not easier, because the output got more fluent without getting proportionally more correct.

Stanford researchers studying developers with and without an AI assistant found that participants using one wrote significantly less secure code, and were more likely to believe their code was secure. Fluency and correctness came apart, and the fluency was convincing enough to stop people from checking. Veracode’s 2025 GenAI Code Security Report, which analyzed output from more than 100 large language models, found AI-generated code introduced security flaws in 45% of tests.

So the reviewer’s job got harder at exactly the moment the volume got bigger. That is the bottleneck. Not the writing. The believing.

What trusting AI-generated code actually requires

Trust is not a feeling you develop about a tool over time. In an engineering pipeline it is an output, manufactured from three specific inputs. When a security fix arrives at the merge gate, the question is whether it carries them.

Evidence. Not a classification of the problem, an artifact of it. The request that produced the behavior and the response that came back. A classification tells you what kind of thing someone believes this is. An artifact tells you what your application actually did. Only one of those can be checked by somebody who was not there.

Repeatability. If two runs against the same build return different results, nothing downstream of them means anything. A finding that appears intermittently cannot be distinguished from a fix that worked, and a finding that disappears cannot be distinguished from a scan that got unlucky. Repeatability is not a nice property of a good tool. It is the precondition for every claim built on top of it.

Verification. This is the one the industry is currently skipping, and it is the expensive one.

A fix is a hypothesis until something re-runs the exact request that proved the problem, against the build that supposedly fixed it, and shows the behavior is gone. Until then you have a plausible diff and a closed ticket. “No longer flagged” and “fixed” are different claims, and the gap between them is where regressions live. A scanner that did not reach a route this time reports the same clean result as a scanner that reached it and found nothing.

Notice that all three are properties of the record, not of the agent. You cannot improve them by using a better model.

Why a severity label fails all three

Hand an agent a vulnerability class and a severity score and it will write you a fix. Well structured, confidently explained, and wrong often enough to matter, because it is pattern matching against what that kind of bug usually looks like rather than against what your application actually did.

A severity is a judgment about a category. It is not a fact about your system. It cannot be reproduced, it cannot be re-run, and it carries no proof that anything changed. It fails evidence, repeatability, and verification at once, which is why “we gave the agent our findings” so often produces confident diffs that nobody wants to merge.

The reviewer then has to re-derive from scratch what the tool already knew and did not pass along. That is the actual cost, and it scales with volume.

What happened when one project priced trust correctly

The curl project ran a bug bounty for roughly seven years, paying out over 100,000 USD for 87 confirmed vulnerabilities. For most of that run, somewhere north of 15% of submissions turned out to be real.

Then, as maintainer Daniel Stenberg documented, the confirmed rate collapsed to below 5%. Not even one in twenty. The cost of generating a plausible security report had gone to zero while the cost of evaluating one had not moved at all, and a small team absorbed the entire difference. In January 2026 the project ended the bounty.

Here is the part that matters, and it is not the part most people quote. curl returned to HackerOne in March 2026, and Stenberg reported that the rate of confirmed vulnerabilities went back to and even surpassed pre-AI levels, somewhere in the 15-16% range, while report volume ran at roughly double the previous year. His assessment of the AI question: “The slop situation is not a problem anymore.” And: “Almost every security report now uses AI to various degrees.”

So the recovery did not come from removing AI. AI use went up. Volume went up. What changed was the economics of submitting something unverified. Once a plausible-sounding claim stopped being worth filing on its own, what arrived carried enough to be worth reading.

That is the same lesson, at a different scale, as the one inside your own pipeline. The problem was never that machines were participating. It was that participation had become free while evaluation stayed expensive. You fix that by changing what a submission has to carry, not by trying to slow the submissions down.

Three ways a fix arrives at the merge gate

None of these rows are about speed. Every one of them is about how much work a reviewer has to redo before they are willing to sign.

What this means for how AppSec spends its time

The uncomfortable version of this argument is that AppSec becomes a rubber stamp on machine output. It does not, and the honest reading is more useful.

Agents absorb volume. They read more surface than any human could, they draft the fix, and they can check their own work when there is something to check it against. What they do not do is set the standard, decide whether a fix is genuinely a fix, or own the consequences of shipping it.

None of this shrinks the AppSec team. It is the only thing that scales one.

The shift is what the team spends its hours on. Less time re-deriving whether a finding is real, because the evidence arrived with it. Less time guessing whether a patch worked, because the re-run answered it. More time on the judgment calls that were always the actual job and never had enough room.

Same team. Far more surface. The judgment stays exactly where it belongs.

Where NightVision fits

NightVision produces the finding half of that record.

Every finding ships with the full request and response that produced it, so what reaches the reviewer is an artifact of the application’s behavior rather than a classification of it. Findings reproduce identically against the same build, which is what makes a second run mean something. And the loop closes: over MCP, a coding agent such as Claude Code, Cursor, GitHub Copilot, or any MCP-capable agent can start a scan, read the evidence, propose a fix, and re-run the scan to check its own work. The results export as SARIF into GitHub Security Alerts, so found, fixed, and verified become a record someone can read later rather than a memory of a conversation.

On API scans where NightVision also ran source-based discovery, a finding resolves to the source file and line that produced it, so the agent is working on the right code rather than the code it guessed.

The human still approves the merge. That is not a limitation we are working around. It is the design.

Determinism on the finding. Agents on the fix. Humans on the merge.

Frequently asked questions

Does AI-assisted development actually make software less secure?

It makes more software, faster, with a wider quality distribution. Google’s 2025 DORA research found higher AI adoption associated with increased delivery throughput and increased delivery instability at the same time. Stanford researchers found developers using AI assistants wrote less secure code while being more confident it was secure. The risk is less about any individual output and more about volume arriving faster than evaluation can keep up.

What does it mean to trust AI-generated code?

In practice it means a reviewer can establish that a change does what it claims without redoing the work themselves. That requires evidence they can inspect, results that reproduce, and a verification step showing the intended behavior change actually happened. Trust in this sense is a property of the record attached to a change, not a judgment about the model that wrote it.

Why isn’t a severity score enough for an AI agent to write a fix?

A severity describes a category of problem, not your application’s behavior. An agent given only a class and a score pattern matches against what that kind of bug usually looks like, which produces fixes that are well structured and confidently wrong often enough to matter. Given the actual request and response, the agent has something to check its own work against.

How do you verify that an AI-written security fix actually worked?

Re-run the exact request that demonstrated the problem against the build containing the fix, and confirm the behavior is gone. This only proves anything if the scan is repeatable, since a finding that disappears because a scan did not reach the route looks identical to one that disappeared because the code was fixed.

Does any of this reduce the need for an AppSec team?

No. It changes what the team spends its time on. Agents absorb volume and drafting. Setting the standard, judging whether a fix is real, and approving what ships stay with the security team, which is the part that was always underserved because the volume work consumed the hours.

Where should a team start if AI-written code is already shipping?

Start with what your findings carry today. If a finding arrives as a class and a score, no agent and no reviewer downstream can do better than guess. Getting reproducible evidence attached to findings, and a re-run that confirms a fix, changes the economics of every review that follows.

If fixes are arriving faster than your team can believe them, the gap is in what those findings carry. Book a demo to see what a finding looks like when it arrives with its proof attached, or start free and point a scan at the application you are least sure about.