Scheduling agents allow you to tackle software projects that until recently would have taken too long. It is the thesis of an essay that takes inspiration from pgrust, a project by Michael Malis to rewrite components related to PostgreSQL in Rust. The point is not that artificial intelligence produces reliable code by definition: it is that today we can try multiple paths, as long as we rigorously verify what we build.
The text cites a number of flaws identified during pgrust testing in the database: errors in numerical calculations and cache management, problems with JSONPath and pgcrypto, vulnerabilities in memory safety, and an overflow in the handling of monetary values. The author points out that this does not demonstrate the absence of bugs in the project. However, it shows how an attempted rewrite can help find problems and lead to fixes even in existing software.
Performance is the main focus of pgrust, but the paper does not present comprehensive comparative results. Some optimizations may also be useful for other systems, such as PostgreSQL or ClickHouse, although this outcome is less direct than bug reports. Caution is necessary: the author himself admits that he has not carried out in-depth benchmarks for all the tools he mentions.
More speed moves the bottleneck
Faster models can make visible limits that previously weighed less: Rust compilation, file searching with ripgrep, and file and system operations. The essay describes some personal experiments to accelerate these tasks, including a regular expression engine, a variant of ripgrep, and a Rust interpreter.
According to the author, making them took a few hours of his time, instead of months of work. But taking a design from “works for me” to adequate quality for other users requires much more. Even the results on the Rust compiler, described as a strong improvement in cold compilations and a smaller advantage in subsequent ones, remain personal observations, not extended benchmarks.
The difference also lies in the capacity of the models. The author reports having achieved better results with newer systems in creating an AI for a board game and in tests implementing zstd. It reports that a model passed more than 99% of recorded tests under the conditions tested, but does not present the entire evaluation here. They are examples of progress, not a guarantee that a model will correctly interpret any specification or code.
To make the project concrete, an adequate control system is needed. In the case of Guards of Atlantis 2the ambiguous rules made a simple implementation request insufficient: the author had to construct consistency checks between discordant descriptions. A more expensive approach in tokens, but useful for identifying contradictions before considering the usable result.
Yossi Kreinin’s comment on the post warns against this very passage: many projects they have no clear-cut success criteria and they become black boxes that are difficult to understand and maintain. AI can accelerate a solution that is overbuilt, tailored to a single case, and fragile to future changes. Without expertise to break down the problem and measure performance, speeding up development risks amplifying errors.
Ambition yes, but with checks
The essay also mentions in-house software developed by a small team in five months and personal tools built for very specific needs. These are cases that show how much previously uneconomical work can become practicable. They don’t prove, by themselves, that AI increases productivity uniformly: the benefit depends on what you choose to build and how well you can control the outcome.
The proposal, therefore, is not to rely on agents and produce as much code as possible. It means reconsidering activities that were discarded because they were too expensive, choosing projects with practicable checks and measurable utility. The argument on pgrust indicates a possibility, not a pass: testing and the ability to judge software remain the distinguishes between a useful experiment and yet another project that only works on paper.
