Who still owns the patch decision?
AI is not arriving on one side of software security. It is pressing both sides at once.
One side of that pressure is assurance. Anthropic said it is using Claude to formally verify software at large scale, a concrete sign that software inspection is moving further into machine speed Anthropic said.
The other side is flaw discovery. MIT Technology Review said AI uncovered a decade-old flaw threatening much of the web, a concrete sign that old code can yield new findings faster than many teams are used to handling MIT Technology Review said.
These are different activities, but they converge on the same gate. More software can be checked. More flaws can be found. The review path after that finding still belongs to named people on accountable teams.
That is the unsettling symmetry. The risk is not only that attackers automate. Defenders automate assurance too. Both accelerations narrow the same span between a report and a decision.
A finding does not patch itself. A verified property does not decide whether a release stops, whether a service can wait for maintenance, or whether a workaround is safer than a rushed change. Those decisions still sit with people who can be asked why they acted, why they waited, or why they accepted the risk.
Ethan Mollick described AI security as an acceleration of attack and defense at inhuman speeds interacting with human systems that need to react Mollick wrote. That frame matters because it puts the bottleneck in the open. The narrow point is not computation. It is organizational judgment under accountability.
The loss, if nobody owns that narrow point clearly, is not abstract. It is authorship of the patch decision itself. The machine-speed lanes keep feeding the queue while the approval gate remains a calendar event, a chain of messages, or a handoff nobody has authority to complete.
Today, that can mean a team receives a stronger signal sooner and still moves no faster where it counts. This is not a failure of scanning. It is a failure of prepared decision paths.
Pre-decide the path before findings land
The answer is not to slow the tools down. The answer is to remove avoidable hesitation from the human gate they are converging on.
A prepared team decides in advance who can triage a new finding, who has authority to interrupt planned work, who can approve a patch outside the normal release rhythm, and what threshold moves an issue from report to action. Those choices do not eliminate judgment. They reserve it for the parts that cannot be delegated to a model or a scanner.
That is where control still exists. A person can define escalation rules before the next report appears. A lead can assign a single owner for verification. An incident manager can specify what evidence is enough to trigger containment while a deeper review continues. The point is not speed for its own sake. The point is to keep machine-speed discovery from collapsing into human delay.
In practice, this week’s useful work is plain:
- name the person who owns first triage for AI-assisted findings
- name the person who can authorize a patch without waiting for a meeting
- define the threshold that turns a report into an action item
- decide what temporary mitigation is acceptable if a full patch cannot ship first
- write the handoff so the next finding does not depend on memory
The practical takeaway
Prepare the decision path before the next finding arrives. Decide who can triage, who can patch, and what threshold moves an issue from report to action without waiting for a meeting.
Human Runtime Core™ is designed for the mental edge you need to survive in an AI-run world.