Quick Answer: Ambitious software projects, such as a Postgres-compatible rewrite, a custom regex engine, or a faster Rust toolchain, used to take years of specialist effort. Capable AI coding models now bring many of them to "works for me" quality in hours. The catch: your testing and benchmarking have to keep pace, or you're just shipping slop faster.
Most people who see a project like pgrust on a news aggregator assume it's another vibe-coded rewrite that will never work. They're usually right about the pile as a whole. But as Dan Luu argues, that reflex now carries an outdated assumption: that building serious developer tools from scratch is too expensive to attempt. That assumption is breaking, and the reasons are more useful than the hype.
The pgrust case shows why testing matters more than the rewrite
Michael Malis's pgrust is a Postgres rewrite, and the part worth your attention is what its testing has turned up. According to Luu's account, the project has surfaced several real bugs in Postgres itself:
- A numerical bug that can cause valid SP-GiST operations to fail
- A format cache bug that can produce incorrect results from JSONPath
- A pgcrypto bug that can cause later operations to fail
- Multiple memory safety bugs in the dictionary loader
- A money overflow bug
Here's the counter-intuitive part. Even if pgrust never becomes a usable database, the attempt has already improved Postgres in a durable way, because filed bugs get fixed upstream. Luu notes the project isn't bug-free, and that's the point. Serious testing is what separates a rewrite worth reading about from slop, and the bugs are evidence of that testing.
The main pitch for pgrust is actually performance. If the project fails, some of its optimizations could still reach Postgres or ClickHouse. That path is less direct than filing bugs that get fixed, but it's still value.
Testing is the quality filter, not the author's identity
Here's what most guides skip: the question isn't whether an AI wrote the code. It's whether anyone checked the code against something independent. Slop has no oracle. It passes its own tests, benchmarks against itself, and gets announced on social media.
Luu's point is that you can build things that were once too large to attempt, and if you do "a reasonable job with testing and benchmarking," the result can be good enough to use. The bar is evidence, not origin.
That said, there's a real catch. Trusting a builder's track record, as Luu did with Malis, is a reasonable shortcut for an expert reader. It doesn't transfer to strangers. If you're evaluating a project you don't know, look for the test suite, the conformance target (an RFC, a format spec, a reference implementation), and benchmark methodology before you look at the README's claims.
The pre-agentic cost model is quietly wrong
Ten years ago, Luu says, the person who wrote a new compiler because their compiler was slow was usually the same person who started a 3D game engine and never shipped anything. The cost of those side projects was months or years, so most productive programmers rightly avoided them.
Most engineers still carry that cost model around. It's why people complain about slow Rust builds for weeks without asking whether a faster build path is now cheap to create. Luu's own examples, all built with a low single-digit number of hours of his time, make the point:
- A regex engine he can tune for specific workloads
- A ripgrep fork that uses the regex engine's native code compiler
- A Rust build speedup that helps cold builds a lot and warm builds moderately
He's candid that none of these is production-ready, and he didn't run rigorous benchmarks. For someone without a regex or compiler background, though, he estimates getting to "works for me" quality would have taken a year or more before.
Here's where it gets interesting. The cost model changed, but the professional habits didn't. That gap is where opportunity sits.
Measure where the time goes before you rewrite anything
Luu didn't start with a rewrite. He asked where his time would go if a frontier model were 10x to 100x faster. Ripgrep searches, Rust compilation, and syscall and filesystem overhead all showed up as bottlenecks that would get worse as models sped up.
When he actually measured, Rust compilation wasn't the big bottleneck people were complaining about on Twitter. Filesystem overhead was more significant, and switching development from macOS to Linux improved it a lot. This is the actionable lesson: profile first, then decide whether a rewrite is worth the effort.
Filesystem overhead is also a place where the standard interface may be the problem. Luu argues that the POSIX filesystem API wasn't designed with modern disk performance in mind, and that direct I/O approaches that once seemed absurd are now feasible to build. Whether that's worth doing depends on your workload, and most teams never measure it.
Capability gains are real, but verification is the bottleneck
Luu's experience with board game AI is the clearest example. With GPT-5.1 and GPT-5.2, he says, the model's suggestions were mostly wrong, and when asked to implement a technique from a paper, it produced code that looked like the technique but wasn't. Checking that output required him to learn enough of the domain to verify it, which ate time. He reports that his Azul AI took about 5 hours to become superhuman and about 20 hours to become the strongest AI he knew of at the time. Gabriel Cangussu, working with newer models, reportedly built a stronger AI in substantially less time.
Newer models shift the picture in a different way. Luu reports that GPT-6 Astra passed all registered tests for his zstd implementation more than 99% of the time across conditions, including TDD-impaired ones, at roughly $1 per implementation. He then moved to harder evals, like the IMAP RFC and Pandoc, because the models had advanced past his original tests.
But he's also clear that "it just works" isn't the whole story. Models one-shot more things, so people, including Luu, take on more ambitious work where models still struggle. The gap between what a model can implement and what you can verify without heavy handholding has been widening. Here's the uncomfortable question: if models are better than ever, why does your experience still feel like hand-steering? Often it's because you're working on harder problems.
| Project | Reported effort | Result reported by the author |
|---|---|---|
| Azul board game AI | ~5 hours to superhuman; ~20 hours to strongest known at the time | Stronger than his earlier AI, including against humans |
| zstd implementation (GPT-6 Astra) | Roughly $1 in model cost | Passes all registered tests >99% of runs |
| Regex engine, ripgrep fork, Rust build speedup | Low single-digit hours total | "Works for me" quality, not production-hardened |
| pgrust (Postgres rewrite) | Not reported | Surfaced several real Postgres bugs |
Trade-offs: when to build and when to adopt
Building your own tool makes sense when your workload is specific, when you need to learn a domain, or when the real output is upstream bug reports. It rarely makes sense as a production replacement for a mature tool you already depend on. Luu himself says a text index would beat his ripgrep fork for his use case, but he built the fork anyway as a fun project.
Be honest about the costs. Code you didn't write, in a domain you don't know, is expensive to verify. Subtle bugs can survive a passing test suite. Maintenance stays with you. The cheap part is now the first draft, not the trust.
Frequently Asked Questions
What is an ambitious software project?
An ambitious software project is one whose scope would have been impractical for a small team or solo builder before, such as a database engine, compiler, or domain-specific AI. Recent AI coding tools lower the effort to a working prototype. Quality still depends on testing against an independent reference, such as a conformance suite or RFC.
Are AI-built rewrites like pgrust actually useful?
They can be, even when they fail as products. pgrust's testing has reportedly surfaced several real Postgres bugs, and those reports can get fixed upstream. Treat the project as evidence to evaluate, not a drop-in replacement, and check its tests and benchmark methodology before relying on it.
How do I know if an AI-generated implementation is correct?
Check it against something the model didn't write: an RFC, a format spec, a reference implementation, or a fixed test corpus. Benchmark against the incumbent on your real workload. Passing the model's own tests proves very little, and that's the trap most slop falls into.
Why does AI coding feel like it only works for simple tasks?
Models have gotten better at one-shotting common tasks, so people take on harder work where they still struggle. The bottleneck has shifted toward verification. If you're working on ambitious problems, expect more steering, not less.
Ambitious software projects are cheaper than they were, but the verification work hasn't gotten any easier. Pick one slow tool you use every day, profile it this week, and write down where the time actually goes. Then pass this to someone who's stuck arguing about whether a rewrite is worth it, and suggest they measure before they decide.