Single-Use Software: Write It, Run It, Delete It

Last month I needed to reconcile two CSV exports with slightly different column conventions — a task I'd normally solve by finding a diff tool, reading its docs, and fighting its assumptions for twenty minutes. Instead I asked an agent to write me a fifty-line script. It ran once, produced the answer, and I deleted it. Total elapsed time: ninety seconds. The script never entered version control, never got a name, and never will be seen again.

That transaction — write it, run it, delete it — is quietly becoming the default mode for a whole class of work. When code generation costs approach zero, the cheapest correct move is often a bespoke one-off, not a general-purpose tool. Finding an existing utility means searching, evaluating, installing, configuring, and trusting it. Generating a disposable one means describing what you want. For narrow, well-specified tasks, the second path now wins on every axis except one: nobody is watching what gets created.

That last part is the interesting bit. Single-use software deletes the maintenance burden, which is genuinely revolutionary — most of software's lifetime cost is maintenance, and ephemeral code pays none of it. But it also deletes two things we didn't realize were load-bearing: institutional learning and the security review checkpoint. This post is about what the new economics actually buy you, what they silently cost, and how to decide when a throwaway has earned the right to become a real product.

The Economics Actually Did Flip

For seventy years, software creation was constrained by ROI. Every line had to justify its cost, which is why the industry's early output was payroll, tax, and ERP systems — permanent software for permanent problems. Anish Acharya's framing captures the shift: creation used to be constrained by financial justification; now it's constrained only by imagination. His examples are deliberately frivolous — a custom math game to gate his kids' screen time, a photo-sharing app exclusively for pictures of his cat. Neither would have survived a build-versus-buy analysis in 2020. Neither needed to.

The venture predictions around this are aggressive — Tomasz Tunguz expects ephemeral apps to outnumber SaaS applications "perhaps millions to one," and Andrej Karpathy has argued for "super custom, super ephemeral one-off apps by default." But you don't need to believe the maximalist version to see the mechanism. Geoffrey Litt identified it back in 2023: the historical bottleneck of end-user programming was converting fuzzy intent into formal, executable code, and LLMs dissolved that bottleneck.

The result isn't just that professionals code faster. It's that the population of people who can produce working software expanded by an order of magnitude, and the minimum viable audience for a piece of software shrank to one.

For engineers, the calculus shows up in small daily decisions. You need to resize a batch of images, transform a JSON dump, or scaffold a quick internal dashboard. The old decision tree — is there a tool? is it maintained? does its license allow this? does it handle my edge case? — collapses into a single prompt. The generated script handles exactly your case, with your column names, your directory structure, your weird date format. General-purpose tools carry the complexity tax of everyone else's requirements. A one-off carries none.

What You're Actually Trading Away

The honest accounting has three lines, and most enthusiasm for disposable software only reads the first one.

The win: zero maintenance liability. The oldest wisdom in this industry is that code is a liability, not an asset — you pay for it every year it exists, through dependency updates, security patches, and the cognitive load of everyone who has to read it. Single-use software is the one category that genuinely escapes this. Code that no longer exists cannot rot, cannot be exploited next year, and cannot confuse a future maintainer. Deleting the script isn't waste; it's the whole point.

The first loss: institutional learning. When a team maintains a shared tool, the tool accumulates knowledge. Every bug fixed after a production surprise, every edge case handled after a customer complaint, every performance tweak after an incident — these are lessons encoded as code. Andreas Kirsch's critique of the ephemeral-software hypothesis lands hardest here: "Tests catch what you anticipated. Production catches what you didn't."

A regenerated script resets that accumulation to zero every time. If five engineers on your team each generate their own CSV reconciler this quarter, the sixth engineer's version will contain none of the fixes the first five discovered. The organization keeps re-learning the same lessons and paying for them with the same small errors — each too minor to notice, collectively a real tax.

The second loss: the review checkpoint. Traditional security tooling shares one assumption: code enters a repository. Code review, SAST scans, dependency audits, license checks — the entire governance pipeline triggers on commit. Single-use software is born outside the repository and dies before anyone looks. It runs with your credentials, on your laptop, against production APIs, and leaves no artifact to audit. The checkpoint didn't get faster; it got skipped.

Disposable Code, Durable Side Effects

The governance problem sharpens once you notice an asymmetry: the code is ephemeral, but its side effects aren't.

