On April 7, Bruce Schneier published an essay on the age of “instant software”: applications generated on demand by AI, used for a specific purpose, then discarded. His thesis, explicitly optimistic, is that security could improve if defenders use the same tools as attackers to find and patch vulnerabilities faster.
The argument is clean. The problem is that it rests on enormous unknowns, and above all on a fragile assumption: that a meaningful share of AI-generated software will actually be ephemeral.
In the real world, a lot of AI code does not get deleted.
It gets committed.
“Disposable” AI Code Does Not Exist in Production
The central image in Schneier’s essay is this: “Taken to an extreme, it might become easier for a user to have an AI write an application on demand—a spreadsheet, for example—and delete it when done.” No persistent vulnerability, no lasting attack surface. The software disappears before anyone finds a way to exploit it.
As an extreme scenario, that makes sense. As a description of production software, much less.
A developer uses Copilot or Cursor to generate an authentication module. They test it quickly: it works. They commit it. From that moment, the code is no longer instant. It is permanent. It enters the system, gets copied into other projects, outlives the team that wrote it, and becomes a transitive dependency of things nobody will ever audit again.
Disposable software exists in proof-of-concepts and demos. In production, far less code is thrown away than we like to pretend. More often, it stays there: no longer understood, no longer actively owned, but still running.
The Five Unknowns Behind Schneier’s Optimism
Schneier lists five explicit unknowns: how well AI vulnerability discovery tools will work against closed-source commercial software; how much better AI will get at writing secure code reliably; how quickly it will generate patches that do not introduce new bugs; whether it will find the most obscure and subtle vulnerabilities, the ones requiring deep contextual understanding; and whether we will ever solve prompt injection attacks against defensive AI systems.
Each of these is not a footnote. It is a necessary condition for the optimistic scenario to work.
If even one of those unknowns does not resolve in defenders’ favor, the balance between attackers and defenders may not shift the way Schneier predicts. The last one is the most uncomfortable: an AI system used to defend infrastructure can itself be attacked by manipulating the data it analyzes. System logs crafted to deceive it, network inputs designed to alter its behavior, tickets written to make it classify something dangerous as harmless.
This is not the classic kind of isolated bug you fix with a patch. It is a problem that comes from the way these systems interpret input, context, and instructions. Maybe it will be mitigated. But treating it as an implementation detail is already a mistake.
AI-Generated Code Security Is Already a Present Problem
Meanwhile, who is producing the attack surface for the next cycle?
Not only security researchers with specialized toolchains. Mostly ordinary developers using LLMs today: REST endpoints generated with ChatGPT, SQL queries completed by Copilot, input validation logic written with Cursor. Code tested on the surface, committed because it works, deployed because deadlines do not wait.
As Schneier’s analysis makes clear, these models were not trained with security as their primary objective. The code they produce can contain non-obvious SQL injection, error handling that exposes stack traces, latent SSRF, race conditions on shared resources. None of these patterns is always easy to catch in a quick code review, and in an AI-assisted review the model may not flag them unless explicitly instructed to look.
There is also an incentive problem, already visible in structural AI token billing: AI tools reward usage volume and perceived speed, not the robustness of the code produced. Coding assistants optimize for completion speed. More code generated faster is a positive product signal, regardless of security correctness.
The consequence is organizational before it is technical: the bottleneck is no longer writing code, but understanding what that code authorizes, exposes, and makes possible. AI has pushed production forward. Security review has not moved at the same pace.
TechMonk’s Take
Schneier is right about the long horizon: AI may give defenders better scanners, faster patches, deeper automation, and more capable defensive agents. The point where his scenario becomes fragile is the temporal framing. He presents the age of instant software as something still to come, when we are already inside it.
Only the software does not get discarded.
It gets deployed and forgotten.
The Asymmetry Between Attackers and Defenders Does Not Disappear With AI
Betting that defenders win requires extremely high coverage, much closer to completeness than anything attackers need.
Run the math. In a large codebase, even a small percentage of missed vulnerabilities can be enough to leave critical paths open. An offensive AI system that finds a single useful attack surface across distributed infrastructure is, for an attacker, an enormous success.
The asymmetry is not only about tool speed. It is about the mathematics of coverage. Defense means covering everything. Offense means finding one path.
AI has accelerated both sides. It has made potentially vulnerable code generation faster, and it has made vulnerability discovery faster. But it does not automatically follow that the ratio shifts in favor of defenders.
The defenders of 2030 will inherit the attack surface being built today, including every LLM-generated commit accepted without serious security review.
The Most Concrete Risk Is Code Nobody Really Designed
Schneier frames the problem mainly as external attackers versus defenders. The more concrete risk for the next cycle is internal.
AI-generated code does not only produce classic vulnerabilities: SQL injection, SSRF, race conditions. The worse risk is quieter. Endpoints created without an authorization model. Tenant separation left implicit. Ownership checks applied in one place and forgotten in another. Business logic that looks plausible, passes functional tests, and embeds broken access control at the design level.
A banal example: an LLM generates an /invoices/{id} endpoint that checks only whether the user is authenticated, not whether that invoice actually belongs to that user. The functional test passes, because the right user can see the invoice. The bug is not syntactic. It is not an injection. It is a mental-model error.
Static analysis tools can catch some signals, but they often lack the domain context needed to know whether that access is legitimate. The problem is not just “the code is vulnerable.” It is “the system allows something the product should never have allowed.”
Organizations with strict compliance requirements — GDPR, SOC 2, financial services, healthcare — will find themselves auditing code that passed many technical checks and failed on a design principle. It is not an external attack. It is failure by construction.
The question Schneier does not ask is the most concrete one: what datasets were the models writing today’s code trained on? If the answer is GitHub, and GitHub contains twenty years of insecure patterns from developers who were not thinking about security, then AI reproduces those same patterns faster and with less scrutiny.
Schneier’s optimistic defender will probably arrive. They will have better scanners, faster patches, more coordinated agents.
The problem is what they will find when they get here.
Because the code being generated today is not waiting for that future. It is entering repositories, deployments, internal systems, public APIs. And every commit accepted without security review is not instant software.
It is debt. With execution privileges.