Applying AI to the Backlog You Deferred: A Workflow Playbook for Data and Dev Teams (AIApplications)

By David Nakamura — AI & Data News · AIApplications

Every team has a pile of work it keeps postponing: the search step that stalls builds, the codec nobody wants to own, the rules document that contradicts itself. A widely circulated developer essay treats precisely that pile as the best first candidate for applied AI work. Its starting point is Michael Malis, who created pgrust and has been sending the essay's author finished work since early this year, usually captioned with one line: “we should be more ambitious with the software we build”. The author's own variant of the sentence is the descriptive one — “we can be more ambitious with the software we build” — and for anyone deciding how to use AI at work the two framings teach the same lesson: the entry price of a first usable version has collapsed, while the price of a trustworthy version has barely moved.

Begin with verification, not with the pitch

Skepticism is the correct reflex, because the public stream is already full of low-quality AI-generated work. A rewrite project reads at first glance like another vibe-cobbled artifact that will never run. What separates pgrust from the pile is the test harness rather than the marketing: its testing was serious enough to expose real bugs in Postgres — 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-free software. It is evidence of extensive test coverage, and coverage is the reusable part of the story. Even if the rewrite ultimately fails, the attempt itself can permanently improve Postgres; some demonstrated optimizations could still reach Postgres, Clickhouse or similar systems, though that is a weaker path than submitting bug reports and getting fixes.

Two habits follow for people evaluating AI-assisted tools commercially:

• Expect most rewrite announcements on a news aggregator to be waved away, and do not consider that unfair: nobody has enough time to vet every project, so reputation is the shortcut people actually use.
• Demand the artifact instead of the adjective. As a user of software, one sees slow programs marketed as fast by creators pointing at flimsy benchmarks; several such claims can appear in a single day, and low-quality software that does not work has never been more abundant.

Find the bottleneck your new speed creates

The most transferable technique in the essay is a thought experiment, not a tool. After learning that OpenAI intended to use Cerebras for SOTA models rather than only for fast-but-lower-quality models like 5.3-Codex-Spark, the author asked where a machine would spend its time if the same SOTA model ran 10x to 100x faster. Three familiar costs surfaced:

• Ripgrep
• Compiling Rust
• Syscall and filesystem overhead

At the “works for me” level, each of those is now improvable with modest effort:

• a regex engine that can be adjusted to outperform general-purpose regex libraries on the workloads the owner cares about;
• a Ripgrep fork using that engine's native code compiler for faster codex Ripgrep workloads;
• a Rust build path that made personal builds quicker — a very large win on cold builds, a moderate win on warm builds, and a ceiling caused by deliberately avoiding a fork of the Rust compiler front end;
• a platform shift from Mac to Linux, which helped a lot because agents often perform huge numbers of tiny filesystem operations;
• options that would previously have looked ridiculous — making a developer toolchain bypass normal filesystem calls with direct I/O, building a custom OS, or inventing an odd shim that fakes syscalls — which are now feasible, since modern disks reduce any reason to remain bound by a historical *nix filesystem API that was not designed for current disk performance.

For a practitioner with limited knowledge of regexes, string matching, compilers and interpreters, those projects once would have taken a year or more to reach “works for me” quality. Here they required only a low single-digit number of hours. Turning them into useful products or open source projects would be a lot more work, and that difference is exactly where a project budget has to be written down rather than guessed.

The same lens applies to the complaints that cycle through technical feeds. For weeks, every login to Twitter showed someone arguing that Rust compilation was too slow and was capping development velocity. Compile time is genuinely slow, but this was before 5.6 Sol and 6 Astra were available on Cerebras, so compilation was not the dominant bottleneck; one can write a Rust interpreter and also directly improve compilation. 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.

Step tutorial: running one deferral-busting project

