Dan Luu argues that coding agents have changed which projects are worth attempting. A custom compiler or database rewrite can look absurd under an old estimate of the work involved. His examples suggest reconsidering that estimate while keeping the testing bill firmly in view.

  • Build for a real bottleneck. Luu describes improving code search and Rust builds for his own workloads as model output becomes faster.
  • Keep the quality bar explicit. He reports a few hours of human work for personal tools. Making them dependable public products would take much more effort.
  • Count what the checking produces. He points to upstream Postgres issues uncovered while testing Michael Malis’s pgrust rewrite, even if the replacement itself never succeeds.

Luu says the gap between what a model can implement and what it can verify without help has been growing in his work. Yossi Kreinin’s response, included in the essay, warns that bigger opaque systems and narrowly optimized code can outrun their developers’ understanding.

Caveat: Luu explicitly says these examples lack rigorous benchmarking. They are practitioner reports, not a general productivity multiplier.

The Hacker News thread adds team bottlenecks, a caught failure, and a dispute over what pgrust’s evidence establishes.

What the thread adds

  • bob1029 — reports review and merging falling behind code generation: “It doesn’t matter how fast you write code if you can’t actually merge it and ship it to the customer faster too.”
  • majormajor — describes a model introducing fragile log-capturing machinery to expose an error: “it’s also really easy to end up with messy fragile stuff if you get lazy about reviewing the output.” In a follow-up, they clarify: “That example I mentioned didn’t make it to production.” The original prompter caught and fixed it before code review.
  • thepoet — offers a different personal project: “I built an SDK and apps that allows e-ink apps with sandboxing and permissions model, auto-updates, shared capabilities etc. to be built for Kobo”. This is their account, not an independently tested result.
  • fritzo — pushes beyond faster versions of existing tools: “What is the one thing that only you can specify, where your competitive advantage is maximized?”
  • malisper — acknowledges a version mismatch in the benchmark dispute: “the 0.4-beta source doesn’t prove anything about the benchmarked binary.” ClickBench removed the preview entry, alleging query-specific execution and result caching. Malisper disputes those mechanisms being used during the benchmark. verdverm asks for the missing history: “we don’t have the commits we need to audit”. In a later response, Malisper reports a new run of the open-sourced beta: “And now it’s been accepted”. ClickBench now lists fresh pgrust results dated October 25, backed by results committed to its repository. That is new evidence for the beta, while the earlier preview dispute remains separate.
  • malisper — describes translating C and Rust into Lean, a proof-checking language, to compare behavior. They report growing proof context slowing the work. sealeck asks: “What if there are bugs in this C,Rust->Lean compiler?” Malisper frames the goal as bug finding: “My goal is to find as many bugs as I can with the least effort.” That qualifies the verification claim; the translation itself remains an assumption.

HN handles are pseudonymous, with no public per-comment scores. The source order is HN’s ranking; these selected comments are a slice of the thread, not a consensus.