The Validation Tax Is the Real AI Code Crisis

The bottleneck isn't detection. It's proof.

ProjectDiscovery's 2026 AI Coding Impact Report surveyed 200 cybersecurity practitioners across North America and Western Europe. The headline finding: two-thirds of them spend more than half their working hours manually validating findings rather than resolving the underlying vulnerabilities. Not triaging. Not remediating. Validating. Proving that the thing the scanner flagged actually matters.

That's the validation tax. And as AI-generated code accelerates engineering output, it's compounding fast.

AI coding is shipping faster. Security isn't keeping pace.

Every single respondent in the ProjectDiscovery survey reported increased engineering delivery over the past twelve months. Nearly half (49%) attributed most of that acceleration to AI-assisted coding tools. That tracks with what teams across the industry have been feeling: pull requests land faster, feature velocity is up, code volume keeps climbing.

But 62% of security teams say keeping up is getting harder. Mid-sized organizations feel it most acutely, with 69% in that cohort reporting growing difficulty managing the review load.

The gap here isn't a staffing problem you can hire your way out of. It's structural. More code means more findings, more findings mean more validation work, and validation work doesn't scale linearly with headcount.

Where the time actually goes

The report breaks down what security practitioners actually do each week. It's grim reading for anyone who assumed AppSec teams spend their days fixing things:

• 60% spend time triaging alerts
• 53% spend time coordinating fixes across teams
• 46% spend time validating exploitability

None of those activities is fixing a vulnerability. They're all overhead that sits between "scanner found something" and "engineer can act on it." That's the validation tax in its purest form: the time cost of converting a noisy alert into a confirmed, actionable finding.

Secrets exposure: the #1 concern from AI-assisted code

When asked what security risks AI coding tools amplify, 78% of respondents cited secrets exposure as their top concern. API keys, tokens, credentials embedded in generated code or leaked through prompts and context windows.

This has implications for any code review tool operating on sensitive diffs. If your review system ingests the full diff context to generate useful feedback, it's also processing whatever secrets that diff contains. That's a design constraint, not a feature request. Review tools that touch code must be architected with the assumption that secrets will be present in the data they handle.

More tools, more noise, worse outcomes

Here's the counterintuitive part: adding another scanner or review tool to your pipeline doesn't necessarily help. If each tool produces findings that require their own manual validation cycle, you've just increased the tax.

Rishi Sharma, ProjectDiscovery's CEO, put it directly: "Practitioners do not need more scanners piling on more alerts. They need fewer tools that deliver evidence instead of noise."

The right question for any tool evaluator isn't "does this find more issues?" It's "does this reduce my total validation burden?" A tool that finds ten issues but requires manual confirmation of each one is a net negative compared to a tool that finds three issues and proves all three are real.

What evidence-grade review signal looks like

There's a meaningful difference between a review comment that says "this might be a bug" and one that says "this will break because processOrder() calls validatePayment() with a null customer ID when the guest checkout flag is set."

The first creates a validation task. Someone has to check whether it's actually a bug, understand the context, and decide whether to act. The second is already validated. It carries the proof with it: the specific call chain, the specific condition, the specific failure mode. An engineer can go straight to fixing it.

This is the design principle behind Tenki's code reviewer: every review comment should carry enough context to act on without a separate validation step. The reviewer understands your codebase, follows custom rules you configure, and produces findings that reference the specific code paths involved. Instead of adding items to a triage queue, it delivers signal that an engineer can take straight to a fix.

Trust requires transparency

The ProjectDiscovery report surfaced another constraint: 57% of respondents said they'd need a full audit trail before trusting AI-based security tooling. Security teams won't adopt tools they can't inspect. That's rational behavior, not resistance to change.

For review tools, this means the reasoning behind each finding has to be visible. A comment that says "potential SQL injection" with no further context asks the reviewer to trust the tool's judgment blindly. A comment that traces the tainted input from the request parameter through three function calls to the unparameterized query gives the reviewer the evidence to make their own call. That's what transparency in practice looks like.

The evaluation framework that matters now

If you're evaluating AI code review or security tools, the ProjectDiscovery data suggests a single filtering question: does this tool reduce or increase my team's total validation burden?

That means asking:

• Do findings include enough context to act on directly, or do they create new triage work?
• What's the false positive rate under real-world conditions, not in a demo?
• Does the tool understand codebase-specific context, or does it apply generic rules?
• Can you inspect and configure the reasoning, or is it a black box?
• How does the tool handle sensitive data in diffs?

Two-thirds of security practitioners are already drowning in validation work. The last thing they need is another tool that makes the pile bigger.