The “AI is going to kill us all” narrative is way too overdone, and it usually arrives without serious counterpoints. That is a problem, because the claim is being used to advocate for who may build the next generation of tools and under what permission regime.

This is not a new pattern. The world has been supposed to end thirty ways to Sunday, and the world’s resources have been supposed to run out several times over. Nuclear winter, overpopulation, peak oil, and The Limits to Growth–style scarcity forecasts all had large audiences. Some of those risks were real enough to take seriously. Most of the advertised collapse dates were not. Civilization is still here. The specific monster changes. The appetite for an ending-of-the-world story does not.

AI deserves a clearer description than that story provides. The object worth regulating is not a training run. It is the product that leaves the lab, the claim used to sell it, and the deployment that can injure someone.

AI Is Software, and It Is Also More Than a Spreadsheet Macro

AI is software. That is the practical starting point, and it is the part that keeps getting skipped.

A frontier model is a trained program: weights, inference code, tooling, and an interface that other software and users can call. It is versioned, copied, patched, rate-limited, and sold as a service. In that sense it is not a new kingdom of nature. It sits in the same family as compilers, databases, search engines, and industrial control software, even when the training run that produced it cost more than most companies will ever spend.

It is fair to say it is not just software in the casual desktop sense. The systems that matter now sit on specialized clusters, consume large amounts of energy and capital, and are increasingly wrapped in agents that can take actions rather than only emit text. When those systems are bolted onto cars, hospitals, markets, or networks, the blast radius is larger than a crashed app. Evaluation is harder than it is for a payroll script, and the people building the systems do not fully understand every internal representation the model learned.

That difference matters for engineering and for liability. It does not automatically justify a pre-approval regime for research and training. The artifact that leaves the lab, the thing customers pay for, and the thing that can harm someone is still a software system. We already have ways to inspect, constrain, recall, and punish software systems that are built or sold badly. The useful question is which of those ways we are willing to use, and which ones mainly raise the cost of entry.

The Desire for Regulation

Of course, many of these companies want regulation and auditors: It crushes competition.

A compliance stack that requires frontier-scale evaluations, embedded outside inspectors with employee-level access, incident bureaucracies, and agreements about the rate of progress is not a neutral safety layer. It is a moat. The labs that already have billions of dollars can staff it. The labs that do not, cannot. That outcome should be treated as a design feature of the proposal until proven otherwise.

The target here is not extra rules for aircraft software, medical devices, or weapons systems. Those settings already have regimes because the deployment itself is a specific, high-consequence use. The target is the other proposal: a license to train, a guild of approved model-makers, and a political bargain over how fast the field may move. Those are not the same thing, and collapsing them is how a capture project borrows the prestige of aviation law.

Regulating software development has been a debate for a long time. Doing it well is practically impossible without crushing the work — unless, of course, you already have billions of dollars. You can regulate fraud. You can regulate defective products. You can put extra rules on specific deployments in specific high-risk settings, the way we already do with aircraft software, medical devices, and safety-critical industrial controls. You cannot pre-approve every interesting training run without turning the field into a licensed guild.

When the same companies that spent years warning that the technology is too powerful to leave unsupervised then ask for common standards, in-house evaluators, and coordination on pacing, listen to the incentives. Safety language is cheap. A rulebook that only a handful of organizations can afford is not.

Creativity at the Extreme End of the Curve

People who work at the far edge of a hard technical field are often unusually creative. That is part of why the work happens there at all.

The same tail of the distribution can also come with a higher appetite for all-or-nothing stories. A mind that can hold a new system in view can also hold a vivid collapse of that system in view, and then treat the collapse as if it were a measurement. That is not a diagnosis of every researcher in the field, and it is not an argument that talent is a character flaw. It is a reason not to confuse fluency with evidence.

If you spend your days on a problem most people cannot follow, it is easy to assume that your fear is the missing data. It is easier still to turn that fear into fundraising, recruiting, and a request that the state slow everyone else down. Vividness is not a forecast. Facility with a scenario is not a substitute for a base rate.

None of this requires assuming bad faith in every lab. It does require refusing to treat the loudest worry in the room as a measurement. If we are going to talk about regulating conduct, the conduct that deserves more attention is fear-mongering and overclaiming used as marketing and lobbying. Overstate extinction risk when you want money, talent, and a veto over rivals. Soft-pedal the same claim when liability gets close. That pattern is not safety engineering: It is narrative management.