A throwaway script that emails a customer list has permanently sent those emails. A one-off migration helper that wrote to the production database has left rows behind that some future system will treat as authoritative. Ken Huang's framing is exact: the risk of AI-generated disposable code is "completeness without comprehension" — output that behaves like production software, owned by no one who can assess its security posture. The concrete failure modes are mundane and already documented: generated servers that bind to 0.0.0.0 instead of localhost and accept connections from the coffee-shop Wi-Fi, hallucinated package names typosquatted by attackers (the "slopsquatting" pattern), credentials pasted into a script that was "just for one run" but landed in a shell history or a temp directory.

The aggregate numbers say this isn't hypothetical. IBM's 2025 Cost of a Data Breach report broke out shadow AI for the first time: incidents involving unsanctioned AI tools accounted for 20% of breaches studied and added roughly $670K to the average breach cost. Sixty-three percent of breached organizations had no AI governance policy at all. Single-use software is shadow AI's fastest-growing form factor — it's not an unapproved SaaS subscription that shows up in expense reports, it's code that materializes, executes, and vanishes between two audit intervals.

The uncomfortable implication: you cannot govern this with the existing pipeline, because the pipeline's trigger event — code entering a repo — never fires. Point-in-time review doesn't work on software whose lifetime is shorter than the review queue. The controls have to move from the artifact to the blast radius: what credentials could a generated script use, what networks can it reach, what data can it touch. Sandboxed execution environments, scoped short-lived tokens, and egress monitoring govern ephemeral code the way code review never can — they don't need to see the code, only to bound what it can do. That reframing, from reviewing artifacts to constraining capabilities, is the single most useful mental shift for anyone responsible for an engineering org where agents now write most of the small stuff.

The Promotion Problem

The subtler failure mode isn't the script that runs once. It's the script that was supposed to run once.

Everyone who has operated real systems knows this lifecycle: the throwaway gets a second run, then a cron entry, then a Slack channel asks for a small feature, and eighteen months later a "temporary" script with no tests, no owner, and no error handling is load-bearing infrastructure. Disposable software doesn't eliminate this failure mode — it industrializes it, because the volume of throwaways is now a hundred times higher and each one is competent enough to survive unexamined.

So the discipline that matters isn't "never write throwaways." It's having explicit promotion criteria — the checklist that converts a one-off into a product, deliberately rather than by accretion. Mine looks like this:

• Third run rule. The first run is a one-off. The second is a coincidence. If you reach for the same generated script a third time, it's a tool, and it needs a repo, an owner, and a name. Regenerating it fresh each time feels free but silently discards every fix the previous run taught you.
• Anyone-else rule. The moment a second person uses it, the ambiguity in your head about what it does becomes their production incident. Shared use demands written behavior — a README and pinned dependencies at minimum.
• State rule. The instant a throwaway writes to durable storage that anything else reads, it stops being disposable regardless of how often it runs. Kirsch's point about integration boundaries applies in full: the thin code between systems is the hardest to test and the most consequential to get wrong, and silent data corruption is strictly worse than a loud crash.
• Unattended rule. Anything scheduled — cron, CI, a webhook — is a service, full stop. Services need monitoring, alerting, and a person who gets paged. A generated script on a schedule with none of those is an outage with a delay timer.

The point of the checklist isn't bureaucracy; it's making the promotion visible. The failure isn't writing disposable code — it's disposable code acquiring permanence without anyone deciding it should.

Two Categories, Two Rulebooks

Where does this settle? Not at "all software becomes ephemeral" — the strongest counterarguments hold. Systems with persistent state, stable interfaces users have built mental models around, and auditability requirements will stay durable, because code is where operational ambiguity gets concretely resolved, and regenerating it re-opens every question the old version had answered. Regeneration-by-default recreates the classic rewrite failure, just faster.

But "single-use software is a fad" is equally wrong. The economics are real and they're not reverting. What's actually happening is that software is splitting into two categories with different rulebooks. Durable software keeps the old rules: repos, reviews, tests, owners, changelogs. Ephemeral software gets new ones: sandboxed execution, scoped credentials, bounded blast radius, and explicit promotion criteria for anything that tries to cross into the durable category.

The teams that will handle this well aren't the ones that ban throwaway generation — that battle is already lost, and the productivity is too valuable to ban anyway. They're the ones that make the two categories legible: cheap, safe, genuinely disposable paths for one-off work, and a deliberate, low-friction gate for the small fraction of throwaways that turn out to matter. Write it, run it, delete it — and know exactly which ones you're not allowed to delete.