DHH, creator of Ruby on Rails, commissioned AI agents to rewrite Campfire Once — a chat application — from Rails into Rust, Elixir, and Go. The twist: he deliberately avoided reading the generated code, treating the exercise as a test of whether programming expertise plus AI delegation could replace direct code engagement. Piotr Sarnacki's forensic analysis of the results delivers a verdict the vibe-coding movement won't enjoy. The non-functional divergences alone are damning. The Rust rewrite dropped CSRF tokens and replaced Redis with in-process queues — architectural decisions with real security and reliability implications that were never specified in the prompt. The Elixir version stayed closer to the Rails original, not because Elixir demands it, but because the LLM's coin flip landed differently. Every ambiguous question — backwards compatibility, latency vs. throughput, memory budgets, crash recovery behavior — got answered implicitly by the model, invisibly to the person who thought they were in charge. The code-level problems compound the architectural ones. The Elixir version funneled all SQL queries through a single sequential process, killing read concurrency. The Rust version committed a subtler sin: some database operations run as blocking calls inside an async runtime. In Rust's cooperative scheduling model (tokio), a blocking 100ms query pins an entire worker thread. Sync locks held for 10ms produce the same bottleneck. These aren't edge cases — they're the kind of mistakes that surface under production load and are invisible in happy-path testing. Benchmarking exposed the next layer. DHH's original benchmarks measured only throughput — requests per second — and declared Rust the winner. Zach Daniels then measured notification delivery under load and found the Rust version delivering just 1% of new-post notifications versus Elixir's 100%. But Sarnacki's deeper analysis reveals even this comparison is misleading: the closed-loop benchmark let Rust process roughly 4x more requests (6-7k vs ~1.7k), generating proportionally more notification events. At a constant 100 requests/second, Rust delivered ~14% of events while Elixir hit ~60% — but Elixir timed out on ~23% of HTTP POST requests, and its worst-case event delivery latency reached 180 seconds. The broadcast channel capacity story is the essay's sharpest illustration of hidden trade-offs. The Rust version used tokio::sync::broadcast with a capacity of 256. Raising it to 16,384 boosted delivery from ~14% to ~90% — superficially beating Elixir. But pMAX latency exploded from 11 seconds to over 130 seconds. Sarnacki argues the original fail-fast behavior was actually better design: disconnecting lagging clients forces a reconnect that fetches current state, while silently queuing 130 seconds of stale notifications is strictly worse UX. Meanwhile, the Elixir version's unbounded GenServer mailboxes consumed 1.8GB of memory during the stress test — trading message loss for OOM risk. The meta-lesson cuts across languages. Elixir's BEAM runtime is genuinely excellent at concurrency, but it doesn't eliminate the need to set bounds on mailboxes, manage memory under load, or decide what failure mode is acceptable. Rust's cooperative async model demands explicit yielding discipline, but its fail-fast defaults can be an advantage if you understand them. Neither language's AI-generated code made these trade-offs consciously — they were accidents of generation, discovered only because humans read the code and ran adversarial benchmarks. The essay is a direct rebuttal to the emerging consensus that senior developers can operate as pure prompt-engineers, delegating implementation entirely. The evidence shows that every underspecified prompt produces an implicit architecture — and implicit architectures are the ones that fail in production. You can delegate typing. You cannot delegate thinking.
