ItInsightsWorld SoftwareDevelopment: How Agentic Tooling Changes the Cost Math Behind Your Roadmap

Delivery plans are priced twice: once by the skills a team genuinely has, and once by an inherited gut feeling about what work costs. In the engineering write-ups we follow here at ItInsightsWorld, the second number is usually the binding one — it decides whether a rewrite of a storage layer, a bespoke regex engine or a serious property-based test suite ever reaches the board at all. Michael Malis, the author of pgrust, has kept sharing interesting work with me since early this year, and he tends to frame it with a single sentence: “we should be more ambitious with the software we build”. What follows is the SoftwareDevelopment read on that claim — which bottlenecks have really moved, how to scope an ambitious slice without shipping slop, and when a team should deliberately pull scope back.

Why Ambitious Rewrites Get Dismissed, and What Serious Testing Reveals

Work like pgrust draws instant doubt, because the ecosystem already carries a large volume of low-quality AI-generated output. If Malis were a stranger, the reasonable guess would be another vibe-slopped project that never works. Prior history is enough to trust the output without deep inspection, and even a light pass shows the testing is rigorous enough to surface genuine Postgres defects: 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 is not a claim of bug-freedom. It is evidence of extensive test coverage. Even if pgrust ultimately fails, the attempt itself can permanently improve Postgres; the project’s central argument is performance, and that is where its most promising work lives. Should it fail, some demonstrated optimizations could still land in Postgres, Clickhouse or similar systems — a weaker path than submitting Postgres bugs and obtaining fixes.

The dismissal reflex is also understandable: whenever pgrust surfaces on a news aggregator, many readers wave it away as vibeslop, because most rewrite projects genuinely are slop, and nobody has time to vet every project. The bug list above only came to light on a re-check before using pgrust as an example. From the user side the problem is visible everywhere — slow programs marketed as fast on flimsy benchmarks, several such claims in a single day, and low-quality non-working software at historic highs. From the builder side, none of that is a reason to stop: with sensible testing and benchmarking, work once too large to be realistic can still reach quality that is good enough to use.

Which Bottlenecks Have Actually Moved

Learning that OpenAI intended to use Cerebras for SOTA models, rather than only for fast-but-lower-quality models like 5.3-Codex-Spark, prompted a concrete thought experiment: if a SOTA model ran at 10x to 100x faster speed, where would a workstation spend its time? Several existing bottlenecks would get worse — Ripgrep, compiling Rust, and syscall plus filesystem overhead.

Each of those is improvable at “works for me” level, even with small available time:

• A regex engine tunable to outperform general-purpose regex libraries on the workloads that matter.
• A Ripgrep fork that uses the regex engine’s native code compiler for faster codex Ripgrep workloads.
• A Rust build path with a very large win on cold builds, a moderate win on warm builds, and a ceiling set by avoiding a fork of the Rust compiler front end.
• Moving development from Mac to Linux for syscall and filesystem overhead, because agents issue huge numbers of tiny filesystem operations.

Modern disks remove most reasons to stay bound by a *nix filesystem API that was never designed for current disk performance. Previously, making a toolchain bypass normal filesystem calls with direct I/O, or building a custom OS, or inventing an odd shim that fakes syscalls, would have been ridiculous. Now it is feasible. For someone with limited working knowledge of regexes, string matching, compilers and interpreters, these projects would once have taken a year or more to reach “works for me” quality; they required only a low single-digit number of hours. Converting them into useful products or open source projects is a great deal more work — but the time compression is still remarkable.

The Pre-Agentic Cost Model Is the Real Constraint

Read as engineering guidance, the slogan points at a planning habit rather than a capability gap: many people simply do not think to try tasks that have now become easy. For weeks, every login to Twitter showed someone arguing that Rust compilation was too slow and was capping development velocity. Those complaints did not fully reflect where time went, since they predated the availability of 5.6 Sol and 6 Astra on Cerebras, when Rust compilation time was not the dominant bottleneck. Rust compilation is slow — but you can write a Rust interpreter and improve compilation directly. The same applies to many problems raised daily: they are now solvable without large time or effort, and persist mainly because teams still operate with an implicit pre-agentic cost model. Ten years ago, someone who rebuilt a compiler because compiling was slow was the same type who would start a new 3D game engine just to ship an indie game: the type who never ships. Many productive programmers still carry an instinct against that, even though building it has now become reasonable.

Field Note: Azul AI as a Competence Timeline

An earlier project, Azul AI, is superhuman at matched time controls. Using GPT-5.1/5.2 and starting with zero AI knowledge, about 5 hours produced something superhuman and about 20 hours produced what 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 crushes that version, and it required him substantially less time. A central difference is that Fable 5.1 and Opus 5.5 understand board game AI much better.

