speed ships the flaw

At Honeycomb, a cron job kills the oldest Kafka node every Tuesday. Nothing breaks, because the bootstrapping and rebalancing are repeatable, the data regenerates, and the commitments that matter live somewhere other than that specific node. You cannot do that to your application code, and in a recent essay on charity.wtf, Charity of Honeycomb argues that the inability to regenerate code on demand is a sign you do not understand it.

That frames a larger claim about AI and code: generation got cheap, and the honest response is more rigor, not less.

For most of 2025 the mainstream position was that AI-generated code was slop and might always be slop. The essay dates the turn to November 2025 and Opus 4.5, after which, by the author’s assessment, models could produce code roughly as good as the median software engineer for common patterns, and do it faster and cheaper. Opus 4.5 is treated as the tipping point rather than the cause. The groundwork was agentic harnesses, the loops that wrap a model in tools, which became usable in mid-2025 on precursors going back to late 2024, alongside a year of tool use, function calling and MCPs.

What actually changed, per the essay, is the economics of producing code. Writing it went from slow, expensive and carefully curated to effectively free and instant. Once regeneration is cheap, code stops behaving like an asset and starts behaving like a cache. The author borrows Chad Fowler’s description: a materialized view of understanding that is useful while current and disposable when stale. Fowler coined “immutable infrastructure” in 2013, and the argument runs straight out of that lineage.

Stateless services, containers, blue-green deploys and infrastructure as code all rest on one premise: never fix a running thing, replace it. Mutation accumulates entropy; replacement resets it. Fowler’s claim, which the essay adopts, is that cheap regeneration pushes that premise out of infrastructure and into application code, so editing in place becomes the risky move.

The sharpest tool here is Fowler’s Deletion Test. Imagine deleting the entire implementation. What you lose is rarely the code itself; it is the answers the code quietly encoded: what behavior is required, which failures are unacceptable, which invariants must always hold, how you would tell whether a new version is correct, and which bugs are deliberate fixes for forgotten edge cases. Those are evaluation problems, not code problems. Code feels precious exactly when it is the only place that knowledge lives.

This is where speed ships the flaw. If generation is instant but the only record of what the system is supposed to do is the code a human last read, then regenerating that code faster than anyone can validate it ships whatever is wrong with it. The essay’s answer is to move rigor to where it can keep pace, which means production and validation. The techniques already exist, mostly inherited from operations and QA: behavioral and characterization tests that encode what the system does rather than what it ought to do, capture and replay, traffic splitters, evals and tests run in production, tracing and real observability. Production stops being what happens after development and becomes a stage of it.

The author is blunt that humans are the weakest link at validation. The nitpicking, the repetition, the habituation to patterns are the parts of review people are worst at, and a poor place to plant the argument that software still needs people. Nondeterministic code in production forces the instrumentation and the evals that disciplined teams should have been running anyway. The claim is that nondeterministic systems demand more engineering discipline, not less, and that the return on that discipline is nonlinear. The author also reckons model gains have been leveling off, and that even with no further advances the past year has unleashed enough to reshape software for a long time, which argues for treating this as a shift to absorb rather than a curve to ride.

For anyone running these systems the practical reading is narrow. Before you let a model regenerate a component, you need an evaluation harness that can tell you the regeneration is correct against observed behavior, not against someone’s memory of it. Without that, cheap regeneration is a faster way to introduce drift. The author puts the share of teams already working in short, fast feedback loops at well under ten percent, and treats AI tooling as the thing that could finally make that reachable for everyone else.

The ceiling on all of it is durability. Bits are cheap and governed by logic and language, but anything with value resolves against physical systems: persistence on one side, user experience on the other. People do not want the buttons in Slack to move every morning, and they do not want financial transactions that complete most of the time. Determinism stays, so disposable code only pays off behind a validation layer that can prove the new version still behaves.