Disposable vs. Durable Code
The split between cheap, throwaway AI-generated code (prototypes, scripts, experiments) and expensive, trust-earning production code that must be maintained and operated over time — a distinction defined by maintenance cost, risk and expected lifetime, not by who or what wrote it.
Also known as: disposable code, durable code, disposable software, throwaway code, disposable vs durable
How authors use it
Oldest first (extraction date when no publication date is known).
| Author | Their term | Their meaning |
|---|---|---|
| Disposable Code Is Here to Stay, but Durable Code Is What Runs the World Charity Majors · 2025-07-29 | Disposable code | Code generated and used once or briefly with no intent to maintain it -- prototypes, scripts, experiments, hobby apps -- where low stakes make it acceptable to skip testing, review, and long-term understanding. |
| Disposable Code Is Here to Stay, but Durable Code Is What Runs the World Charity Majors · 2025-07-29 | Durable code | Code that runs critical, high-stakes systems (banking, medical, aviation, infrastructure) where failure is costly and unpredictable, requiring sustained investment in testability, observability, and incremental, trust-building rollout. |
| Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 | disposable code | Code treated as throwaway: regenerated from the latest specifications whenever an agent has trouble patching it, rather than maintained |
Documents (4)
- Guillaume Barrois' Post Guillaume Barrois · 2026-10-08 source ↗ Reader 🖥️
Building features at the speed coding agents enable creates 'cognitive debt' — an accumulating gap between what has been built and what the engineer still understands — which, like technical debt, must be deliberately repaid (through upfront planning, disposable prototyping, and PR-based review) or it will erode confidence and slow you down. - Software Design in the Agentic Age: Place Your Bets Mathias Verraes · 2026-07-07 source ↗ Reader 🖥️
In the agentic age, code-level quality becomes automatable but high-level software design and rigorous (ideally executable) specifications remain decisive human-led work, so under deep uncertainty about AI's payoffs and externalities teams should bet on design rigour, executable specifications, and the ability to revert from agent generation back to human engineering. - Bliki: Vibe Coding Martin Fowler · 2026-05-21 source ↗ Reader 🖥️
Vibe coding — building software by prompting an LLM without ever looking at the generated code — is a distinct practice from agentic programming, useful only for disposable software, because forgetting the code exists produces serious risks in security, maintainability, and correctness. - Disposable Code Is Here to Stay, but Durable Code Is What Runs the World Charity Majors · 2025-07-29 source ↗ Reader 🖥️
Software development is splitting into two durably separate domains -- cheap, AI-generated disposable code and expensive, trust-earning durable code -- and because the cost of software is defined by its maintenance rather than its authorship, generative AI changes who can write code but does not eliminate the need for the fast-feedback-loop engineering discipline (tests, CI/CD, observability) that durable code has always required.
Propositions touching this concept (7)
By publication month, oldest first (extraction month when no publication date is known).
2025-07
- explicitSoftware development is bifurcating into two domains -- disposable code and durable code -- with diverging skill sets, tool chains, and definitions of success, likely to become separate disciplines over time.
- explicitReliability should be matched to actual need rather than maximized, because each additional order of magnitude of reliability costs roughly an additional order of magnitude in engineering effort (the 10x/9 rule); it makes sense to replace expensive durable code with cheap disposable code wherever a lower reliability bar will satisfice.
- explicitDisposable and durable code are not separate codebases but coexisting modalities -- a feature often starts as a disposable prototype and is converted to durable code once its shape is clear, and the ease of generating ancillary tests/docs should mean more of them actually get written.
- implicitThe seemingly limitless supply of cheap disposable code is itself an illusion that depends entirely on an enormous substrate of durable code running reliably underneath it (OS, device drivers, network protocols, databases, cloud infrastructure) -- disposable code's cheapness is parasitic on durable code's expense.
2026-01
- explicitIncreased AI code output correlates with increased code duplication, review time, and churn, but these negative side effects scale roughly linearly with output rather than exploding faster than output — and AI power users actually require marginally less review time relative to the volume of durable code they deliver.
2026-02
- explicitAI-enabled non-professionals writing their own disposable software (hobbyists, an accountant building her own automation) expands who writes software without threatening the professional discipline, paralleling the hobbyist wave that accompanied the rise of personal computers in the late 1970s/80s.
2026-05
- implicitThe category 'disposable software' is stable and identifiable in advance.
Tensions
Is code a durable artifact humans must keep reading, or an ephemeral byproduct regenerated from a spec?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Code is potentially ephemeral — a disposable byproduct the agent regenerates from the spec on demand; the spec, where a developer's taste now lives, is the thing that matters.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Code must remain human-legible and maintained; agents behave better as 'engineers' moulding a persistent codebase than as 'compilers' regenerating from scratch.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Skeptical of throwaway regeneration; unconvinced code can be discarded and regenerated at will — bets that code largely stays.
Assessment: The retreat's own 'largest divide' (Ördög). It is unresolved inside the room and inside the individual essays: Herlein concedes the deterministic 'code is the better spec' counter is 'hard to wave off', and Ördög reports being ironically pulled toward the dark-factory camp by her own good-code practices. The crux is whether a fuzzy prose spec can ever be the durable source of truth when the stated quality bar is verifiability — a tension none of them resolves.
How much of the build pipeline should run with no human reading the code (the 'dark factory')?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Toward a largely self-evolving software factory where a feature request is 'magically built' into the system; humans build and operate the factory and intervene only at explicit hand-off points.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Deliberately bounded autonomy — keep humans in the loop.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are only safe for organisations that already have high test coverage, skilled engineers, and a high-quality engineering culture; most should cover their fundamentals first.
Assessment: Not simple optimism vs pessimism but a disagreement about preconditions and hidden costs. Ocytko's is a projection of where tooling is heading; Bangser and Verraes both supply reasons the projection is unsafe by default — learning-loss and missing prerequisites. Bangser has the stronger argument that the loss is structural (you cannot buy back organisational learning), which even an improving platform does not address.
Reversibility as a hedge vs a one-way commitment to deeper autonomy.
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Build systems that can revert from agent generation back to human engineering.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): Head toward a self-evolving software factory — a progressive, largely one-directional build-out of autonomy and platform capability.
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Commit early and hard, because adoption is a compounding flywheel and the lead becomes a permanent structural moat.
Assessment: Incompatible risk models. Verraes treats deep AI-dependence as the danger to insure against; Herlein treats not-committing as the existential danger. They cannot both be the rational strategy: reversibility trades some upside for exit options, while flywheel-commitment trades exit options for compounding lead. The tie-breaker is empirical (will access/economics deteriorate?) and neither has evidence — Fowler's 'tokenpocalypse' data leans slightly toward Verraes.
Does low-level code quality matter intrinsically, or only instrumentally (via token economics)?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Code-level quality is automatable and he is 'unsure it matters much in its own right apart from token cost'; you bet on it via an asymmetric payoff, not intrinsic worth.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Code quality matters intrinsically because code good for AI and code good for humans are the same thing.
- Fragments: July 6 (Martin Fowler (Jul 6)): Contested and leaning toward design mattering, but on new grounds — token cost as a proxy for architectural quality.
Assessment: The disagreement is about the grounds of the fundamentals-revival, not just its truth. If quality matters only via token cost (Verraes, and Fowler's proxy), the case for it is contingent on token economics and evaporates if tokens get cheap; if it is intrinsic (Ördög), it survives cheaper tokens. This makes the popular slogan 'quality still matters' quietly unstable — the same conclusion rests on incompatible foundations.
Will the classic fundamentals (especially DDD / domain modelling) actually deliver this time — is the revival evidenced or merely asserted?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
- Notes from FOSE Europe (Giles Edwards-Alexander): Skeptical: domain modelling kept being proposed, but it is not a new idea and never became the standard before — why would it suddenly work now?
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Evidenced: feeding an agent an explicit domain model first yields better code structure and database performance, and bounded contexts also reduce token cost.
- Jimmy Nilsson's Post — reflections after the Thoughtworks 'Future of Software Development' retreat (Jimmy Nilsson): Asserted: DDD, XP, TOC, TDD, BDD, CD are 'more important than ever' in the agentic age.
Assessment: The single slogan 'fundamentals matter more' spans concrete evidence (Verraes), unargued assertion with admitted bias (Nilsson), and active skepticism (Edwards-Alexander) — from attendees of one retreat. This directly exposes the 'the fundamentals are agreed' assumption below: the cohort's flagship convergence is doing a lot of work with very uneven support underneath it.
Is code a durable artifact to be maintained, or an ephemeral byproduct regenerated from a more durable source (spec/objective)?
from: What is the future of software development in the agentic/AI age?
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Code is (or is becoming) ephemeral — a disposable byproduct the agent regenerates from the spec; the spec is 'the point.'
- Fragments: February 4 (Martin Fowler (Feb 4)): When coding is free, the specification-plus-tests becomes the durable, primary engineering artifact.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Specifications could replace code as the source of truth, but throwaway regeneration is a bet he is unwilling to make; keep code durable and revertible.
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Code endures because the winning agents behave like engineers moulding a maintained codebase, not compilers regenerating from scratch.
- What Survived Contact (Sam Ruby): The durability question is a category error — what endures is neither the code nor the prose spec but the objective and its oracle.
Assessment: The most-cited open question of the corpus, and genuinely unresolved (Herlein: 'no consensus here. None.'). The 'code is the better spec' counter is strong — code is unambiguous, executable, deterministic, whereas a prose spec is reinterpreted each run, which sits in tension with verifiability being the quality bar. Ruby's move is the most defensible: it dissolves the code-vs-spec fight by locating durability in the evaluation rather than any representation. Verraes and Ördög expose the load-bearing empirical unknown — nobody has data on regenerate-vs-patch cost or on long-term evolvability of agent-maintained code.
How far should software be automated — toward the fully-autonomous dark/software factory, or held back to bounded autonomy with humans in the loop?
from: What is the future of software development in the agentic/AI age?
- Why did Martin Fowler invite 60 engineers to a ski resort? (Ivett Ördög): Full automation is genuinely viable in context and she is 'ironically' being pulled toward the dark-factory camp.
- Looking back at the Future of Software Engineering unconference (Bartosz Ocytko): The aspirational endpoint is a largely self-evolving software factory; humans build and operate the backbone rather than the application.
- AI Is Changing Software Engineering. The Fundamentals Still Matter. (Abby Bangser): Bounded autonomy — keep humans in the operational loop; automated remediation must stay an intentional decision.
- What Survived Contact (Sam Ruby): Self-healing has stalled halfway on purpose: diagnosis is automated, remediation withheld from the machine.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Dark factories are safe only for orgs that already have high test coverage, skilled engineers, and a quality culture; most should cover fundamentals first and stay revertible.
Assessment: The spectrum runs from Ördög/Ocytko (full automation is arriving and desirable) to Bangser/Ruby/Verraes (deliberately withhold the last step). The decelerationists have the better of the safety argument today — Ruby's 'nobody will cede the blast radius' and Bangser's 'removing humans removes learning' identify concrete, unmet prerequisites — but Ördög's context-dependence (backends, COBOL) shows the boundary is domain-specific, not absolute. The real disagreement is less about capability than about who absorbs the blast radius when an autonomous fix goes wrong.
Strategically, is the right move to accelerate adoption to build a permanent lead, or to decelerate and hedge against AI's risks?
from: What is the future of software development in the agentic/AI age?
- We've Stopped Arguing About Whether AI Changes Software (Greg Herlein): Accelerate: adoption compounds into a flywheel, and the gap can harden into a permanent structural moat the slowest never close.
- Software Design in the Agentic Age: Place Your Bets (Mathias Verraes): Decelerate and hedge: build systems that can revert from agent generation back to human engineering.
- Fragments: July 6 (Martin Fowler (Jul 6)): Treat good design as a hedge against AI-dependence risk rather than as a race to maximal dependence.
Assessment: Nearly opposite bets: Herlein optimizes for a world where AI keeps getting cheaper and better and first-movers win permanently; Verraes and Fowler optimize for a world where AI gets costlier, curtailed, or unreliable. Herlein's 'permanent moat' rests on flywheel logic plus a single secondhand anecdote and ignores technology-diffusion catch-up dynamics; Verraes and Fowler's hedge is cheap insurance but under-examines whether reversion is actually achievable once specs, agents, and toolchains are deeply embedded and human familiarity has eroded. The disagreement is ultimately a bet on the trajectory of token economics, which nobody in the corpus can price.
Open gaps (4)
- incompleteThe 'spend more time planning' practice presupposes the planning skill and domain expertise to build a solid mental model upfront — the post doesn't address whether a less senior engineer, who may lack that expertise, can use the same practice to the same effect.Guillaume Barrois' Post — read next: Look for evidence on whether upfront-planning-as-cognitive-debt-mitigation holds across seniority levels, not just for experienced practitioners like the author.
- incompleteFowler offers no mechanism for detecting when 'disposable' software is silently graduating into consequential software. The disposable/consequential boundary is treated as legible to the author, but in practice it is one of the most common failure modes in software organisations — internal scripts becoming critical infrastructure.Bliki: Vibe Coding — read next: Cutler on institutional overload and shadow systems; classic discussions of 'tactical' vs 'strategic' programming (Ousterhout, Philosophy of Software Design); literature on shadow IT and end-user computing.
- incompleteNo engagement with the cultural/professional question of whether vibe coding deserves the name 'coding' at all, or whether legitimising it as a coding practice (rather than, say, 'spec-driven prototyping') invites exactly the diffusion problem Fowler is trying to push back against.Bliki: Vibe Coding — read next: Naur on programming as theory building; the broader 'what is programming' debate that has resurfaced post-LLM.
- incompleteThe article asserts organizations and engineers will correctly classify code as disposable or durable and apply the right rigor accordingly, but doesn't address the organizational failure mode where disposable-grade AI output gets shipped into durable systems because AI makes both look equally finished -- exactly the quality-cost externalization pattern documented elsewhere in this corpus (rising bug/incident rates correlating with AI adoption).Disposable Code Is Here to Stay, but Durable Code Is What Runs the World — read next: extract-faros-acceleration-whiplash documents the empirical version of this risk (bugs per developer up 54%, incidents-per-PR up 242.7% with rising AI adoption) and is worth reading as a counterweight to this article's relatively reassuring 'don't freak out' tone.