Build1 publisher2 min readPublished
Hansson's agent-built Rust Campfire posts a 166-fold benchmark gain on code he never inspected
David Heinemeier Hansson's agent-written Rust port of Campfire served 36,120 room-page requests a second to Rails' 217 in 37signals' own benchmark. A parity harness checks its behavior against Rails, but the numbers are company-run and stop short of production traffic.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- Hansson had coding agents port 37signals' Campfire chat app into Elixir, Go and Rust, then asked whether readability matters when people no longer read most of the code.
- The Rust port keeps Campfire's existing SQLite database, storage layout and signed cookies, retaining the Rails app's data and much of its interface.
- In the same repository benchmarks, posting a message ran 25 times faster, and a test with 10,000 connected clients delivered 73 times as many chat messages per second.
- Hansson described the app as small, said the work ran on two personal subscriptions, and estimated that some conversions took under two hours.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Teams that hand implementation to agents now have a public case for choosing a language on runtime cost and testability, with how the code reads to its author weighed less.
- exposure Operators of an agent-built port inherit the calls the harness cannot make: choosing test coverage, deciding which trade-offs are acceptable, and responding when a failure slips past the tests.
- cost Rust's slow compiles add time to every generate-and-validate cycle, so an agent workflow pays that cost on each change it attempts.
- precedent Behavioral parity against an existing app, on the same data and the same observable output, gives later agent-port claims a concrete bar to meet.
A parity harness in the repository compares what Rails and the Rust port produce: rendered HTML, the live document structure, accessibility trees, assets, WebSocket frames and screenshots [12]. Hansson says he never inspected the generated code directly [2]. RuntimeWire describes the workflow as delegating implementation, validating the output with automated checks, then judging the resulting application [20]. The harness is careful work. According to RuntimeWire, it makes the experiment more inspectable than a claim that an agent simply "rewrote" an app [17].
Those checks fix behavior at the moment of comparison. A screenshot diff flags that a page changed. It does not explain why. RuntimeWire's assessment is that tests like these cannot by themselves show that later changes will be easy to trace, that workloads the tests never ran will behave the same, or that the generated code stays safe to modify [13].
Hansson's position is conditional. For code he writes himself he still prefers Ruby, and he wrote that his interest in Rust is as a "prompt compile target" [4]. He also said he had not written code by hand in a while [16]. On Rust's costs, he conceded slow compile times and said he has no interest in learning its intricacies [14]. That is a workable stance for an author and a harder one for whoever gets paged when the port fails. His larger argument is that agents do not need frameworks for the same reasons human developers do [15].
The benchmark rig was one AMD Ryzen AI MAX+ 395 machine with four pinned hardware threads per app, production images, identical seed data and the median of three runs [9]. Divide the room-page results [7] by four threads and Rails served about 54 pages a second per thread, against 9,030 for Rust [1]. If those threads were saturated, each Rails request took roughly 18 ms of thread time and each Rust request about 0.11 ms [2]. For a real deployment to see that ratio, its bottleneck has to be the one this test hit: application work on a page render, over data shaped like the seed set. RuntimeWire notes these are 37signals' own measurements, not an independent benchmark or a record of production traffic [10]. By its reading, the numbers show neither that customers will get a 166-fold speedup nor that a real Campfire deployment needs that much capacity [10].
I think the stronger near-term case for the port is operational. The Rust build consolidates several runtime pieces into one executable [6], and RuntimeWire suggests infrastructure consolidation may be the immediate practical reason to run it [19].
What to watch
- An independent benchmark, or production traffic figures, for the Rust Campfire build.
- Whether 37signals moves the Rust version past beta and runs it for real customers.
- The first substantive change to the Rust code after the port, and whether an agent or a person diagnoses what breaks.