The argument that the industry has about a year before cheap local models make exploitation routine
An essay making the rounds this week sets out a deadline argument, and it is worth reading precisely because it does not rest on speculation about future capability. It rests on three things that are already true and can be checked.
First, the safeguards are optional once weights are public. Open-weight models are downloaded and re-released with their refusal behaviour surgically removed — the practice has a name, "abliteration", and groups doing it publish benchmark scores showing the stripped models refuse essentially nothing. The lab that trained the model is no longer in the loop.
Second, the hardware is ordinary. The author works through the arithmetic of running a current flash-class model locally: a GPU workstation in the single-digit thousands, or a large unified-memory desktop in the region of ten thousand dollars, producing tens of tokens per second — enough for continuous, round-the-clock use by one motivated person rather than by an organisation with a data centre.
Third, the capability is measured, not assumed. The essay cites security benchmark results — 84.5% on CyberGym, 54.4% on ExploitBench for the full model — and points out that the cheap variant will land near it. Models are already finding and exploiting real vulnerabilities; the question is only how cheaply.
From there the argument is simple: the same class of model that makes attack cheap also makes defensive review cheap, so the industry has a window in which it can out-fix the coming attacks. And the essay's most useful claim is about where the bottleneck actually sits. Finding bugs is no longer the hard part. Triaging them, writing patches that do not break anything, backporting them to versions people actually run, and getting those versions deployed — that is the part no model does for you, and it is the part that is chronically underfunded.
The prescription follows from that: point money at maintainers and at engineers who will review, backport and ship rather than at generating more findings, and use structured, targeted review prompts instead of asking a model to hunt for bugs in general.
What it means
The deadline framing is arguable; the bottleneck observation is not. Whether the window is one year or three is a forecast, and forecasts about model capability have a poor record in both directions. But "we can generate more security findings than we can possibly deploy fixes for" is a description of today that any maintainer of a widely-used library will recognise, and it does not depend on the forecast being right.
The asymmetry is the uncomfortable part. An attacker needs one working exploit against one unpatched deployment. A defender needs a patch written, reviewed, released, packaged, and then installed by thousands of people who are busy. Cheap automation multiplies both sides, but it multiplies the side with the shorter checklist far more efficiently.
The practical read for an engineering team this quarter is not to buy an AI security product. It is to ask how long a known-critical patch currently takes to reach production in your own estate, measure it honestly, and treat that number as your real exposure. If it is measured in weeks, no amount of faster bug-finding — yours or anyone's — changes your position.
The full essay, with the hardware costs and benchmark citations, is linked above.