Raising the Bar: Why We Need More Ambition in Software Engineering

“We should be more ambitious with the software we build”

This sentiment, shared with me by Michael Malis (the mind behind pgrust), has been a recurring theme in our conversations since the start of the year. At first glance, projects like pgrust often trigger immediate skepticism. In an era saturated with low-quality, AI-generated "vibeslop," it is easy to assume that any ambitious rewrite is just another project destined to fail.

The Case of pgrust

If I were a stranger to Malis, I might have dismissed pgrust as just another superficial project. However, knowing his rigor, I trusted the process. Upon closer inspection, it becomes clear that the testing for pgrust is so exhaustive that it is actually uncovering deep-seated bugs within PostgreSQL itself.

Some of the critical issues uncovered include:

• Numerical Errors: Bugs causing valid SP-GiST operations to crash.
• JSONPath Issues: A format cache bug leading to incorrect query results.
• Security/Crypto: A pgcrypto bug that disrupts subsequent operations.
• Memory Safety: Multiple vulnerabilities found in the dictionary loader.
• Financial Logic: A specific bug related to money overflow.

While pgrust may not be entirely $\text{bug-free}$, the sheer volume of testing means that even if the project never achieves commercial success, it has already provided a temporary durable benefit to the Postgres ecosystem.

Performance as the Primary Driver

The core value proposition of pgrust is performance. Even if the project fails, the optimizations developed during the process could eventually be integrated into Postgres or Clickhouse.

---

The "Vibeslop" Epidemic

We are currently drowning in "vibeslop"—software that claims to be revolutionary or "fast" based on misleading benchmarks, but is actually low-quality or non-functional.

The Builder's Paradox: As a user, this noise is frustrating. But as a builder, the existence of this garbage is irrelevant. The fact that others are "shoveling piles of crap and calling it gold" doesn't stop you from building something genuinely great. We can now tackle projects that were previously considered too massive to be feasible, provided we maintain a commitment to rigorous benchmarking and testing.

---

The New Capability Horizon

The tools available to us have evolved. For instance, seeing OpenAI integrate Cerebras for SOTA models (moving beyond just "fast but low-quality" models) made me consider the implications of having a SOTA model that is $10\times$ to $100\times$ faster.

I began analyzing where my local compute time was actually being spent. I identified several bottlenecks that would only become more apparent as the AI models got faster:

Personal Experiments in Ambition

Despite a tight schedule, I spent a few hours building tools to address these bottlenecks:

• Custom Regex Engine: A tweaked engine that outperforms general-purpose libraries for my specific workloads.
• Ripgrep Fork: Integrated the native code compiler from my regex engine to speed up codex ripgrep tasks.
• Rust Build Optimization: Implemented changes that significantly improved cold builds (and moderately improved warm builds), though I avoided forking the entire front-end.

The Filesystem Problem

I noticed that my machine often hangs on filesystem operations. The standard *nix filesystem API was not designed for the performance of modern disks.

Standard API $\rightarrow$ Slow Syscalls $\rightarrow$ Bottleneck for AI Agents

In the past, attempting to build a custom OS layer or a toolchain using Direct I/O would have been an absurd waste of time. Today, it is entirely doable.

From "Impossible" to "Hours"

The most shocking part of this process is the reduction in time-to-prototype. For someone like me—who lacks deep expertise in string matching algorithms or compiler design—these projects would have previously taken over a year to reach a "works for me" state.

Now, it took a low single-digit number of hours.

Note: There is a massive difference between "works for me" quality and "production-ready open source" quality. The latter still requires significant effort.

Conclusion: The Ambition Gap

When Malis says, "We should be more ambitious," I believe he means that people aren't even attempting these projects because they don't realize how easy they have become.

For example, I see endless complaints on Twitter about slow Rust compilation hindering velocity. Instead of simply complaining, the current landscape allows us to actually do something about it. We have the tools; we just need the ambition.