pgrust essay urges developers to build more ambitious software with AI

The post starts with Michael Malis, of pgrust, who has been showing the author interesting things since early this year and saying "[W]e should be more ambitious with the software we build." The author uses that line as the thesis. Malis said it in casual chats, and the author notes he himself would say "can" rather than "should", so the wording should not be over-read.

Pgrust draws skepticism because so many AI-generated rewrite projects are low-quality. The author says that if he did not know Malis he would assume pgrust was vibe-slopped too, and he trusted Malis without looking into it. Only while checking pgrust for this post did he find that Malis's testing is thorough enough to uncover real bugs in Postgres. The examples he links: a numerical bug that can make valid SP-GiST operations fail, a format cache bug that can give incorrect JSONPath results, a pgcrypto bug that can make later operations fail, multiple memory safety bugs in the dictionary loader, and a money overflow bug. He does not say pgrust is bug free, but argues the testing is substantial and that even if pgrust never succeeds, the attempt has improved Postgres in a durable way. The main pitch for pgrust, he says, is performance, and some of its optimizations might land in Postgres or Clickhouse if it fails.

His distinction is between consumers and builders. As a consumer, he sees slow software whose makers tout slop benchmarks, and low-quality software is more common than ever. As a builder, it does not matter that most such projects are junk: projects too large to be feasible in the past can now be built, and with reasonable testing and benchmarking they can reach good-enough quality to use.

His own examples start with OpenAI's plan to use Cerebras for its top models, not just fast-but-low-quality ones like 5.3-Codex-Spark. He imagined a state-of-the-art model 10x to 100x faster and asked what would bottleneck on his machine: ripgrep, compiling Rust, and syscall and filesystem overhead. He then built a regex engine that can be tweaked to beat other general-purpose regex libraries on a workload he cares about; a ripgrep fork that uses the regex engine's native code compiler and is faster on his Codex ripgrep workloads (a "just for fun" project, and he notes a text index would be the better solution); and a Rust interpreter that sped up builds for his projects. Switching development from Mac to Linux alone improved syscall and filesystem overhead a lot. He says someone who knows nothing about regexes, string matching, compilers or interpreters would have needed a year or more to reach "works for me" quality on this set; it took a low single-digit number of hours of his time. Reaching a useful-product or open-source bar would take much more work.

He reads Malis's point as: it does not occur to people to do things that are now easy. For weeks he saw Twitter complaints that Rust compilation is slow, though he thinks it was not much of a bottleneck then, before 5.6 Sol and 6 Astra were available on Cerebras. His diagnosis is that people carry a pre-agentic cost model. Ten years ago, someone who wrote a new compiler because theirs was slow was the kind who never ships; most productive programmers still have that aversion, though it is now reasonable.

Second example: an Azul AI. With GPT-5.1/5.2 and no AI background, it took about 5 hours of his time to get something superhuman at matched time controls, and about 20 hours to reach what appeared to be the strongest AI at the time, including stronger against humans than an AI used to cheat on Board Game Arena. Models then gave almost entirely wrong suggestions and needed heavy steering; asked to implement a technique from a paper, they produced something that only looked like it. Gabriel Cangussu recently built an AI that demolishes the author's, and as far as the author can tell it took substantially less time. From talking to Cangussu, one key difference is that Fable 5.1 and Opus 5.5 understand board game AIs much better. Based on his own experience with Fable 5 and Cangussu's, he thinks models can now read a paper and implement its techniques.

Third example: a toy eval of verification and test techniques with GPT-5.6 Sol implementing zstd on medium and xhigh. He redid it with GPT-6 Astra, which was so good he had to find different evals. For zstd, 6 Astra passes all registered tests more than 99% of the time across all conditions, even ones that impair performance such as TDD, at about $1 to implement zstd. He switched to the IMAP RFC, which 5.6 Sol could not do effectively, and Pandoc.

