Disposable Code Is Here to Stay, but Durable Code Is What Runs the World

Charity Majors · article · 2025-07-29 source ↗ Reader 🖥️

Coordination Cost Disposable vs. Durable Code Feedback Loops Trust

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.

theoretical · argumentative — Primarily a conceptual reframe (software is bifurcating into two domains with different cost models) rather than a call to specific action, though it implies practical consequences (keep investing in tests/CI/observability, don't panic about durable engineering disappearing).

Structure

Part	Role
Framing the debate: is writing code a valuable skill or an obsolete one?	sets up the false dichotomy the article resolves
Disposable code vs. durable code, defined by stakes and the cost of failure (bank transactions, medical results vs. prototypes, scripts)	core distinction
The cost of software is defined by its maintenance, not by who or what wrote it	the mechanism that explains why the distinction matters and why AI doesn't collapse it
Durable software is about trust, which is earned only through time in production, not through test coverage alone	elaborates why durable code resists being commoditized the way disposable code has been
Disposable and durable are modalities that coexist in the same codebase (prototype -> durable conversion)	qualifies the bifurcation claim -- it's not two separate codebases, it's two postures toward the same code
AI's role differs by domain: in disposable code it may stop being considered 'software development' at all (a commodity skill); in durable code it accelerates the expensive parts (rewrites, instrumentation, anomaly analysis) without changing the cost model	conclusion / practical implication

Key terms

Disposable code Disposable vs. Durable 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.
Durable code Disposable vs. 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.
The 10x/9 rule (via Alex Ewerlof)
For every additional '9' of reliability (SLO) you target, the system becomes roughly 10x more reliable but also roughly 10x more expensive to build and maintain -- used to argue reliability should be matched to actual need, not maximized.
Durable software is about trust
Confidence in code is not a property that can be manufactured by test coverage alone; it accrues only from a track record of the code behaving correctly in production over time -- which is why durable code cannot be sped up the way disposable code generation has been.

Propositions

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.conf: high
explicitThe cost of software is defined by how well you expect to maintain, extend, migrate, understand, and fix it over its lifetime -- not by whether it was AI-generated, human-written, or how hard it was to write initially.conf: high
extendsGenerative AI Is Not Going To Build Your Engineering Team For You · p2 — Same author (Charity Majors), ~14 months later, sharpens her own earlier claim that 'writing code is the easiest part' into a named two-domain framework (disposable vs. durable) organized explicitly around maintenance cost.
explicitInvesting in fast feedback loops (frontloaded tests, CI/CD, observability) is the cheapest and easiest way to build good durable software, not overhead on top of 'real' development work.conf: high
supportsWhen AI Writes Almost All Code, What Happens To Software Engineering? · p11 — Both argue that a culture of automated testing, CI/CD, and observability is what determines whether AI adoption helps or hurts -- its absence makes regressions and outages 'hurt sooner' (Orosz) or means you don't get AI's efficiency gains at all (Majors).
explicitcorroboratedOnly companies that had already invested in reliability and observability before adopting AI are the ones currently realizing efficiency gains from AI -- AI has made fast feedback loops and software guardrails more important, not less.conf: high
supports ←Nick Tune's Post · p3 — Both argue that feedback loops and guardrails, not prompt quality alone, are what determine whether AI-assisted coding actually produces reliable results.
explicitTrust in a piece of code is earned only by exposing it to production reality over time in small, controlled increments -- no test suite can substitute for that accumulated track record.conf: high
supportsGenerative AI Is Not Going To Build Your Engineering Team For You · p3 — Both argue AI-generated code cannot be trusted on the basis of test coverage or review alone; trust/confidence has to be earned through time and exposure (production track record), consistent with the earlier article's 'read and revise line by line' stance.
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.conf: high
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.conf: medium
explicitIf disposable-code generation becomes easy enough, it will stop being considered 'software development' as a profession and instead become a general tech-literacy skill (like typing or spreadsheets) expected of workers in marketing, sales, product, and design -- with pay scales dropping accordingly.conf: medium
refinesGenerative AI Is Not Going To Build Your Engineering Team For You · p4 — Both make the same point -- that the 'AI is like a junior engineer' framing only fits disposable, throwaway code -- but this article gives that case a name and a cost-model justification ('disposable code') rather than treating it as a narrow exception.
explicitcontestedFor durable codebases, AI's most valuable contribution is not code generation but help with the genuinely expensive parts -- large rewrites that would previously have taken years, instrumentation, incident analysis, and anomaly detection -- which reduces the coordination tax on large groups by letting fewer engineers own more surface area with confidence.conf: high
contradictsThe Acceleration Whiplash · p3 — Majors argues AI mainly helps with the expensive, durable parts of software (rewrites, instrumentation, incident analysis) without upending the cost model; Faros' empirical data shows AI adoption correlating with rising bugs, incidents, and unreviewed merges in practice -- a more pessimistic read of the same transition this article frames reassuringly.
explicitEven an expert engineer who fully understands a change they're rolling out doesn't actually know what will happen in production, which is why durable engineering practice is about safe, incremental, tool-assisted rollout rather than confidence in one's own understanding.conf: high
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.conf: high

Arguments

Generative AI does not eliminate the need for the durable-software engineering discipline (testing, CI/CD, observability, incremental rollout); it raises the stakes of skipping it. strength: high

Explicit premises:

The cost of software is defined by its maintainability, not its authorship.
Trust in code is earned only through production track record, which AI-generated code has not yet accumulated.
Only organizations already investing in reliability/observability are seeing AI efficiency gains.

Implicit premises:

Organizations and engineers are capable of distinguishing which code they're writing belongs to which domain (disposable vs. durable) and applying the right standard accordingly.
AI-generated code defaults to looking equally 'finished' regardless of which domain it was meant for, creating a risk that disposable-grade code gets mistaken for durable-grade code.

Inferences:

If engineers or managers cannot reliably tell which domain a given piece of AI-generated code belongs to, the article's reassurance ('don't freak out') may understate the actual organizational risk of durable systems silently absorbing disposable-grade code -- a risk the article doesn't directly address.

Narratives

The progression from 'generate some code to do a thing, do the thing, throw it away' (design mocks, data scripts, hobby apps) contrasted with code behind bank transactions, medical results, and nuclear power plants.
→ Makes the disposable/durable distinction concrete and visceral before the author argues for it abstractly via the maintenance-cost framing.
A new feature starting life as a disposable prototype, then being converted into durable code once its shape comes into focus.
→ Shows that the two domains are not fixed categories of code but a trajectory a given piece of code can travel along -- supporting the 'modalities, not separate codebases' proposition.

Questions addressed

✅ Is writing code a valuable skill worth building, or an obsolete one on its way out (like cursive writing)?
Both -- it depends entirely on which domain (disposable or durable) the code belongs to; durable code remains a profession, disposable code is becoming a general skill set.
⭕ How will organizations and individual engineers reliably tell which domain a given piece of AI-generated code belongs to, especially as AI makes both kinds of code look equally polished on the surface?

Gaps

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).
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.
incompleteThe article predicts disposable-code generation will become a general tech-literacy skill rather than a profession, with pay scales dropping accordingly, but doesn't address what happens to the career ladder into durable-code engineering if fewer people ever practice the 'easy' coding tasks that traditionally built early judgment (the same early-in-career/apprenticeship concern raised elsewhere in this corpus).
Read next: extract-cacm-redefining-software-engineering-profession-for-ai and extract-dora-2025-state-of-ai-assisted-software-development both address how removing hands-on, lower-stakes coding work affects the pipeline into senior/durable-code engineering.