Public Markets Reward and Punish. Private Markets Insulate.

Accountability is a mechanism, not just a brand.

Companies that sit inside public markets can face a sell-off. Investors can leave. Boards get asked questions they cannot answer with a blog post. SpaceXAI, through SpaceX’s public reporting, and Gemini, through Alphabet’s, at least have that pressure, because they sit inside companies that must report to public markets. Other labs sit behind the safety of private markets, where they will not face a sell-off when the story breaks.

Private capital can be patient, and patience is sometimes a virtue. It is also a shield. If the product injures people, misleads customers, or is sold on claims the engineering cannot support, the correction should not depend on whether the cap table is fashionable. A public listing is not a moral halo. It is a feedback loop, and feedback loops beat priesthoods.

Let Existing Law Reach the Conduct

We have a technical field to build in. Instead of regulating development, let actions against AI companies regulate their behavior.

That will not always be a civil matter. Some fact patterns already support criminal charges: unauthorized access and damage to protected computers under the Computer Fraud and Abuse Act, wire fraud where deception is used to obtain money, and other existing offenses when the conduct fits them. Most product failures, overclaims, and negligent deployments will stay in civil court, under negligence, product liability, contract, and consumer-protection statutes such as Section 5 of the FTC Act. Both tracks already exist. We do not need a new licensing office in order to say that a company may be sued, fined, or prosecuted for what it shipped or what it claimed.

Common law is built for this kind of problem. Courts take real cases, find facts, and establish precedent that later courts can use. That process is slower than a press cycle and less flattering than a safety summit. It has a useful property that preemptive software licensing does not: it attaches to what a company did, not to whether the company can afford the approved auditor.

This is the steelman worth answering. Once systems can plan and act, a lawsuit after the fact punishes yesterday’s failure. It does not, by itself, bound a system that can take a new action tomorrow. That is a real limit. It is not an argument for a license to train. The action that harms someone is a deployment and a product. Aviation did not become safer by turning every interesting workshop into a certified factory. It became safer by putting extra rules on airframes and flight software in use, then attaching records, lawyers, and surviving firms to the failures. Duty of care belongs on the product, the deployment, and the claim — not on the right to train a model.

U.S. courts are already testing whether particular software and AI features should be treated as products for liability purposes, rather than as services beyond the reach of those doctrines. That is the right kind of argument to have. It is specific. It can distinguish a chatbot’s design from a user’s misuse, and a model vendor from a downstream deployer. A statute that creates a safe harbor for labs that publish a framework and hire the inspector of record points the other way.

Companies become more cautious when poor engineering has a price. They do a better job when stunting for publicity has a price. Watch which side the largest private labs prefer when the word in the sentence is “liability,” not only “safety.”

Iterating on an Existing Method

Cutting-edge technology has inherent risk. There is no clean escape from that fact, and there should be no pretense that a permission regime can delete it. A rule that tries to make frontier work safe in advance will not make it safe. It will decide who is allowed to take the risk.

What is already palatable is narrow, and it should stay narrow. Extra rules belong where the software is put into a setting that already carries them: aerospace, medicine, defense, and other safety-critical industrial controls. Fraud, defective products, negligent deployment, and deceptive claims already have law. Those are rules about conduct and use. They do not require a priesthood of model-makers.

What is not palatable is a general license to train, a political bargain over the rate of progress, or a compliance stack that only a handful of organizations can afford. Those proposals borrow the language of aircraft certification while pointing at a different object: not the plane in the air, but the right to design one.

What Leading Looks Like

Leading a technical field is not the same thing as narrating one.

Leading looks like shipping systems that users and competitors can evaluate, not only a closed circle of evaluators with badges and laptops inside the lab. Leading looks like being willing to lose a lawsuit, or face a criminal case, if the engineering or the sales pitch was bad. Leading looks like refusing to ask the state to slow everyone else down so one roadmap can catch its breath.

The United States does not need a priesthood of model-makers setting the legal pace of software. It needs products that work, claims that can survive discovery, and markets and courts that can punish the ones that do not. Treat AI as what it is in practice: a software system with unusual scale and unusual reach. Reward the builders who can stand behind it. Let fear, used as a business model, meet the law that already exists.