1. Pick the target from the postponed pile, not from a demo list. Prefer work whose acceptance test already exists or can be written quickly, because every step below depends on a clear pass/fail signal.
2. Probe whether your current model can read the source material. During the GPT-5.1/5.2 experiments behind Azul AI, nearly every model suggestion was wrong, forcing heavy steering to make outcomes even superficially sensible; asking the model to read a paper or codebase and implement the relevant technique failed outright.
3. When the model cannot bridge that gap, supply the named technique yourself. If the paper was read first and the technique then named, GPT would claim it was implementing it, yet the produced code often resembled the technique only on the surface and missed the real method until corrections were issued.
4. Price your verification time before you price the code. 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.
5. Install a self-checking layer wherever the specification is messy. The essay notes that systems can often be arranged so they have some self-checking property, even if most people would not arrange them that way; before coding agents appeared, fuzzing and property-based testing were already powerful methods that people in most fields said would not work, and when applied in exactly those fields they worked — more setup, but more efficient and more effective than conventional unit tests.
6. Set an obsolescence window before you polish. Model and harness capability changes so rapidly that tooling value shifts quickly; spending long effort on one tool that may become suboptimal or obsolete in three months often makes little sense.

What the timeline looked like in practice

The board-game case gives the clearest numbers for planning purposes. Using GPT-5.1/5.2 and starting with zero AI knowledge, the author spent about 5 hours to create something superhuman at matched time controls, and about 20 hours to reach what looked like the strongest AI of the moment; against human players it seemed stronger than the AI used to cheat on Board Game Arena. Gabriel Cangussu later built an AI that crushes that version and, as far as the author can tell, it required him substantially less time. The central difference in the two accounts is background knowledge inside the model: Fable 5.1 and Opus 5.5 understand board game AI much better, and casual testing with Fable 5 suggested the capability shift had already happened — a major time saving for someone who initially knew nothing about board game AIs, even if they still know far less than a real AI researcher.

On the evaluation side, the same author ran a toy evaluation of verification and test techniques using GPT-5.6 Sol to implement zstd under medium and xhigh, then reran it with GPT-6 Astra after publishing. 6 Astra was so strong that the old evaluations needed replacement because model progress made them too easy: for zstd it passes all registered tests more than 99% of the time across all conditions, including conditions that harm performance such as TDD, and it costs 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 application lesson is blunt: when a harness stops failing, it has stopped measuring anything.

The ambiguous-rules case shows the cost side. Guards of Atlantis 2 is a poor AI project because the official rules are an ambiguous, contradictory pile of English text; naively asking AI to produce a working rule set does not help much, although AI can speed up coding once a clean specification exists. Building a rough consistency-check layer between the inconsistent explanations 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 someone else's 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.

Where this pattern fits: applicability at a glance

Application pattern	Conditions where it works	Check before adopting	Main risk
Engine rewrite (pgrust)	Existing test suite is strict and broad	Does testing expose real defects in the reference system?	Readers dismiss it as slop; the rewrite may fail even when the coverage pays off
Personal toolchain (regex engine, Ripgrep fork, Rust build path, Linux move)	Acceptance is “works for me” on your own workloads	Which bottleneck dominates once inference gets 10x to 100x faster?	Productising costs far more than the prototype
Domain you do not know (Azul AI)	Model has real background in the domain	Can it read a paper and implement the method, or only imitate its shape?	Verification time exceeds generation time
Spec reimplementation (zstd, IMAP RFC, Pandoc)	Registered tests or a formal RFC exist	Pass rate and cost per implementation	Evaluations rot as soon as a stronger model ships
Messy specification (Guards of Atlantis 2)	You can build a consistency-check layer first	Token spend versus a month or two of a $200/mo plan	Garbage in, garbage out without the intermediate layer

Common misconceptions to retire

