I'm sorry, but you still have to think

DHH commissioned AI-assisted rewrites of Campfire Once from Ruby on Rails into Rust, Elixir and Go, and the results reveal the pitfalls of delegating design choices to agents without inspecting code. Because prompts omit many non-functional constraints, the rewrites made divergent, language-independent trade-offs: the Rust build dropped CSRF tokens and Redis for in-process queues, while the Elixir version stayed closer to the Rails semantics. The Rust code also mixed blocking database operations and synchronous locks into an async runtime, which blocks worker threads and harms concurrency. These implementation details demonstrate that coding isn’t “solved” by AI - engineers must understand runtimes, I/O, and locking to avoid catastrophic performance regressions.

Benchmarks compounded the confusion: closed-loop tests emphasized throughput and hid arrival-pattern effects and backpressure behavior. Under heavy load the Rust rewrite initially delivered a tiny fraction of notifications because tokio::sync::broadcast was bounded to 256; raising capacity boosted delivery but exploded worst-case latency and memory use. Elixir handled delivery better under some loads but timed out many HTTP requests and used far more RAM. The takeaway is concrete: single metrics mislead, capacity and failure modes are design choices, and sensible bounds and explicit trade-offs are required for reliable systems - you still have to think.