The GPT-5.1/5.2 experience was different in kind: nearly every model suggestion was wrong, forcing heavy steering to make outcomes even superficially sensible. If I asked GPT to read a paper or codebase and implement the relevant technique, it failed. If the paper was read first and a technique named, GPT would claim to implement it, yet the produced code resembled the technique only on the surface and missed the real method until corrections were issued. When a model is that far from correctness and the user lacks domain background, checking whether it did what it claimed takes even longer, because the user must learn enough to evaluate the claim. Casual testing with Fable 5, and Cangussu’s experience, suggest that shift has already happened — a major saving for someone who began knowing nothing about board game AIs and still knows far less than a real AI researcher.

Field Note: Verification Evals From zstd to Pandoc

The same capability expansion shows up in verification and test work. A toy evaluation used GPT-5.6 Sol to implement zstd under medium and xhigh; after publishing, the evaluations were rerun with GPT-6 Astra. 6 Astra was strong enough that the old evaluations needed replacement, because model progress made them too easy. For zstd, GPT-6 Astra passes all registered tests more than 99% of the time across all conditions, including conditions that harm performance such as TDD, and it costs less — roughly $1 to implement zstd. The next targets were the IMAP RFC, where 5.6 Sol could not work effectively, and Pandoc, a substantial target because it must read and write many formats.

The claim that after adopting a new model “everything just works” and software is solved is not accurate. Newer models do one-shot more tasks where things simply work; the practical effect is that the ambitious targets shift to places where the model still struggles. Throughput rises, yet distance from “it just works” grows, because the gap between what the model can verify without substantial handholding and what the model can implement has widened. That is the least graceful way to state the thesis: we can be more ambitious with the software we build. Malis said “we should” in casual talk; do not attach too much significance to can versus should — the striking point is how capability growth has made much larger work practical.

A Repeatable Sequence for Scoping an Ambitious Slice

Every case above shares a shape. Translated into practice steps:

1. Write down the cost estimate you are pricing against, then ask whether it belongs to the pre-agentic model.
2. Choose a target with mechanical pass/fail signals — a registered test suite, a benchmark, or a reference implementation to compare against.
3. Build the test and benchmark harness before the feature; extensive test coverage is what turns an attempted rewrite into durable value even if it fails.
4. Measure where machine time actually goes before attacking the fashionable bottleneck (Ripgrep, compiling Rust, syscall and filesystem overhead).
5. Timebox the “works for me” slice — these experiments landed in a low single-digit number of hours — and only then budget the much larger productisation effort.
6. For every model claim, verify the implementation against the named technique; surface resemblance is the failure mode that costs the most review time.
7. Where the work exposes upstream defects, submit them: bugs accepted into Postgres are a stronger path than carrying optimizations into Clickhouse or similar systems.
8. If the specification is ambiguous, add a partially self-checking layer before asking a model to produce a working rule set.

Old Cost Model vs. Current Toolchain

Planning dimension	Implicit pre-agentic cost model	What the current toolchain supports
Reaching “works for me” quality on a regex engine, a Ripgrep fork or a Rust build path	a year or more	a low single-digit number of hours
Board game AI from zero domain knowledge	Research background assumed necessary	5 hours to superhuman at matched time controls; 20 hours to roughly the strongest of the moment
Implementing zstd as a verification test	Specialist codec work	passes registered tests more than 99% of the time across all conditions, at roughly $1
Cold vs. warm Rust compile wins without touching the front end	Not worth attempting	50x on cold compiles, 2x on warm or cached builds
Direct I/O toolchains, custom OS, syscall shims	Ridiculous	Feasible; modern disks outdate the historical *nix filesystem API
Perceived productivity gain	100x or 1000x promised	Some tasks exceed 1000000x, others gain nothing; Amdahl’s law governs the mix

Common Pitfalls in AI-Assisted Builds

• Reading the surrounding slop as a stopping condition. Other people producing enormous piles of broken work and calling it gold is not a reason to match them.
• Marketing slow programs as fast on flimsy benchmarks — a pattern visible constantly from the user side.
• Building frameworks that build only themselves. Steve Yegge wrote extensively about Gas Town and claimed it was highly productive; when he constructed his next agentic framework, he pointed out that Gas Town had never successfully built anything except Gas Town.
• Adopting loop patterns without comparison: Ralph Loops drew interest for a time, but against a workflow using a naive ordinary loop with context management — clearing context when useful rather than by default at the arbitrary end of one turn — they looked worse.
• Assuming tooling value is durable. Model and harness capability changes so fast that a tool may become suboptimal or obsolete in three months, so long effort on one tool often makes little sense.
• Building personal utilities that an AI lab will obsolete anyway — for example a tool that was useful after the release of GPT-5.6 Sol and restarts codex when it discovers a memory leak that OpenAI may eventually fix.
• Ignoring the maintenance ceiling: the Rust interpreter left the real front-end compiler untouched, because maintaining a compatible Rust compiler fork exceeded the token budget. That should not be an obstacle for OpenAI, which spent $10B+ to gain Cerebras access while also preventing Anthropic from having access.
• Expecting uniform speedups in coding: compared with what Anthropic provides, many SOTA-model tasks show no especially large speedup, because time goes into things such as compiling Rust.

