Dan Luu's post centers on a simple thesis from Michael Malis, creator of pgrust (a Rust reimplementation of PostgreSQL): developers should be more ambitious about what they build because AI tools have fundamentally changed the cost structure of software development. The claim is not that AI produces good code automatically — it's that the time cost of learning new domains, implementing complex systems, and verifying correctness has dropped by an order of magnitude or more. The evidence is specific and testable. Pgrust's testing regime has uncovered real Postgres bugs — a numerical bug in SP-GiST operations, a format cache bug causing incorrect JSONPath results, a pgcrypto bug, multiple memory safety issues in the dictionary loader, and a money overflow bug. Whether or not pgrust ever ships as a production database, these bug reports improve Postgres durably. The project isn't vibeslop; it's producing verifiable artifacts that upstream maintainers accept. Luu's personal experiments reinforce the point. He built a custom regex engine, a ripgrep fork with native code compilation, and a Rust interpreter that speeds up builds — all in a "low single-digit number of hours" of his time, in domains where he had zero prior expertise. Previously, this set of projects would have taken a year or more to reach even "works for me" quality. The time compression isn't marginal; it's structural. The board game AI example is particularly revealing about the trajectory. When Luu built a superhuman Azul AI using GPT-5.1/5.2, it took about 20 hours because the models couldn't reliably implement techniques from papers — they'd produce superficially correct but mechanistically wrong implementations. Gabriel Cangussu recently built a stronger AI in substantially less time using Fable 5.1 and Opus 5.5, because those models actually understand board game AI techniques well enough to implement them from papers. The bottleneck shifted from "steering the model" to "choosing what to build." The scaling picture matters here. GPT-6 Astra implements zstd compression passing all registered tests more than 99% of the time across all conditions, including with TDD enabled, for about $1. Luu had to escalate to harder evals — IMAP RFC implementation, full Pandoc reimplementation — because the previous benchmarks became too easy. But he's careful to note this isn't "software is solved." One-shotting works for more things, but the hard frontier hasn't vanished. The real insight isn't about AI capability per se — it's about the mismatch between what's now feasible and what developers believe is feasible. Most productive programmers carry a "pre-agentic cost model" that classifies projects like writing a new compiler or implementing a database as yak-shaving that signals you'll never ship. Ten years ago, that heuristic was correct. Now it's a constraint that exists only in people's heads. The person who writes a Rust interpreter because compilation is slow is no longer the person who never ships — they're the person who ships faster because they eliminated a real bottleneck in hours instead of living with it for years. The infrastructure implications are significant. Luu points out that modern disk performance makes the standard Unix filesystem API a bottleneck, especially when agents hammer small filesystem operations. Building a developer toolchain using direct I/O instead of normal filesystem operations would have been absurd before; now it's doable. The entire stack of assumptions about what's "too hard" is being repriced in real time, and the developers who update their cost models fastest will build things that look impossible to those who haven't.
