The demo passed. Two weeks later, the queue filled.

Honeycomb kills its oldest Kafka node with a cron job every Tuesday. Charity Majors offers that detail as the thing her team trusts most: the bootstrapping and rebalancing work precisely because the node can be destroyed and regenerated on a schedule, and the commitments that matter live somewhere other than the node itself. Her argument in a recent essay is that the opposite holds for application code. The reason you can’t regenerate a codebase the way you regenerate a Kafka node is that you don’t understand it well enough, and you tend to find your dependencies by breaking them.

Majors dates the shift to Opus 4.5. Since it shipped, she argues, AI generates code roughly as good as the median software engineer for common patterns, faster and more cheaply. She credits the agentic harnesses that became usable across 2025, the loop of tool use, function calling and MCPs wrapped around the model, more than any single model release. The practical result is that the economics of writing code inverted. Code that was expensive and slow to produce, and therefore treasured and reused, became close to free and instant, and therefore disposable.

That inversion is where Chad Fowler’s writing on Phoenix architectures comes in. Fowler, who coined “immutable infrastructure” in 2013, argues that immutable infra, stateless services, containers and blue-green deploys all rest on one premise: never fix a running thing, replace it. Cheap regeneration pushes that premise out of infrastructure and into application code. Mutation accumulates entropy; replacement resets it. His “Deletion Test” asks you to imagine deleting an implementation entirely. The usual objection, that you can’t just throw the code away, decodes to a set of things you don’t actually know: what behavior is required, which failures are unacceptable, which invariants must always hold, how to tell a correct new version from a broken one, and which bugs are load-bearing fixes for forgotten edge cases. Those are evaluation problems. Code becomes precious when it is the only place that knowledge lives. The line Majors singles out is Fowler’s description of code as a cache: a materialized view of understanding, useful while current and disposable when stale.

For anyone operating these systems, the work moves to validation and to the places knowledge gets encoded. Majors is blunt that humans are the weakest link at validation: the repetition and nitpicking that code review leans on is exactly what people are bad at and machines are good at. The techniques that matter come from the two disciplines software engineering has tended to look down on, operations and QA: characterization and behavioral tests that encode what the system does rather than what it should do, capture and replay, traffic splitting, and observability. Running nondeterministic code in production forces the instrumentation teams should have had all along, and that is her central claim: nondeterministic systems demand more engineering discipline. Production stops being what happens after development and becomes a stage of it.

The caution worth keeping is about where value actually sits. Majors argues value is backed by durability, not disposability. Users do not want a UI that rearranges itself every morning, or financial transactions that complete most of the time, so determinism is not going anywhere at the layers that touch persistence and people. The opening she sees is narrow and real: the share of teams that work in short, fast feedback loops has always been small, maybe five percent, and cheap code generation brings that within reach of more of them. The payoff comes from encoding the knowledge in engineers’ heads into the system, because that knowledge is unavailable to the model until someone writes it down.

She stops short of claiming that all code ends up generated to a spec with no human reading it. Whether that works at all depends on what a spec can be, and, as she puts it, anyone who has survived a painful database migration should have some humility about formalizing users’ expectations into something replayable and automatable.