Ephemerality is safe where embedded operational knowledge has low reach

Type: note · Status: seedling · Tags: learning-theory

Kirsch's essay against the ephemeral software hypothesis names four structural barriers to treating software as disposable: edge cases discovered through deployment, state and integration surfaces, interface stability expectations, and ambiguity/auditability requirements. These look like separate engineering concerns, but they share a deeper structure: each is a case where the software embeds operational knowledge that has reach — knowledge that transfers across runs, versions, users, or audit events. The reach of the embedded knowledge, not the complexity of the code, is what makes ephemerality unsafe.

Kirsch's barriers all describe cross-context transfer

The common structure is not "these systems are complicated" but "a resolution discovered once must keep applying elsewhere." Reach is the word for that transfer. Software stops being safely disposable when it becomes the medium where those resolutions live.

Edge cases are post-deployment knowledge that transfers. A fix for a timezone edge case in billing applies to every future release of the billing system, and often to sibling systems handling the same data. Discarding the fix forces re-discovery — not just of the code, but of the explanation for why the edge case arises. The fix has reach because the explanation does.

State and integration surfaces encode constraints that persist across versions. A migration handling a legacy column format embeds knowledge about how past and present schemas relate. That knowledge applies to every future migration touching the same data and often to other systems reading the same store. The constraint is structural, not accidental — it has reach because the data model does.

Interface stability means the software has become a medium for other people's learned expectations. A consistent API response shape or UI behavior is operational knowledge that users and client systems have internalized. Regenerating the interface differently forces re-learning across every consumer. The reach sits in the expectation, not the code.

Auditability demands that resolved ambiguities remain traceable. A spec saying "handle errors gracefully" admits many implementations; once deployed, the specific resolution becomes load-bearing for compliance and incident response. The resolution has reach because external processes reference it.

Reach predicts where persistence pays

Reach is not code size, sophistication, or business importance. A tiny tax patch can have high reach if every invoice depends on it. A 200-line exploratory script can have low reach if nothing depends on it after today. What matters is how many future contexts benefit from preserving a resolution rather than rediscovering it.

Ephemeral computation prevents accumulation, but accumulation is only worth its overhead when what you'd accumulate has reach. A one-off analysis script embeds operational knowledge — which columns to join, how to handle nulls — that is specific to this query. Discarding it is cheap because the next query needs a different resolution. A production billing service embeds knowledge — edge cases, migration history, audit trails — that transfers across releases, users, and regulatory events. Discarding it forces the same ambiguity to be re-resolved under pressure.

Kirsch's durable artifact stack is therefore not sentimental attachment to code. It is a way of storing high-reach operational knowledge in a form future runs, humans, and systems can inherit.

The boundary

This gives a cleaner prediction: the ephemeral/malleable boundary sits where the same operational resolution must survive across contexts.

  • Low-reach zone (ephemerality safe): one-off analyses, spike implementations, local scripts, prototypes. The operational knowledge fits the immediate context and does not transfer far. Re-derivation costs roughly the same as preservation.

  • Boundary zone: tools that start local but pick up users, persistent state, integrations, or compliance obligations. The artifact may still be easy to regenerate, but the knowledge it must preserve is no longer local.

  • High-reach zone (malleability required): production services, shared internal tools, stateful systems, regulated workflows. The embedded knowledge persists across contexts. Codification is how it gets committed to durable, inspectable, testable artifacts. Re-derivation costs grow because more runs, people, and surrounding processes depend on the same resolutions.

Kirsch's five-step malleable software model describes this trajectory in practice: a prototype starts with mostly local knowledge, then deployment discovers memory that must be carried forward.

Connection to vibe-noting

The vibe-noting framing decomposes LLM-assisted work along inspectability and verifiability axes. Reach does not replace those axes — it explains when inspectability becomes worth paying for. Inspectability is the mechanism; reach is why that mechanism matters.

This sharpens the vibe-coding/vibe-noting parallel. Vibe coding works well in low-reach zones: the code lives in an inspectable substrate, and the cost of discarding it is often tolerable. Vibe-noting is harder because its output is usually meant to transfer — a good note should help future humans and agents in contexts the original session did not anticipate. High-reach knowledge work therefore needs a persistent inspectable substrate, or ephemeral computation prevents accumulation and every session starts from zero.

What this framing does and doesn't explain

The reach framing predicts where durability pressure appears but not which artifact should carry the knowledge. AI may expand the low-reach zone by making some medium-reach knowledge cheaper to re-derive from logs, traces, or tests — but that relocates the durable substrate rather than eliminating it. Kirsch's falsification criteria test whether this relocation is happening at scale.

The asymmetry remains: AI can make re-derivation cheaper, but it cannot remove the structural reach of constraints like data model compatibility, user expectations, or regulatory traceability. Somewhere, that knowledge still has to survive.

Relevant Notes: