Aiming Higher in AI-Era Software: What Builders Can Test, Trust, and Scale Back

Software ambitions are being renegotiated because tasks that once required years of specialized effort now appear in short experiments, rough tests, and local bug reports. The MyTechDailyNews General reading of one recent builder argument is that AI does not remove the need for verification; it changes which attempts deserve a first try. A rewrite called pgrust sits in the middle of that debate, alongside a warning about low-quality generated projects and a claim from Michael Malis that builders should not limit themselves to small demos.

The argument began with a line that has circulated since early this year: “we should be more ambitious with the software we build.” The essay’s author liked the capability version better: “we can be more ambitious with the software we build.” That wording is a practical claim, not a moral instruction, and the debate should not hang on “we should” alone. The useful question is whether current tools make large but poorly understood tasks cheap enough to attempt seriously.

Why doubt surrounds projects such as pgrust

pgrust invites suspicion because many AI-assisted rewrites are shallow, and many readers do not have time to vet every new tool. The essay’s author admitted that, if he did not know the creator, he might dismiss it as another vibe-slopped project that would never work. He knew Malis well enough to skip an initial deep audit. A lighter pass nevertheless revealed serious testing: the work exposed real Postgres defects, including a numerical bug that can make valid SP-GiST operations fail, a format cache bug that can return incorrect JSONPath results, a pgcrypto bug that can break later operations, multiple memory safety bugs in the dictionary loader, and a money overflow bug.

That does not certify pgrust as bug free. It shows the test surface is wide. Performance is pgrust’s main bet. If the attempt collapses, useful optimizations may still migrate into Postgres, Clickhouse, or similar systems; that remains a lesser outcome than producing Postgres bug reports that become fixes. The episode also explains why news aggregators often wave rewrites away: most of them are indeed poor work.

Where the new cost model changes outcomes

A separate thought experiment concerns speed. After learning that OpenAI intended to use Cerebras for state-of-the-art models rather than only for fast-but-lower-quality models like 5.3-Codex-Spark, the author asked where his own machine would spend time if a state-of-the-art model ran at 10x to 100x faster speed. Three areas would become worse: Ripgrep work, Rust compilation, and syscall plus filesystem overhead.

At the rough prototype level, all three can be attacked. The writer had very little time available, yet still built a regex engine that could be tuned to beat general-purpose regex libraries on selected workloads. He also built a Ripgrep fork that used that engine’s native code compiler for faster codex Ripgrep workloads, plus a Rust build path that improved his own builds. Cold builds improved much more than warm builds, and the effort hit a ceiling because the author deliberately avoided forking the Rust compiler front end.

Platform choice mattered too. Development shifted from Mac to Linux, which helped because agents often generate huge numbers of tiny filesystem operations. Modern disk performance weakens the reason to stay trapped by the historical Unix filesystem API, which was designed long before current storage realities. Making toolchains bypass normal filesystem calls with direct I/O, building a small custom operating system, or creating a shim that fakes syscalls would once have looked absurd. Now the work can be feasible for a narrow personal use case.

For a person with modest background in regexes, string matching, compilers, and interpreters, these tasks would once have taken a year or more to reach a usable personal standard. Here they took only a low single-digit number of hours. Turning them into polished products or open-source projects would still require much more effort, but the time compression is the point.

Quick signals that the claim has substance

• A doubtful rewrite becomes more interesting when its tests find real bugs in mature upstream systems.
• Performance claims deserve attention when they reduce a concrete local bottleneck, such as search, compilation, or filesystem overhead.
• Model capability matters most when it removes domain ignorance long enough to produce checkable output.

Azul AI: compressed learning, still unequal verification

Azul AI shows the pattern in another domain. Starting with zero AI knowledge and using GPT-5.1/5.2, the author reached a superhuman board-game AI at matched time controls after about 5 hours. About 20 hours of work produced a system that looked like the strongest AI of the moment. Against human players, it appeared stronger than the AI used to cheat on Board Game Arena.

Gabriel Cangussu later built an AI that crushed that result, and the author believes it required Cangussu substantially less time than it required him. The gap seems to come from model understanding rather than user effort: Fable 5.1 and Opus 5.5 understand board game AI much better. During the GPT-5.1/5.2 phase, nearly every model suggestion was wrong, forcing heavy steering to make outcomes even superficially sensible.

The older GPT behavior is a warning for non-experts. If asked to read a paper or codebase and implement the relevant technique, GPT would fail. If the author read the paper first and then named a technique, GPT would claim it was implementing it, yet the produced code often resembled the technique only superficially and missed the real method until corrections. When a model is far from correctness and the user lacks background, checking the claim can take longer because the user must learn enough to evaluate it.

Casual testing with Fable 5, plus Cangussu’s experience, suggests the capability shift happened. For someone who initially knew nothing about board game AIs, that saves major time. The author still says he knows far less than a real AI researcher.

zstd, IMAP RFC, and Pandoc: test harder than hype

Another evaluation looked at verification and test techniques by using GPT-5.6 Sol to implement zstd under medium and xhigh. The author did not fully describe the result before rerunning it with GPT-6 Astra. 6 Astra was so strong that the earlier evaluations needed replacement because model progress made them too easy. For zstd, 6 Astra passes all registered tests more than 99% of the time across all conditions, including conditions that harm performance, such as TDD. It also costs less, roughly $1 to implement zstd. The work then moved to the IMAP RFC, where 5.6 Sol could not work effectively, and to Pandoc, a more substantial target because it must read and write many formats.

Common misconceptions

“Everything works after the model update”

When people say that after using a new model everything simply works and software is solved, the author does not find that accurate. Newer models can one-shot more tasks where things simply work. That mainly means he takes on more ambitious targets where the model still struggles. He is faster and more productive, but as models become more capable he moves farther from “it just works” in what he is trying to do, because the distance between what the model can verify without substantial handholding and what the model can implement has widened.

“The visible annoyance is the real bottleneck”

For weeks, Twitter timelines carried complaints that Rust compilation was too slow and capped development velocity. The author did not believe those complaints always reflected where time went. This was before 5.6 Sol and 6 Astra were available on Cerebras, and at that point Rust compilation time was not the dominant bottleneck. Rust compilation is slow, of course, but one can write a Rust interpreter and also directly improve compilation.

“Old cost intuitions still decide what is silly”

Many problems remain problems mainly because people operate with an implicit pre-agentic cost model. Ten years ago, someone who rebuilt a compiler because compiling was slow was the same type of person who would begin writing a new 3D game engine just to ship an indie game: the type who never ships. Many productive programmers still have an instinct against that, even though building it has now become reasonable.

“AI can rescue a contradictory spec”

The Guards of Atlantis 2 example warns against this. The official rules are an ambiguous, contradictory pile of English text. The author describes it as a game he has watched humans misplay often, with confusing rules that the designer repeatedly changes while insisting they are clear. If you naively ask AI to produce a working rule set, AI does not help much, though it can speed up coding after a clean specification exists.

In that case, the author could construct a rough consistency-check layer between inconsistent explanations. It got fairly close to a correct rule set, about as close as another person achieved with much more human effort and a less systematic method, and enough to compare against another implementation to obtain a working rule set. It consumed far more tokens than a manual method, but it was only a month or two of the $200/mo OpenAI subscription with GPT-5.1/5.2, which was cheaper in time than writing a clean, consistent, correct rule copy by hand.

Scale ambition up, but keep checks in place

Yossi Kreinin supplied a cautionary argument quoted with permission. Rephrased for general readers, his warning is that most people may need to scale ambition down with AI, or they may experience abject failure. Many problems lack clear pass/fail criteria, and even when they have criteria, most people have trouble reasoning about giant black boxes they can constrain but not understand. The essay’s author compares that to microservices: some people need them and use them well, while many people need them less and cannot use them well.

