I'm sorry, but you still have to think
-
AI-Assisted Language Rewrites:
- Piotr Sarnacki analyzes DHH's experiment of using AI agents to rewrite Campfire Once from Ruby on Rails to Rust, Elixir, and Go without personally reading or writing the target code.
- The experiment demonstrates that without detailed and specific prompting, critical architectural decisions become random coin flips because AI implicitly chooses trade-offs.
-
Flawed Implementations and Discrepancies:
- The AI-generated implementations varied wildly in constraints and backward compatibility:
- Rust dropped CSRF token verification and replaced external Redis queues with in-process queues.
- Elixir stayed closer to the original Rails implementation, making direct cross-language comparisons invalid.
- The generated Rust code exhibited major concurrency flaws:
- It mixed non-async blocking database queries and locks into Tokio's cooperative async runtime, causing worker threads to stall.
- The generated Elixir code routed database queries through a single sequential process, hurting read concurrency.
- The AI-generated implementations varied wildly in constraints and backward compatibility:
-
Misleading Benchmarks and System Trade-Offs:
- Initial closed-loop benchmarks focused narrowly on throughput, masking severe functional failures:
- Zach Daniels tested notification delivery under load and found Rust achieved only a 1% delivery rate compared to Elixir's 100%.
- Subsequent tests using constant-arrival rates revealed deeper architectural trade-offs:
- Rust failed fast by disconnecting lagging clients once its bounded in-memory broadcast channel (capacity 256) filled up, maintaining 0 HTTP errors.
- Elixir accepted all events via unbounded GenServer mailboxes, but suffered 23% HTTP request timeouts, ~180-second latencies, and ballooned memory usage to 1.8GB (risking OOM crashes).
- Increasing Rust's broadcast capacity boosted delivery rates to ~90%, but spiked latency above 130 seconds, demonstrating that neither language provides a "magic bullet" without explicit architectural tuning.
- Initial closed-loop benchmarks focused narrowly on throughput, masking severe functional failures:
-
Core Takeaways:
- Software engineering remains inherently about trade-offs (e.g., latency vs. throughput, failing fast vs. queuing indefinitely).
- Programming cannot be considered "solved" by AI agents; developers must still think critically, understand failure modes, and review the code.
Hacker News Discussion
-
Brandolini’s Law and "Workslop":
- Commenters heavily highlighted the Bullshit Asymmetry Principle (Brandolini's law): generating low-effort AI slop takes seconds, but thoroughly analyzing, debunking, and reviewing it demands immense effort and domain expertise.
-
Shifted Review Burden and Tech Debt:
- The ratio of verification capacity to generation capacity is broken. Individuals appear productive by generating mass amounts of code, but that "productivity" merely shifts an unsustainable cognitive and time burden onto reviewers.
- Submitting LLM output without understanding it acts as a "debt machine," creating brittle codebases that fix surface symptoms without addressing root bugs.
-
Accountability and Professional Standards:
- Participants argued that committers—not LLMs—must be held accountable for subpar code quality, recommending strict pushbacks against massive, unreviewed AI dumps in pull requests.
- Some noted the organizational friction where management praises rapid output, penalizing careful reviewers for "slowing down progress."
-
Limits of Automation and Cognitive Bias:
- Discussion touched on the human cognitive bias toward tolerating poor machine output simply because it is automated or cheap.
- Commentators warned that without human comprehension and careful verification, software evolution and correctness will hit severe productivity ceilings.
