The Denominator Problem

I’m not sure if this is a new mistake or just wishful thinking. Organisations, when they talk about security and quality in the AI era, treat AI purely as a productivity multiplier with lower overhead.

The logic goes something like this:

“Move the budget for two developers into AI tooling, and output goes up 10x.”

So the old equation:

X developer_spend = Y_productivity

becomes:

X - 2 developer_spend = 10 × Y_productivity

Simple. Attractive. Wrong (I need Holly Cummins Wah Wah Wah audio at this point)

Productivity in software is not just a function of how many developers you have or how many lines of code, features, tickets, or test cases you can produce. Developers know this already. Real productivity depends on the organisation’s ability to validate what it produces, understand the risks it is introducing, and correct mistakes before they become incidents.

AI may increase the volume of output. But volume, much as many early rock bands would disagree with, is not the same as quality, safety, or useful progress.

Counting productivity purely as quantity is naive, even when the thing being counted is “more tests” or “more code coverage”. More generated test cases do not automatically mean better assurance. More code does not automatically mean more value. More changes do not automatically mean more delivery.

The number of people in the organisation is only the numerator. If AI increases the output of the numerator while the denominator is ignored, the organisation has not improved productivity. It has just increased output without increasing control.

The denominator is everything else those people are expected to cover.

More generated code. More modified code. More repositories. More integrations. More third-party packages. More model APIs. More AI agents. More data movement. More prompts that influence business behaviour. More automation running inside workflows never designed to be autonomous.

If the numerator stays flat (or, as is apparently happening, goes down) and the denominator expands, coverage falls. That’s how “we didn’t cut the security team” can be technically accurate and tragically misleading at the same time.

Cybersecurity spending is already under pressure. IANS and Artico reported that average security budget growth slowed to 4% in 2025, down from 8% in 2024, while security spending as a share of IT fell from around 12% to 11%. Staffing growth hit its lowest level in four years (IANS / Artico Security Budget Benchmark Report).

That would be worrying in a normal year. It’s much worse in a world where AI simultaneously changes the attacker model, the developer workflow, the review burden, and the volume of change.

There’s a second denominator problem. This one lives in open source itself.

The CVE and vulnerability disclosure process was already strained before AI. It depended on scarce human attention: maintainers, security teams, CNA staff, bug-bounty triages, and ecosystem reviewers. People giving time and effort to keep the rest of us safe and informed.

AI is being used to maliciously attack this process and bring it down. The less we know about vulnerabilities in our dependencies or tools, the easier it is for the bad guys to exploit our environment.

It’s not always malicious either. Sometimes the person submitting the report believes the AI-assisted tool result. Sometimes a contributor pastes a generated explanation into an issue because it looks plausible. Sometimes a startup wants vulnerability “discoveries” as marketing collateral. Sometimes it’s just spam with better grammar.

The effect is the same: AI generates human-shaped security work much, much faster than humans can actually validate it.

Daniel Stenberg has written repeatedly about curl being hit by AI-generated vulnerability reports that look plausible but collapse under review: “death by a thousand slops” (Daniel Stenberg).

The curl project added explicit rules requiring contributors to disclose AI use in security reports because low-quality submissions waste scarce maintainer time (Socket).

OpenSSF’s vulnerability-disclosure working group runs an active AI-SLOP effort because open-source projects face waves of low-quality AI-generated reports (OpenSSF).

Even Linus Torvalds has warned that the Linux kernel security list is becoming unmanageable due to AI-assisted duplicate reports through private channels (The Verge).

The cost of generating plausible reports has collapsed. The cost of validating them has not. The cost of filing a plausible PR has collapsed. The cost of reviewing it has not.

That imbalance pushes scarce human reviewers into a queue they can’t ever clear. It’s ironic that AI, here being used to help, can often be a significant burden. (Humans are turning out to be lazy when checking the creation of a forceful and articulate AI before sharing it).

I’ve been talking about software supply chain security since around 2014. For a long time, it often felt like shouting into the wind. Then things improved. SBOMs became a serious conversation. Dependency scanning became normal. Signing and provenance moved from specialist concerns into mainstream platform thinking.

That progress is real, but AI is now stress-testing it from two directions at once.

Attackers get better automation. Defenders get more surface area. Developers get faster generation. Reviewers get more to review.

