Finding the bug is the fast part now.

On Wednesday 30 September Google released Gemini 4 Argon, its new frontier model. The interesting part was not the benchmark table. It was the order of the queue. Argon went first to trusted cyber defenders through a programme Google calls Fairwind, before paying customers and well before the public, because Google says the model can autonomously find, validate and patch critical software vulnerabilities.

The numbers Google published point the same way. Argon scores 68% on CWE-bench, a test built from real classes of security flaw, and 77.9% on DeepSWE, a software engineering benchmark. Internally, Google says agents running on it migrated codebases of more than 800,000 lines and wrote a memory-safe video decoder 2.7 times faster than an existing Rust port. Treat those as vendor figures. The direction is still clear enough to plan around.

The queue tells you what they think it does

Releasing to defenders first is an admission. A model that can find a hole in your code can find one in anyone's. Google is trying to give the people who patch a head start on the people who exploit, and that head start is measured in weeks. It also means the number of known, fixable flaws in common software is about to go up, quickly, and every one of them comes with a deadline attached.

"

When finding the flaw takes an afternoon, the risk lives in how long the fix takes to arrive.

Where our systems are slow

A web app on a server is the easy case. You merge the fix, deploy, and every user has it on their next request. Most of what we build is not that. It is a check-in kiosk bolted to a reception desk, a touchscreen in a showroom, a box behind a display at an event, a tablet fleet running an operational app in a warehouse. Those devices are switched off at night, sit behind venue firewalls, run an app store build that waits for review, or only come online for the weekend they are hired for.

On those systems the time from fix written to fix running is not minutes. It can be days for a store release, and weeks for a device that lives in a storage cage between events. That gap used to matter less because finding the problem was slow too. If tools like Argon compress discovery, the update path becomes the whole exposure window.

What we would do now

• 01Know your fleet. A list of every installed device, its software version and when it last checked in, kept current, not rebuilt from memory when something goes wrong.
• 02Make updating boring. Signed over-the-air updates for anything we control, staged to a few devices first, with a rollback that does not need someone on site.
• 03Move logic to the server where it does not need to be on the glass. The less code on the device, the less there is to patch there.
• 04Treat dependencies as stock with a sell-by date. Pin them, watch them, and budget time each month to move them, rather than once a year in a panic.
• 05Put the patch plan in the quote. Who updates the install, how often, and what happens to a device that is offline when the fix lands.

The honest caveat

Argon is not generally available, and the benchmarks are Google's own selection. We have not run it on our code, and we would want to see what it gets wrong before trusting what it gets right. Automatic patching on someone else's codebase is also a different promise from a patch you understand well enough to ship to a hospital reception or a live event.

None of that changes the shape of the problem. For years the bottleneck in software security has been people noticing. That bottleneck is being automated on both sides. The studios that do well will be the ones whose systems can take a fix on a Tuesday afternoon without anyone driving to site.