• “Everything just works now.” When people say that after using a new model everything just works and software is solved, the essay's answer is no. Newer models do one-shot more tasks where things simply work, but that mainly means taking on more ambitious targets where the model still struggles; the distance between what a model can verify without substantial handholding and what it can implement has widened. To put it less gracefully: we should be more ambitious with the software we build rather than assume it just works.
• Single-number productivity multipliers. The same objection that applies to claims of 100x or 1000x gains applies here: some tasks are accelerated by enormous factors, easily more than 1000000x, and some 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's law — but you can decide what to accelerate, and productive work usually points at activities that previously cost too much.
• Framework worship. 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. Ralph Loops drew interest for a time, but compared with a normal workflow they looked worse than a naive ordinary loop with context management, where context is cleared when useful instead of by default at the arbitrary end of one turn.
• Treating personal tooling as a durable asset. For many personal tools the reasonable assumption is that an AI lab will soon obsolete what you built. One silly instance was a tool that became useful after the release of GPT-5.6 Sol and restarts codex when it discovers a memory leak — a leak the lab may fix, making the tool worthless.
• Assuming budget is the only limit. The Rust interpreter example is the counterweight: a tool giving 50x speedup for cold compiles and 2x for warm or cached builds was reachable, with more possible if changes to the Rust compiler were allowed, but performance would improve much more by modifying the Rust front end directly, and maintaining a compatible Rust compiler fork exceeds a personal token budget. That should not be an obstacle for OpenAI, which spent $10B+ to gain Cerebras access while also preventing Anthropic from having access; in coding, tasks where you compare their SOTA model with what Anthropic provides do not always show an especially large speedup because time goes into things such as compiling Rust.

Ship, review, and state what you did not test

Applying AI tooling also changes publishing hygiene. The essay's author writes each post in half an hour and reviews it only lightly, which inevitably produces posts with thinner support: instead of supplying thorough benchmarks for every project mentioned, a quick comparison that satisfied curiosity was written up without rigorous benchmarking, and there are twenty or thirty things the post would like to do but does not. Even the Rust interpreter went undocumented. If, five years ago, someone had thrown together an interpreter giving 50x on cold compiles and 2x on warm or cached builds, that would have been very interesting to write up; now tasks that recently seemed very impressive are easy enough to perform, so they are not.

The essay also records the strongest counter-argument, quoted from Yossi Kreinin with permission: that for most people they should be less ambitious with the software they build with AI or they will experience abject failure, because a lot of problems do not lend themselves well to agentic loops without clear pass/fail criteria, and even when they do, most people have trouble reasoning about giant black boxes they can impose constraints on but cannot understand — a little like microservices, which some people both need and are good at using while most need them less and cannot use them well. The original stance survives the objection: the last time the author opened a big AI lab's web chat, a double-digit number of bugs appeared within one minute, and the fact that many people are shipping enormous quantities of barely working slop does not mean you have to do the same. From the builder side, the surrounding slop is not a reason to stop; with sensible testing and benchmarking, work can reach quality that is good enough to use. Comments, corrections and discussion came from Laurence Tratt, Yossi Kreinin, Alex Kolovsky and Michael Malis, and Malis said his line in casual talk, so the exact framing is his rather than a thesis to over-read.

Action advice

1. List three postponed internal projects and rank them by how strong their existing pass/fail signal is, not by how interesting they sound.
2. Before writing code, run a one-hour probe: ask your model to read the relevant paper, RFC or codebase and implement the technique, then judge whether the result matches the method or only its surface.
3. Build the checking layer first — property tests, fuzzing, a consistency pass over the ambiguous specification — then let the model fill in code.
4. Record two numbers for every experiment: elapsed time and cost, so a $1 implementation and a month-or-two subscription spend are distinguishable in your report.
5. Re-run your evaluation suite whenever a new model lands; replace any test set that a current model passes more than 99% of the time.
6. Publish with an explicit list of what was and was not benchmarked, and revisit promising prototypes inside a three-month window before investing in maintenance.

The reusable conclusion for applied AI work is procedural rather than celebratory: capability growth has made much larger work practical, so the interesting question for a team is no longer whether a tool can be built but whether it is verified. Take the postponed project, attach a test oracle to it, and let the model work inside that frame — which is what “we can be more ambitious with the software we build” means when it is translated into a workflow that an ordinary product or data team can run.