For twenty years we built better smoke detectors.
Now we are finally building firefighters.
We have gotten incredibly good at finding problems.
Your IDE underlines a vulnerability before you finish typing it.
Your CI pipeline fails because a transitive dependency three levels deep has a CVE from
2019.
Your inbox gets a Dependabot PR every Tuesday that you will politely ignore until Thursday.
GitHub Advanced Security, Snyk, Semgrep, Wiz, Orca, Lacework, the alphabet soup of scanners has turned security into a very high resolution photograph of a burning building.
We know exactly where the fire is.
We have a heat map.
We have a severity score.
We have a CVSS vector that nobody reads.
We just do not put it out.
That is the strange era we are exiting.
The Finding Economy Was Profitable The last decade of AppSec was built on an unspoken agreement: tools find, humans fix.
It was a sensible division of labor when finding was hard.
You needed abstract syntax trees, taint analysis, symbolic execution, and a PhD to explain why your Python string concatenation was actually remote code execution.
So we built an entire economy around detection.
Dashboards that count vulnerabilities.
Leaderboards that shame teams for not triaging fast enough.
Compliance frameworks that ask if you know about your bugs, not if you fixed them.
The metric of success became mean time to detect, not mean time to remediate.
The result is predictable.
The average enterprise has something like 50 to 100 days of open critical vulnerabilities, not because engineers are lazy, but because the funnel is fundamentally broken.
You can generate ten thousand findings with a single scan.
You cannot generate ten thousand fixes with a single engineer.
Finding scales with compute.
Fixing scales with humans.
And humans do not scale.
Anyone who has maintained an open source project knows this pain intimately.
You get a beautiful, detailed issue report with a proof of concept, a CVSS score, and a polite note that you are endangering the internet.
What you do not get is a patch that passes your tests, respects your architecture, and does not break the three weird edge cases only you know about.
We celebrated the finder.
We burned out the fixer.
Why Fixing Is a Different Species of Problem It is tempting to think of fixing as finding plus one more step.
It is not.
It is a different cognitive task entirely.
Finding is a pattern matching problem.
Does this code look like that bad code I have seen before?
Is user input flowing into a sensitive sink without sanitization?
An LLM is shockingly good at this, because it has seen millions of examples of both good and bad code.
Fixing is a planning and context problem.
To fix a bug correctly you need to understand intent, not just syntax.
You need to know what the original author was trying to do, what invariants the rest of the codebase relies on, what the test suite actually covers versus what it pretends to cover, and how to make the smallest possible change that closes the hole without opening two new ones.
A bad fix is worse than no fix.
A bad fix gives you false confidence and a new CVE with a different name.
This is why early attempts at auto remediation felt like a Clippy for security. "It looks like you have a SQL injection, would you like me to add an ORM?" No, thank you.
What changed is not that models got better at writing code, although they did.
What changed is that they got better at operating tools.
The new generation is not a chatbot that writes a diff.
It is an agent that can reproduce the bug, write a test that fails because of it, edit the source, run the relevant tests, observe the failure, try again, and iterate until the green checkmarks come back.
In other words, it can do the boring, methodical, unglamorous loop that human engineers actually do when they fix something.
It just does not get tired at 2 AM.
We Are Entering the Patch Agent Era Look at what is happening at the edges.
In open source, you now have agents that