The Counterweight: When to Scale Ambition Down

Yossi Kreinin offered the opposing case, quoted with permission, and it deserves a place in any engineering plan: for most people, less ambition with AI-assisted software may be the difference between shipping and abject failure, because many problems lack clear pass/fail criteria, and even when they have them, most people struggle to reason about giant black boxes they can constrain but cannot understand — a situation comparable to microservices, which some teams need and use well while most need less and cannot use at all. Moderating ambition is a big part of handling the current situation for most teams.

The disagreement is mostly about distribution, not direction. It resembles the argument over claims that AI delivers 100x or 1000x productivity gains: some tasks are accelerated by enormous factors, easily more than 1000000x, while some tasks are not accelerated at all right now. A person who does exactly what they would have done five years ago, only with AI, gains little because of Amdahl’s law. But you can decide what to accelerate, and searching for productive work usually points at activities that previously cost too much.

Systems can often be arranged to have a self-checking property, even where most people would not arrange them that way. The Guards of Atlantis 2 implementation is one example, and a poor AI project by construction: the official rules are an ambiguous, contradictory pile of English text, the game watched most often misplayed by humans, with a designer who repeatedly changes what the rules mean while insisting they are perfectly clear. Naively asking AI for a working rule set does not help much, though AI accelerates coding once a clean specification exists. Constructing a rough consistency-check layer between the inconsistent explanations reached a rule set about as correct as another person achieved with much more human effort and a less systematic method, and close enough to compare against someone else’s implementation. 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 — cheaper in time than hand-writing a clean, consistent, correct rule copy.

This parallels broader software testing. Before coding agents appeared, fuzzing and property-based testing were already very powerful; in most fields people said those methods would not work, and applying them in exactly those fields showed that they do. They need more setup, yet remain applicable and, as far as can be told, more efficient and more effective than conventional unit tests. A core part of Yossi’s point is that people are not doing this kind of work, and the bug volume compared with the past makes that hard to dispute: the last time a big AI lab’s web chat was opened, a double-digit number of bugs appeared within one minute. Many people are shipping enormous quantities of barely working slop — it simply does not mean you have to do the same.

FAQ

Does a stronger model mean software is “solved”?

No. Newer models one-shot more tasks where things simply work, which mostly means the work moves to targets where the model still struggles; the gap between what a model can verify without substantial handholding and what it can implement has widened.

Is an attempted rewrite worth it if it fails?

It can be. With extensive test coverage, attempting pgrust can permanently improve Postgres even if the project fails; porting demonstrated optimizations to Postgres, Clickhouse or similar systems is the weaker path compared with submitting bugs and getting fixes.

What if my specification is ambiguous or contradictory?

Build a partially self-checking layer first, as with Guards of Atlantis 2. Expect higher token spend — a month or two of the $200/mo OpenAI subscription with GPT-5.1/5.2 — but less elapsed time than writing a clean specification by hand.

Which bottlenecks should a team inspect before optimising code?

Ripgrep, compiling Rust, and syscall plus filesystem overhead. At the “works for me” level all three improve meaningfully, including switching development from Mac to Linux.

Should we trust an ambitious new project on sight?

Nobody has time to vet every project, and most rewrites are slop, so dismissals are rational. The practical filter is whether the author ships serious testing — the kind that exposes real Postgres bugs rather than only passing its own suite.

Action Recommendations

• Re-price one backlog item per iteration using today’s toolchain instead of the pre-agentic cost model, and check it against mechanical pass/fail signals before scheduling.
• Put test and benchmark work ahead of the feature, and prefer coverage methods such as fuzzing and property-based testing where the target has invariants rather than examples.
• Keep a short list of machine-level bottlenecks and verify where time actually goes before accepting complaints that, for example, Rust compilation is capping velocity.
• Timebox “works for me” experiments, then decide separately whether the larger productisation investment is justified.
• Contribute upstream where a rewrite exposes defects, rather than accumulating private forks.

Sourcing Note and Acknowledgements

One caveat on evidence. To publish more, each post is written in about half an hour and reviewed only lightly, which inevitably produces posts with thinner support: in the usual mode, thorough benchmarks would have been supplied for every project mentioned here, and instead a quick comparison that satisfied curiosity was written up without rigorous benchmarking — there are twenty or thirty things that would be done in this post but have not been done.

The Rust interpreter is not even documented. If, five years ago, a Rust interpreter had been thrown together giving a 50x speedup for cold compiles and 2x for warm or cached builds, with more possible if changes to the Rust compiler were allowed, that would have been very interesting to write up. Even barely edited posts do not make the cut now, because tasks that recently seemed very impressive have become easy enough to perform. Thanks to Laurence Tratt, Yossi Kreinin, Alex Kolovsky, and Michael Malis for comments, corrections, and discussion.

Treat the ambition question as an engineering input, not a mood: the projects that once failed on cost alone are the ones worth re-scoping this quarter, provided your tests, benchmarks and self-checking layers are strong enough to tell you the truth about the result.