He pushes back on the claim that software is now solved. Newer models one-shot more things, but he ends up working on more ambitious things where models still struggle, and he gets farther from "it just works" with each model because the gap between what a model can verify without handholding and what it can implement keeps growing.

A closing note says he is trying to write posts in half an hour with little review, which means less well-supported posts. He did a quick comparison rather than rigorous benchmarks, and says there are maybe twenty or thirty things in the post he would like to do but has not. He has not written up the Rust interpreter, which he says got a 50x speedup on cold compiles and 2x on warm or cached builds. An appendix quotes a comment from Yossi Kreinin, with permission: if the author publishes this, Kreinin will publish a response explaining that most people should be less ambitious with the software they build with AI or they will experience abject failure. Kreinin thinks many problems lack clear pass/fail criteria for agentic loops. The comment is cut off in the available text.

Key facts

• Michael Malis of pgrust says "[W]e should be more ambitious with the software we build"; the author backs it with pgrust's testing, which found real Postgres bugs (SP-GiST, JSONPath, pgcrypto, dictionary loader, money overflow).
• The author says a regex engine, a ripgrep fork and a Rust interpreter took a low single-digit number of hours, versus a year or more before; the interpreter got a 50x speedup on cold compiles and 2x on warm builds, from a quick comparison, not rigorous benchmarks.
• His Azul AI took about 5 hours to reach superhuman with GPT-5.1/5.2 and about 20 hours to reach the strongest at the time; Gabriel Cangussu later built one that beats it, in less time.
• On a zstd eval, GPT-6 Astra passes all registered tests more than 99% of the time across all conditions at about $1; the author moved to the IMAP RFC and Pandoc as harder evals.
• Yossi Kreinin's quoted comment in the appendix argues that most people should be less ambitious with AI-built software or face abject failure.

Why it matters

The post makes a builder's case: AI models have advanced enough that projects once too big to attempt are now feasible, and the author thinks people still price work using a pre-agentic cost model. The pgrust example shows why dismissal on news aggregators can miss real engineering, since its testing has found actual bugs in Postgres. The author also argues that better models do not make software solved: the gap between what a model can implement and what it can verify without handholding keeps growing.

Who it affects

Mainly working programmers and builders deciding what to attempt with AI coding agents, including those who complain about slow tooling such as Rust compilation, ripgrep or filesystem overhead. The author contrasts them with consumers of software, who face more low-quality, AI-generated projects and inflated benchmark claims. Maintainers of projects like Postgres are affected too, since pgrust's testing has produced bug reports.

How to use it

The practical advice in the post is to take the problems you complain about and try fixing them directly, at "works for me" quality. The author's examples: a custom regex engine, a ripgrep fork and a Rust interpreter for his own workloads, and switching development from Mac to Linux for lower syscall and filesystem overhead. For larger projects he says reasonable testing and benchmarking can make the result good enough to use. Reaching a useful-product or open-source bar would take a lot more work.

How solid is it

Weak to moderate. It is a first-person opinion post, and the author says he wrote it in about half an hour with little review and without rigorous benchmarking. The 50x and 2x figures come from a quick comparison, and he has not written up the Rust interpreter. He did not look into pgrust himself beyond finding the Postgres bug examples, and trusts Malis personally. The Azul and zstd claims are his own accounts of his own experiments. The text is cut off mid-sentence in Yossi Kreinin's appendix comment.

Risks and caveats

The author admits the post is less well supported than his standard style. Success stories come from one experienced builder's personal projects, and the source gives no performance numbers for pgrust and does not say whether it is production-ready. Kreinin's counterpoint is that for most people, being less ambitious is the better advice, and that many problems lack clear pass/fail criteria for agentic loops. The author himself notes that most rewrite projects are slop, and that checking model output is time consuming for anyone without background in the domain.

“As far as I can tell, these problems are problems because people are implicitly carrying around a pre-agentic cost model.”

— Author of the post, danluu.com