The author’s broader feeling is similar to his argument against claims that AI delivers 100x or 1000x productivity gains. Some tasks are accelerated by enormous factors, easily more than 1000000x. Some tasks are not accelerated at all right now. If a person does exactly what they would have done five years ago, only with AI, the gain is poor because of Amdahl. But more generally, you can decide what to accelerate, and searching for productive work often points to activities that previously cost too much.

Systems can often be arranged so they have some self-checking property, even if most people would not arrange them that way. The Guards of Atlantis 2 consistency layer is one example. This also parallels broader software testing. Before coding agents appeared, the author regarded fuzzing and property-based testing as very powerful. In most fields, people told him those methods would not work; when he applied them in those fields, they worked. They require more setup, yet remain applicable and, as far as he can tell, more efficient and more effective than conventional unit tests.

A core part of Kreinin’s comment is that people are not doing this kind of work. Given the number of bugs encountered now compared with the past, it is hard to say he is wrong: the last time the author opened a big AI lab’s web chat, he hit a double-digit number of bugs within one minute. Still, the stance remains: many people shipping enormous quantities of barely working slop does not mean you have to do the same.

Action checklist for readers and builders

1. Treat “works for me” as the first honest milestone, not proof that software is solved.
2. Use AI tools on tasks where tests, benchmarks, or a consistency-check layer can fail loudly.
3. Ask whether a project failed before because it was impossible or because the old cost model made it unthinkable.
4. Do not assume a rewrite is slop when serious testing exposes upstream bugs in Postgres or similar systems.
5. Prefer clear specifications over vague rule sets; if the source is ambiguous, build a checking layer first.
6. Remember that personal tools may be obsoleted quickly: a tool useful after the release of GPT-5.6 Sol and restarting codex when it discovers a memory leak may become worthless if OpenAI fixes the leak.
7. For Rust interpreter work, a hypothetical result five years ago of 50x speedup for cold compiles and 2x for warm or cached builds would have been interesting to document; now it is less interesting because such tasks have become easier.
8. Watch for tools that produce only themselves: Steve Yegge wrote extensively about Gas Town and claimed it was highly productive; when he built his next agentic framework, he pointed out that Gas Town had never successfully built anything except Gas Town.
9. Compare fancy loops with naive ordinary loops that clear context when useful instead of by default at the arbitrary end of one turn; Ralph Loops drew interest for a time, but the author considered them worse under that comparison.
10. Expect tool value to shift because model and harness capability changes rapidly; spending long effort on one tool that may become suboptimal or obsolete in three months often makes little sense.
11. For large performance gaps, assume a major lab may outdo outsiders: OpenAI spent $10B+ to gain Cerebras access while also preventing Anthropic from having access.

FAQ: how ordinary tech readers should judge these claims

Q: Is this saying every person should build a compiler or database rewrite?
A: No. The original argument is narrower: some tasks once dismissed as too large are now practical enough to try. The essay’s author still wrote each recent post in half an hour and reviewed it only lightly, so the notes have thinner support. He says there are twenty or thirty things he would like to do in the post but have not done.

Q: Why trust pgrust when many AI projects are low quality?
A: Because the surrounding slop is not a reason to stop. The author notes that most rewrite projects really are slop, and without his history with Malis he would have reacted the same way. Nobody has enough time to vet every project. The trust came from known testing discipline, and the bug list surfaced only when he checked pgrust again before using it as an example.

Q: What practical takeaway matters outside the builder bubble?
A: Look for testable proof, not slogans. A performance claim is more credible when it can expose bugs, pass registered tests, reduce a local bottleneck, or show a concrete cost such as roughly $1 to implement zstd. The discussion thanks Laurence Tratt, Yossi Kreinin, Alex Kolovsky, and Michael Malis for comments, corrections, and discussion.

Bottom line

The strongest version of this argument is neither “software is solved” nor “most people should stop trying.” It is that capability growth has made much larger work practical, while verification remains the difference between an ambitious project and an impressive pile of broken code. To put it less gracefully: we should be more ambitious with the software we build.