What happened
In “We should be more ambitious with the software we build,” Luu develops an argument prompted by conversations with Michael Malis, who has been showing him work on pgrust, a Rust-based PostgreSQL implementation. Luu says skepticism about AI-generated rewrites is understandable: many such projects are low quality. But he points to testing in pgrust that has uncovered bugs in PostgreSQL, including issues involving SP-GiST operations, JSONPath, pgcrypto, dictionary-loader memory safety and money overflow. He does not claim pgrust is bug-free. He argues that even an unsuccessful rewrite can produce useful work, including bug reports and possible performance techniques for established databases.
The broader claim is that coding agents lower the cost of trying projects that previously looked unreasonable. Luu describes building a regex engine, a ripgrep fork tailored to his Codex search workloads, and a Rust interpreter intended to speed builds. He says these “works for me” efforts took a low single-digit number of hours of his time, rather than the year or more he estimates they might once have required. He distinguishes that standard from a useful product or open-source project, which would require substantially more work. The examples are personal experiments, not controlled productivity measurements.
Luu also describes changes in model capability through a board-game AI project. When he used GPT-5.1 and GPT-5.2, he says, suggestions were often wrong and he had to steer the implementation. He contrasts that experience with later work involving Fable 5.1 and Opus 5.5, which he says were better at understanding board-game AI techniques. In another experiment, GPT-6 Astra passed registered zstd tests more than 99% of the time across the conditions he tried, including conditions that impaired performance; he reports that implementing zstd cost about $1. These are results from Luu’s own evaluations, not an independent benchmark.
The essay makes verification central. Luu says that as models improve, he moves on to more ambitious projects where they still struggle, and that the gap between what a model can implement and what it can verify effectively without handholding has grown. He argues that useful work can involve designing tests or other partially self-checking systems, including for projects whose specifications are difficult. He also includes a counterargument from Yossi Kreinin: people without the expertise to decompose and check large systems may produce brittle, overfit software and be unable to reason about its internals. Luu accepts the risk while maintaining that careful builders can pursue projects that were previously out of reach.
What the archive adds
New Runtime’s earlier coverage, “How to be more ambitious: A tutorial for humans with models” (2026-10-21), argued that ambitious prompting changes the unit of work from a task to an outcome, with evidence and tools to pursue it. Luu’s essay is a new fact on that known thread: it extends the discussion from how to direct a model to which software projects may now be economically feasible, while foregrounding the verification burden.
Trend signal
This supports verification bandwidth is the scarce engineering resource. Luu’s account suggests that implementation capacity can expand faster than the ability to validate complex output: the essay’s proposed response is not merely to generate more code, but to build tests and partially self-checking systems. His examples are personal and do not establish how common this constraint is across teams.
Why now
Luu ties the argument to his experience with newer models and faster inference. He says stronger models made some previous evaluation tasks too easy and pushed him toward more demanding projects. The timing therefore reflects a change in what he says he can attempt with current tools, not a new product release or a stated industry-wide threshold.
Why it matters
For teams building with coding agents, the useful question may be less “How much faster can we complete our existing backlog?” and more “Which worthwhile projects were previously too expensive to attempt?” Luu’s examples point toward internal tools, specialized performance work and software made for a narrow personal or team need. These projects need not begin as polished products to create value, but they still need an explicit quality bar.
The caution is equally practical. More code produced at lower cost can increase the burden of understanding and maintenance. Luu distinguishes a prototype that works for its author from a robust product, and Kreinin’s response highlights the danger of building systems whose behavior their creators cannot reason about. Teams should pair expanded scope with verification plans: define observable outcomes, use tests suited to the problem, and keep human review focused on the failure modes that automated checks cannot cover. Ambition is productive when the team can tell whether the result is right and when it is worth maintaining.
Limits and uncertainty
Luu presents personal projects and informal comparisons rather than a controlled study of development time or output quality. The reported hours describe his own time on “works for me” versions; they do not include a comparable accounting of model usage, review, maintenance or the effort needed to make a product suitable for others. The zstd result and cost are his own evaluation, and the essay notes that his broader project comparisons were not rigorous benchmarks. It remains unclear how consistently teams with different expertise can reproduce these outcomes, or how much verification effort larger projects require.
Skill to build now
Choose one recurring task that has been too small or specialized to justify building a tool for. Before asking an agent to implement it, write down a concrete example of correct behavior and at least one test that could catch a plausible failure. Keep the first version scoped to “works for me,” then decide separately what additional tests, documentation and maintenance would be needed before others rely on it. This turns the essay’s call for ambition into a bounded experiment with a visible quality bar.
Reader takeaway
Coding agents may make more ambitious software projects worth attempting, including tools that would once have been too costly to build. The limiting question is not just whether an agent can produce the implementation, but whether the builder can verify it and maintain what works. Expand the project boundary, but expand the evidence of correctness with it.