AI rewrote the app, but someone still had to understand it

The starting point of this essay is DHH's experiment: he had an AI agent rewrite Campfire from Ruby on Rails into Rust, then Elixir and Go, without reading the code himself. The author's argument is that the rewrites differ for reasons that have nothing to do with the language. Unstated requirements get decided by default. The Rust version dropped the CSRF token and replaced Redis with in-process queues, while the Elixir version stayed closer to the original. If you do not specify those choices, the agent makes them for you, silently.

The numbers are where it gets concrete. The benchmarks everyone cited were closed-loop, which measures raw throughput but not how a system behaves when users keep arriving at a steady rate. Under that kind of load the picture changes. At 100 POST requests per second, the Rust build returned no HTTP errors but delivered only about 14% of events to clients, dropping lagging connections so they reconnect and refetch. The Elixir build delivered about 60% of events but timed out on roughly 23% of those POSTs, with event latency reaching nearly 180 seconds and memory climbing to 1.8GB. Raising Rust's broadcast buffer from 256 to 16384 lifted delivery to about 90%, but pushed maximum latency past 130 seconds. These are decisions about backpressure and what to do when you cannot keep up, not a verdict on which language is faster.

The point is not that AI coding fails. It is that the judgment did not go away. You still have to set the constraints, reason about how the thing breaks, decide what to drop and what to queue, and refuse to draw a conclusion from a single benchmark number.

Why it matters

If you hand a rewrite to an agent, the parts it decides quietly, dropping a security token, swapping a queue, choosing how to behave under overload, are exactly the ones that hurt in production. You either specify them and read the result, or you ship choices you never actually made.