News · 2026-10-12

A Campfire rewrite critique puts reliability ahead of headline throughput

Software developer Piotr Sarnacki argues that AI-assisted application rewrites still require people to define compatibility, reliability and architectural trade-offs explicitly. His October 11 essay examines Campfire rewrites whose headline throughput can obscure changed behavior and delivery failures. The newsworthy point is a public challenge to evaluating agent-built software by speed or a convincing first version alone.

Key facts

• Sarnacki cites a test reporting delivery of only 1% of new-post notifications in the Rust rewrite under heavy load.
• The essay appeared October 11 and examines AI-assisted rewrites of Campfire Once.
• The notification result is attributed to Zach Daniels’s test, rather than independently reproduced here.
• The primary source is Sarnacki’s essay.

A faster service is useful only if it still performs the service people need. That is the distinction Sarnacki draws in “I’m sorry, but you still have to think.” The essay is an engineering argument about what prompts and benchmarks leave implicit. It does not dismiss the ability of coding agents to generate working implementations.

The background is a set of AI-assisted rewrites associated with DHH’s Campfire Once. Moving an application between languages can look like a well-bounded task: the original already exists, and an agent can inspect its behavior or implementation. But a rewrite also changes choices about storage, queues, authentication, latency and failures. Unless those decisions are specified or tested, the new application may optimize a different problem.

Sarnacki says the Rust version dropped a cross-site request-forgery token and Redis-backed queues, while the Elixir version stayed closer to the original Rails behavior. These are claims in his account, not findings from a fresh source-code audit. They matter because a performance difference between versions cannot then be cleanly credited to the language or the model. The implementations are no longer controlled substitutes.

A concrete analogy is replacing a delivery company with a fleet that drives much faster but leaves some parcels at the depot. Parcels per hour measured at the loading gate can look excellent. Parcels that reach the recipient measure the customer’s actual requirement. Likewise, accepting requests or processing a benchmark loop is not equivalent to reliably delivering notifications under load.

The essay’s most vivid number is the reported 1% notification-delivery rate for the Rust version. It cites another person’s experiment, so the figure should remain attached to that provenance. It is not an independently verified universal property of the rewrite. Its editorial value is to identify a failure mode a throughput graph can hide, rather than to provide a definitive ranking of programming languages.

The underlying mechanism is missing specification. A prompt such as rewrite this application faster does not state whether messages must survive a crash, what compatibility means, how much memory may be used or whether throughput should outrank latency. The model must fill those gaps somehow. A syntactically successful result can therefore embody consequential product decisions nobody explicitly approved or even noticed.

The established lesson on program synthesis explains why the specification is part of the task. The lesson on property-based testing offers a complementary way to express broad behavioral rules. Neither automatically solves the problem: the chosen properties still have to match the service’s real obligations.

The Hacker News discussion contains an important counterargument. Translating an existing program should be particularly suitable for AI because many difficult decisions are already encoded in the original. That is a plausible reason to expect success. It also makes fidelity checks especially important: the agent has a source of behavior to preserve, but success depends on recognizing which details are requirements rather than accidental implementation choices.

Practitioner comments also describe review as work transferred from the producer to the reviewer. A rapidly generated implementation can demand substantial effort from someone who must explain it, maintain it and diagnose later failures. Those comments are self-reports in a single forum, not measured productivity evidence. They fit the essay’s narrower claim that generating code does not eliminate the need for an accountable engineering model of the system.

The ArtCraft repositories provide a related contemporary example. Their disclosed file-exchange gaps show why building an application and preserving a stranger’s document are different verification targets. In both cases, the decisive question is what the test measures and what important behavior sits outside it.

The caveat is that this story is about a documented critique, not an independently audited rewrite competition. It offers a practical standard for future demonstrations: name the behavior being preserved, disclose changed architecture, measure customer-visible completion and explain the failure conditions. Faster implementation becomes more valuable when those requirements are made testable, because reviewers can then distinguish progress from a change in what the software promises to do.

Primary source, verified: read the paper →

Ground Truth. (2026, October 12). A Campfire rewrite critique puts reliability ahead of headline throughput. Ground Truth. https://groundtruth.day/news/sarnacki-campfire-rewrites-reliability-review.html

@misc{groundtruth:sarnacki-campfire-rewrites-reliability-review,
  title  = {A Campfire rewrite critique puts reliability ahead of headline throughput},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {oct},
  url    = {https://groundtruth.day/news/sarnacki-campfire-rewrites-reliability-review.html}
}

Topics: coding-agents · software-engineering · reliability · evaluation