When Software Creation Outpaced Execution Governance

For most of computing’s history, the hard part was making the software — writing it, building it, shipping it, getting it to run at all. That constraint quietly shaped how the field thought about risk. If creation was slow and expensive, there was time, between writing code and running it, for review, testing, and judgment to catch up.

That constraint is dissolving. AI now generates working software faster than most organizations can verify the conditions under which it should be allowed to run. Code is produced, committed to repositories, wired into tools, granted credentials, packaged into extensions, and pushed toward deployment — often before anyone has fully understood the execution surface it creates.

The useful way to read this is not “AI writes code now.” It is that the bottleneck moved. Creation is no longer the scarce, governed step. Execution is.

A concrete version of the shift

In March 2026, one of the most depended-upon packages in the JavaScript ecosystem — axios, with over a hundred million weekly downloads — was briefly compromised. The mechanism is worth stating plainly, because it is so ordinary: a long-lived publishing token that had never been revoked was used to publish poisoned versions directly, bypassing the project’s modern build pipeline, code review, and branch protections. No code inside axios itself was changed. The only modification was the addition of one new dependency. There was no matching commit, tag, or release in the source repository — the bad versions existed only in the registry.

And then, on every machine that ran an install during the exposure window, that dependency executed — automatically, with the user’s full privileges, because the package manager runs install-time scripts by default.

Security tooling actually caught it; an automated scanner flagged the malicious package within minutes. It ran anyway, on every install that happened before it was pulled. That gap is the entire point: published code became running code at install time, and detection without enforcement is insufficient. Being flagged is not the same as being blocked at the moment execution opens.

The reading everyone reaches for

The standard account is a supply-chain-security story: revoke stale tokens, enforce provenance, scan dependencies, harden the registry. All correct. All necessary. And all of it lives where the industry’s attention already sits — at access (who is allowed to publish) and at detection (what got flagged).

What that account underdescribes is the moment that actually did the damage: install time. The point where published code became running code on someone else’s machine, under whatever conditions happened to hold there, with nothing asking whether it should.

The execution-boundary reading

Creating and publishing software is a creation event. Installing and running it is an execution event. The axios case is a clean illustration of what happens when creation outpaces any governance at the execution-opening moment: the package became executable everywhere, by default, the instant it was pulled — provenance unverified, age unconsidered, behavior unexamined, against no policy about what an install step is even allowed to do.

The deeper failure was not that a bad version was published. Bad versions will always be published. The failure was that publication flowed straight through to execution with nothing standing at the boundary asking the only question that mattered: should this code be allowed to run here, now, given its current provenance and the current state of this environment?

Notice what this reframes. The developer tooling — the package manager, the install step, the extension, the repository hook — had been treated as a productivity surface. Operationally, it had become an execution surface. The same is true of every AI coding assistant, every agent that writes and runs code, every “generate and deploy” workflow. They are not only faster ways to create. They are faster ways to open execution.

Generated readiness is not executable readiness

This is the distinction the speed of AI tends to collapse. Generated readiness asks whether the software appears to work. Executable readiness asks whether it should be allowed to run, touch systems, or create consequence under current conditions. A passing test, a clean scan, an earlier approval — each speaks to the first. None of them, on its own, answers the second.

And the second can change after the first is satisfied. Authority shifts. Dependencies shift. Credentials shift. The operating environment shifts. The intended use expands until the code touches a surface it was never reviewed for. Treating “it appears to work” as “it is allowed to run” is how a harmless prototype becomes operational exposure.

Why this generalizes

AI accelerates precisely the side of this that was already outrunning governance. When software can be generated in seconds, the number of paths from “created” to “executable” multiplies — more dependencies pulled in, more generated snippets dropped into production, more extensions and automations standing up with credentials, more actions issued by agents. Each is a place where creation can reach execution before authority, dependency state, credential state, and deployment conditions have been re-checked.

The same shape appears across domains: a generated automation that routes a financial action, a generated workflow that surfaces a patient record, a generated integration that affects benefits or eligibility. The constraint that used to protect us — that making software was slow enough for judgment to keep pace — is exactly the constraint AI removes.

The question the boundary forces

The interesting question is no longer whether AI can write the software. It plainly can. The question is when generated or published software should be allowed to become an executable path:

Should this code be allowed to run — here, now — under the current authority, the current dependency and credential state, and the current deployment conditions?

Software creation is no longer the bottleneck. Execution governance is. This is the boundary I work on through Foresight Oversight: not governance as a record of how software was created, but the structure that decides whether a generated action path should be allowed to open. The organizations that absorb the speed of AI-built software safely will be the ones that put something at that boundary — not only at the point of creation, and not only at detection, but at the moment running becomes possible.