AI doesn’t need to invent new attack patterns to make supply chains worse.

Dependency confusion and typosquatting already existed. But AI makes the economics nastier. It generates package names, README files, fake usage examples, plausible changelogs, issue comments, and pull requests at scale.

It helps attackers mimic the tone and shape of legitimate open source activity. It produces variants faster than a human reviewer can build confidence.

Sonatype identified over 454,000 new malicious packages across npm, PyPI, Maven Central, NuGet, and Hugging Face throughout 2025, bringing its cumulative known-and-blocked malware count above 1.2 million packages (Sonatype).

Unit 42 showed that LLM-assisted rewriting of existing malicious JavaScript produces variants harder for classifiers to detect: mutating malware past signature-based defences rather than generating it from scratch (Unit 42).

Traditional scanners struggle because they are designed to recognise what they’ve already seen. A newly published package with plausible metadata and slightly different code often defeats them. Behavioural analysis, provenance, maintainer identity, and human review all become more important precisely when human review is overwhelmed.

They rubber-stamp reviews. They lower the bar. They approve exceptions. They rely on the tool because the tool is faster than the human process. They stop reading every diff. They trust the generated tests. They defer the threat model. They accept the dependency because the build is green.

That’s exactly what offensive supply-chain attackers want. They don’t need every malicious package to work. They need volume, plausibility, and enough exhausted humans to let one thing through.

The defender has to be right repeatedly. The attacker needs one successful package, one stolen token, one confused namespace, one AI-assisted PR that nobody quite has time to unpack.

The developer adoption data shows how fast this has moved.

GitHub’s 2023 research found 92% of surveyed US developers had already used AI coding tools (GitHub).

Stack Overflow’s 2024 survey found active use rising from 44% to 62% in a single year (Stack Overflow 2024). By 2025, sentiment had turned more cautious, security and privacy concerns became one of the main reasons developers reject technologies (Stack Overflow 2025).

DORA’s 2025 research is the most telling: 90% AI adoption, a median of two hours a day on AI tools, more than 80% reporting productivity gains, but only 24% reporting high trust in AI outputs (DORA 2025).

Developers are using the tools. Organisations are banking the productivity narrative. Trust, validation, security review, testing discipline, and accountability haven’t caught up.

Good QA was never just “write tests”. It’s risk modelling, exploratory thinking, knowing which edge cases matter and which happy-path test proves almost nothing.

AI helps with scaffolding, input variation, failure summaries, and regression suites. It can also flood the system with low-value tests that create the appearance of coverage without the substance.

The same pattern holds for AppSec. AI helps triage findings, summarise dependency changes, cluster alerts, draft threat models. But if an organisation uses those theoretical gains to stretch AppSec thinner before measuring false negatives, escalation paths, and auditability, it hasn’t improved security. It’s made a bet against the future: will AI defences get better faster than AI attackers? Want to place a wager?

Things won’t improve if you don’t measure AI adoption with the right questions.

“How many developers use Copilot?” is the wrong question. “How many prompts did we run?” is the wrong question.

Ask instead: Did the change failure rate go up? Did rollback rates increase? Did the security review lead time increase? Did dependency SLA breaches increase? Did exception backlogs grow? Did the system become easier to recover, or merely faster to change?

The board doesn’t need another AI excitement dashboard. It needs a risk dashboard showing whether AI investment is being funded by degradation elsewhere.

AI has made software supply chain defence more human-dependent.

AI can help defenders triage, cluster, summarise, and prioritise, so use it for that. But the final control still depends on humans who understand context: maintainers, reviewers, QA engineers, AppSec people, release engineers, platform owners.

AI mimics those humans from the outside. It produces a plausible report, a plausible package, a plausible fix, a plausible test. Plausibility is not trust.

Track the denominator. Applications per AppSec engineer. Repositories per reviewer. Services per platform owner. AI-assisted pull requests per senior reviewer. Critical systems per QA engineer. Unsupported dependencies per maintainer.

DORA’s central finding should be the operating principle: AI amplifies the qualities of the existing system (DORA 2025). If your system is already underfunded and running on the knowledge of a handful of senior engineers nobody has time to replace, AI won’t save it.

It’ll help you fail faster. With a better-looking demo.