The claim that "we should be more ambitious with the software we build" comes from Michael Malis, author of the pgrust project, who has been making the case in conversation over the past year. Malis's argument matters because pgrust is exactly the kind of project that draws reflexive skepticism: a rewrite attempt in a field crowded with low-quality AI-generated work. If you don't know Malis and don't look closely, the safe assumption is that it is one more "vibeslop" project that will never work.
Looking closely changes that picture. Testing pgrust has turned up real bugs in Postgres itself: a numerical bug that can cause valid SP-GiST operations to fail, a format cache bug that causes incorrect results from JSONPath, a pgcrypto bug that can cause later operations to fail, multiple memory safety bugs in the dictionary loader, and a money overflow bug.
That list doesn't make pgrust bug free, but it does show substantial testing is happening. Even if the rewrite never succeeds, the attempt will have improved Postgres durably. The project's actual pitch is performance, so the headline work is in optimization; if it fails, some optimizations might still land in Postgres, Clickhouse and similar systems, though that's clearly less direct than filing bugs that get fixed.
Why default skepticism is reasonable, and why it doesn't bind builders
It is understandable that news-aggregator threads dismiss pgrust; almost all rewrite projects are slop, and nobody has time to audit every one. The same applies on the consumer side, where slow software is routinely advertised as fast on the strength of a slop benchmark.
For someone building software, the calculus is different. Malis's point is not that large prior efforts were impossible, but that it is now feasible to produce things that were too large to attempt before, and that with reasonable testing and benchmarking the output can be good-enough to use. One would naturally say "we can be more ambitious" rather than "we should"; the interesting question is how far capabilities have moved.
What the new cost model unlocks
Suppose a state-of-the-art model were ten to a hundred times faster than today's. Where the host machine's time goes becomes the constraint. Three things already show up as intermittent bottlenecks and would only worsen: ripgrep, compiling Rust, and syscall and filesystem overhead. All three are improvable even for a "works for me" project.
Concrete examples, built without any background in regex engines, string matching, compilers or interpreters: a regex engine tunable to beat other general-purpose regex libraries on any particular workload, and a ripgrep fork using that engine's native-code compiler that is faster for the author's codex workload. A text index is the better answer in principle, but this was a for-fun project rather than an optimal design. A modified Rust sped up builds for these projects: a large improvement on cold builds, moderate on warm, limited by wanting to avoid forking the Rust compiler front-end.
For syscalls and filesystem overhead, simply moving development from Mac to Linux helped a lot, and there is plenty of room left, especially as agents hammer many small filesystem operations and the standard OS interface wasn't designed for modern disk performance. A developer toolchain using direct I/O, or a custom OS layer that fakes out syscalls, used to be an absurd endeavor and is now doable.
A task set like that would once have taken a year or more to reach "works for me" quality. It took a low single-digit number of hours. Raising any of it to "useful product or open source project" quality would be far more work, but the speedup of the initial process is substantial. The same pattern shows in a different register: an Azul AI that is superhuman at matched time controls, built with GPT-5.1/5.2 by someone with no AI knowledge, took roughly five hours to reach superhuman strength and roughly twenty to become apparently the strongest AI at the time, stronger against humans than the AI used to cheat on Board Game Arena. Gabriel Cangussu has since built an AI that demolishes it in substantially less time, a difference he attributes to Fable 5.1 and Opus 5.5 understanding board game AIs far better. With GPT-5.1/5.2, nearly every suggestion was wrong and had to be steered; asking the model to read a codebase or paper and implement its techniques failed, and once a technique was named the model would produce something that superficially resembled it but wasn't, until corrected. When the model is that far off and you lack domain background, verifying it takes a long time, because you first have to learn enough to check the claim.
That state did not last. With Fable 5 and later models, reading papers and picking codebases to crib from appears to work, which saves significant time for someone without a board game AI background. Public evals also understate progress: what matters to most working programmers is performance on tasks that still need human guidance, not on tasks that have become trivial. In a toy eval using GPT-5.6 Sol to implement zstd at medium and xhigh reasoning, re-running with GPT-6 Astra made the original tasks too easy to be informative. Against the registered tests, 6 Astra passes more than 99% of the time across all conditions, including ones that impair performance such as TDD, at a cost of about $1 per implementation. The replacement evals were the IMAP RFC, which 5.6 Sol couldn't do effectively, and Pandoc, a major undertaking because it must read and write many formats: about 69 input and 74 output formats.
The complaints people voice daily are often like this. For weeks, every visit to Twitter surfaced complaints that Rust compilation is slow and limits development velocity, though at the time neither 5.6 Sol nor 6 Astra was available on Cerebras and measured time wasn't going primarily to compilation. Slow Rust compilation is real; one can write a Rust interpreter and speed up compilation at the same time. Such problems look insoluble because people carry a pre-agentic cost model. Ten years ago, the person who wrote a new compiler because their compiler was slow was the person who started a new 3D engine to make an indie game — the person who never ships. Most productive programmers still have that aversion even where the calculus has changed.
Ambition has a failure mode too
Yossi Kreinin's counterpoint, quoted with permission: for most people, being less ambitious with AI-built software is the safer course, because they will otherwise experience abject failure. Many problems don't suit agentic loops when there are no clear pass/fail criteria, and most people struggle to reason about giant black boxes they can constrain but not understand — himself included. He compares it to microservices, which some people need and use well while most need them less and use them badly. Using AI to speed up a flow can add messy code overfit to the tested case, which won't generalize performance-wise and won't be maintainable after future changes. Where practitioners understand decomposition, when to go all-in on optimizing a part, and how to benchmark, the results are great; where a manager convinced that software has no reason to be slow pushes AI at random components, the results are not.
The overall picture resembles the argument against blanket "100x or 1000x productivity" claims. Some things speed up by enormous factors, some not at all, and doing exactly what you'd have done five years ago but with AI yields a poor speedup under Amdahl's law. The leverage comes from choosing what to speed up, which tends to mean work that was previously too expensive to attempt.
Partly self-checking setups are more available than most people assume. Implementing Guards of Atlantis 2, whose official rules are a mess of ambiguous and contradictory English that humans misplay at a high rate, and which the designer has reinterpreted despite insisting the text is clear, is a poor AI project in the naive form; AI speeds implementation once a clean spec exists but won't resolve the contradictions. A janky set of consistency checks across the inconsistent rule explanations got fairly close to a correct rule set, comparable to what someone else reached with much more human effort and less systematic method, and good enough to compare against another implementation and produce working rules. It cost more tokens than a manual approach, but "only" a month or two of a $200/mo OpenAI subscription with GPT-5.1/5.2 — less than the time cost of writing a clean spec by hand. This parallels pre-agent testing experience: fuzzing and property-based testing worked in domain after domain where people said they wouldn't, with more setup effort but better results than traditional unit tests. Given the volume of bugs visible today — a double-digit count within one minute of opening a major lab's web chat — Kreinin's concern isn't unfounded, but other people's slop doesn't obligate anyone to match it.
Where effort actually pays off
The examples above are tooling that never would have been written otherwise, and there are many more, since "works for me" tooling aimed only at its author is cheap. It is possible to go too far: Steve Yegge wrote extensively about how productive Gas Town was, then noted when building his next agentic framework that he had never used Gas Town to successfully build anything except Gas Town, and Ralph Loops seemed worse than ordinary loops with context cleared when appropriate rather than at the arbitrary end of every turn. The churn in model and harness capability means that what tooling is worth building changes quickly, so heavy investment in any one tool risks being suboptimal or obsolete within months.
The author's assumption for personal tools is that a lab will obsolete them soon. A tool that restarts codex on detecting a memory leak has been useful since GPT-5.6 Sol shipped and will be worthless once that's fixed. For the Rust interpreter, token-budget constraints ruled out much of what a high-performance interpreter needs; notably, it doesn't modify the actual Rust front-end, which costs update compatibility and performance. Maintaining a compatible Rust compiler fork is beyond an individual token budget, but not OpenAI's — which spent over $10B on Cerebras access while also keeping Anthropic from it. For many coding tasks the real speedup from a SOTA model is modest, because of time spent compiling Rust. An organization willing to commit $10B+ will eventually speed up these tools better than anyone outside a lab, so there is limited point in investing heavily here, even if other bottlenecks outrank it today given how much it pays for tokens relative to an individual user.
Smaller-scale self-indulgence is also now economical: games with niche appeal, such as Star Wolf-style submarine combat, implemented for an hour or two of play, alongside digital versions of Scout and Guards of Atlantis 2 for playing with friends remotely. A five-minute build is worth it where 10–20 hours would not be, and a wider game renaissance is underway as programming skill and time stop being the bottleneck.
Custom tooling often pays for itself even, or especially, when the maintainer doesn't understand it. Peter Geoghegan describes a Neovim Lua function written with Fable that formats code to his exact preferences, running clang-format or clangd first and then pgindent, the Postgres fork of bsd_indent whose output CI enforces. It is deliberately a Rube Goldberg device: covering only a block-visual selection rather than whole files conflicts with pgindent's file-only design, so tree-sitter determines which subset of a temporary whole-file buffer to copy back, with fuzzy rules for selections straddling blocks and dynamic regeneration of typedefs from clangd to avoid a stale objdump-generated typedef file without paying the latency of running objdump on the binary. It works, with acceptable latency, and he has only a vague understanding of how. LLMs, he concludes, make a small class of software possible that would be insanely uneconomical to maintain with any human effort.
For pgrust verification, Malis used Kani to verify parts of the code and has since moved to Lean for properties too complex for Kani. Why people have settled on Lean for LLM-driven proofs rather than ACL2 is, on its own, an open question worth an eval akin to an updated theorem prover comparison or language eval. Out-of-lab precedents point in the same direction: a team of seven at Anthropic built internal source-control tools Scion and Antique plus half a dozen related systems and fully migrated to them in five months. Such examples indicate where the industry is headed but say little about what is achievable today without unlimited funds, since they rely on infrastructure also built with unlimited tokens. Spare-time projects — pgrust, David Turner's podcast-skipper that beats everything he could find, Dennis Snell's assorted work — are more representative.
"Everything just works" is not the observed experience
With each new model, more tasks are one-shottable, but that shifts the work toward more ambitious projects where models still struggle. Productivity rises, yet each more capable model has widened the gap between what a model can verify without significant handholding and what it can implement. Programming skill remains high-leverage for now: expert judgment is increasingly what separates a working implementation from a convincing counterfeit. None of this is a forecast — the software skills in question may become irrelevant in the near future, but they remain unusually valuable at present — and it is best to stick to projects where impact is direct.
This argues for care as well as ambition. Malis is careful about claims: asked on the pgrust Discord about production database readiness, he recommended against using it as a primary production database, noting only that a current deployment is unusually tolerant of downtime and will supply evidence on reliability. In a later message he framed the best way to help as finding bugs and performance issues in 0.4-beta, since the new query engine is very fast on some workloads but regresses on others and doesn't support some more complex queries. One notable regression concerns very fast queries, because optimization targeted large-scale OLAP-like workloads; he called that fixable in principle. A published benchmark preview became contentious: accusations of nefarious cheating appear false, and Malis acknowledged that submitting the preview was premature. The damage from that kind of episode tends to persist regardless of the facts.
A comparable caution applies in the other direction. A response to the Guards of Atlantis 2 write-up can cut both ways, as can any blanket claim that there's no reason for software to be slow. The author's Ambition thesis and the "no slow software" thesis share a structure: enormous speedups in some places, none in others, with the gains coming from selecting work that was previously too expensive to do.
