When the Constraint Moves

AI has made finding security flaws cheap. It hasn't made fixing them safely any cheaper. And in security, someone else is chasing the same bottleneck.

I thought I'd had an original idea: AI makes thinking cheap, so the thing holding back progress moves somewhere else. Then I did the reading. Economists, Dario Amodei and a 1984 business novel by Eliyahu Goldratt all got there first. But somewhere in all that reading I found a narrower idea, about what happens when the bottleneck moves inside a system where someone is working against you. That system is security.

The bottleneck has moved

2026 is the year discovery stopped being the hard part. In July, Microsoft shipped a record 570 security fixes in a single Patch Tuesday and said AI-assisted discovery was the reason. Mandiant puts the average time to exploit at minus seven days: on average, exploitation now comes before the patch. Qualys, a security vendor, found defenders were slower than attackers on 88% of 52 actively exploited flaws.

This month, PHP2Shell showed what that looks like. Two critical flaws in the PHP runtime, which runs underneath a large part of the web, had sat in the code for more than a decade. AI helped one researcher turn them into working exploits in about a week. The fix had stalled for months. Details leaked before the patch was ready, exploitation attempts were reported within twenty minutes of its release, and some organisations took services offline rather than rush an untested update.

Most people now agree the bottleneck has moved from finding to fixing. Here's what I think we haven't said.

Someone else is chasing your bottleneck

In most industries, a moved bottleneck is a productivity problem. In security, someone on the other side is using the same tools.
Three things follow.

• You can't slow down the fast bit. Goldratt's answer to a bottleneck is to stop the fast steps flooding it. That works when you own the factory. In security, attackers have the same AI. Slow your own discovery and you just find out later than they do.

• Your queue can be found. In a factory, a backlog is waste. In security, it's a list of ways in. Before AI, 15–20% of vulnerabilities were rediscovered by someone else within a year. And in open source, the fix often goes public weeks before the warning that tells you to apply it.

• Fixes don't always stick. In one 2026 study of 6,080 AI-generated patches, only 26% were clean fixes. About half looked fixed but left the flaw exploitable.

Put those together and only one side carries the safety step. Attackers and defenders share the part AI made fast: finding the flaw. Only defenders carry testing, change control, sign-off and someone accountable when it breaks. Attackers don't do rollback plans. That holds for as long as AI is better at finding flaws than at proving a fix is safe.

Right at Google, wrong at a hospital

Picture two organisations with the same AI and the same findings. One is Google: find, fix, test, ship, roll back if needed. The other is a hospital: a fifteen-year-old imaging system, a maintenance window once a month and a supplier who controls the patch. Same AI, same findings, completely different outcome. What decides it is whether you can turn a finding into a safe, reversible fix faster than someone else can use it.

A deadline isn't capacity

Regulators have responded in very different ways. Washington sets the clock: three days for the most dangerous flaws. The UK's NCSC advises updating by default. For financial firms, DORA mandates the process: test before you roll out, set your own deadlines, and escalate when you can't meet them. The EU's Cyber Resilience Act puts more of the cost on whoever made the product.

None of them measures whether you have the capacity to fix safely. Shorten the clock without adding testing or people, and the protective steps are what get skipped. You've swapped a known vulnerability for an unknown outage.

I tested this over dinner in October with eight security and risk leaders. It's a sense check, not proof: they'd heard me make the case first. But none described measuring their capacity to fix safely, and none would let an AI patch go live on its own.

What to do on Monday

• Do things in Goldratt's order. Spend scarce fixing capacity on what's actually a risk in your environment. Make work flow in that order. Only then add people. Most programmes ask for headcount first.

• Keep the friction that protects you. If a step vanished tomorrow, what failure rate would you accept? If the answer is none, scale it. Don't cut it.

• Measure risk removed, not patches shipped. Count the days your reachable systems spend exposed to flaws known to be exploited, and the time from a fix going public to you being protected.

• Point AI at the bottleneck. The next gains are in testing, safe rollout and proving fixes landed, not in finding more.

None of this is solved by buying a product, yet. Including our own. The bottleneck is process, people and authority: what gets fixed first, how the work flows, and who is allowed to change what.

Read the full essay

The full essay goes further: what eight security leaders told me when I tested the idea over dinner, why vulnerability reports need their own version of the US grid regulator's "first ready, first served" rule, and three predictions I'd like to be held to in a year.

It's also a work in progress, and I'd like it to rest on more than one dinner. So I'm asking security leaders the same three questions wherever I can.

How much of the wait for a fix is protecting you, and how much is just waiting?

Has AI-driven discovery grown your backlog?

Does your clock start when a fix goes public, or only when the CVE arrives?

If you lead a security team, I'd especially like to hear where you think I'm wrong.
Read the full essay

I work in exposure management at Axonius. The views here are my own, and this isn't a pitch.