What About Bob?

If your tool is getting in your way, throw it out! I replaced Gradle with a lovable idiot of a build tool I prototyped in three days. Then I raced the two, each from a fresh dev image, on the same machine.

Two docker builds on one machine, each starting from its era's dev image with the same JDK. Left: the fleet exactly as it stood on 2026-08-04, built the way it was built then, with Gradle. Right: the fleet today, built with bob. Time-lapse; each pane keeps its own wall clock. The fleets are snapshots from different dates: this compares the builds I worked with in each era.

Compare the videos on the left and the right. They correspond to a process I've been following for months as I've been refining the Kompuwiz framework. I have this real moron thing I do called "thinking" and have this mad notion that I should build on actually good software, so I've been evolving my APIs and giving myself Flag Days for months on a nearly 800,000-line, 700-module ecosystem that has persistence, serialization, networking, encryption, compression, analytics, reliability, the works. That has had me Rebuilding the World over and over (a good socialist hobby, though it makes it difficult to get things done)… and I've burnt hours and HOURS fighting dependency versioning and API changes in a way that reminds me of my time using the Brazil build system at Amazon.

Bob the Builder was our build tool at Amazon when I joined. It was a bunch of Ant scripts written by a genius. I found it a bit cumbersome at the time and urged us to move towards Industry Standard tooling, like Gradle.

It's funny how life has a way of humbling us.

I've also burnt MILLIONS of tokens having my Claude agents running builds, hunting issues, creating contention, and generally doing The Hard Work of Software Engineering.

When I started this, I realized that a pillar of my Central Dogma was wrong. The cascading result has led to the dramatic efficiency improvement you see on the right.

I came to Gradle through Grails, which I started using in 2006. Groovy was a fun little language, I found Maven build files ugly and eye-bleeding, and the Grails community was advanced and fun. I wasn't the only one who thought this way: when I saw that Gradle was adopted by Android, that only seemed to add evidence that my convictions were sound. It makes the build process really easy and self-contained; you can just clone a Gradle repo that has the wrapper and build immediately. Plus there's all kinds of useful plugins and a wide community of knowledge… why would anyone ever give that up? There are Industry Standard Tools. Use the Tools. FOLLOW THE CARGO CULT.

Why give it up? Because it's slow as molasses. It has weird behaviors that fight me, which led me to writing software.visionary.publish. I found myself having to give a lot of guidance to my agents on how to use it due to weird issues: how some build configurations work only in Groovy, not in Kotlin; how the Gradle Daemon often deadlocks under contention from parallel builds; and how one agent amusingly described the Gradle API as a Potemkin Village when I wanted to build a non-plugin project to analyze dependencies across the codebase.

After my most recent Flag Day burnt 2 days of builds and rebuilds and agents clobbering each other's work, I had a stunning realization: What About Bob?

For those of you who didn't see this classic Bill Murray movie, What About Bob? is a fun little comedy with Richard Dreyfuss and Bill Murray about this family that ends up becoming friends with this guy who's just a complete fucking neurotic idiot, but he's lovable. He follows his intelligent and capable therapist, who wrote a self-help book, on vacation, and makes life seemingly miserable and yet oddly much better.

In a fit of rage, I told a Fable agent to make me a fucking build system. Make me a fucking bob. The prototype used iluvatar and commander to do the very simple work of "give me some commands and I'll run them." Basic stuff, because 90% of my time I'm doing ./gradlew clean test assemble publish; sometimes that publish is to an artifact registry or Maven Central, and I want quality checks like coverage and cognitive load assessment built in.

It turns out that we live in an age where All Base Assumptions Should Be Questioned. Before doing it, I thought it would be hard. Three days later, I had a working prototype.

The first simplification was putting the build information together. Versions that I was maintaining across gradle/libs.versions.toml, build.gradle.kts/settings.gradle.kts, a gradle.properties file, and various build plugins simply became annotations on my module-info.java. Going into the internal structure of the daily plugins like JUnit, JaCoCo, and Publishing/Vanniktech that I'd used made me realize I could throw a lot of complexity out. I didn't need classpath munging and weird dependency resolutions; my projects are JPMS. The entire testing stack could just be running a main method, built on Eru.

I also had the Fable agent build me some IntelliJ plugins for Bob and Spex. My development experience with IntelliJ IDEA got so bad at scale, and enraged me so much in actively developing an ecosystem at the scale I have, that I canceled my Ultimate subscription and stopped paying $1000/yr to support my development brethren, because their product was dogshit slow and had a bunch of shit I didn't need for my development ecosystem…

…but the Worst Thing is still the best thing for Ctrl+B navigation and Right Click Refactorings (which I'll be dealing with soon), so I kept using it on the rare occasions these days when I have to actually spelunk into code and not CTO my way through an army of dev projects… and wouldn't you know, IntelliJ is suddenly much faster and usable again. Turns out all the dependency resolution and index updates and all the shit that made it miserable can just be, mostly, mainly static and fast.

That's not even the Useful Thing in 2026.

As I covered in my dissertation in Software Engineering and Cognitive Load Theory, Cognitive Complexity is what actually kills software. Software is the concretion of Thought Stuff, and the human brain is incredible at coming up with ways to make things overly complex, confuse correlation with causation, complect things that generally are better left independent, and create towering edifices of "all this shit you have to learn" for things that are fundamentally very simple.

If build systems like Ant/Maven/Gradle are any example, any build system runs the risk of being turned into a general purpose Do the Thing tool that has to integrate support for plugins, lifecycles, eventing, becoming a distributed system, and all kinds of gargantuan byzantine complexifiers that all work fine in isolation and turn into a shit sandwich when you put them together.

ALL OF THAT IS USELESS AND WRONG AND YOU SHOULDN'T DO IT WHEN YOU'RE JUST TRYING TO BUILD. FAST FEEDBACK MATTERS. That's why the Functional Crew was so hot shit on REPLs in the 2010s. They're Correct.

It turns out it's not just humans. My agents were burning thousands of tokens having to cross-reference multiple files, dive deep into the heart of complex tooling not written by us, writing workarounds for themselves like "only run the fleet build with 3 workers" and "make sure the init.gradle runs the proper stanza", and a whole Knowledgebase of tips and tricks they had to read, BURNING CONTEXT, just to be able to do things efficiently.

In those first three days, I saw my token usage for bootstrapping the ecosystem on a new Docker dev container drop 70%.

A few of you just went O.O.

Correct.

Not only that: due to the complexity of coordination and patches, I was often having Opus agents drive the thing. Sonnet and Haiku agents would inevitably get confused on failures and start fucking shit up. In the latest round I was able to rebuild my codebase in an hour with a Sonnet. It was able to proactively debug and fix dependency resolution errors and the little Alpha/Beta stage inconsistencies between actively developed packages in an evolving ecosystem that always make integration difficult. This is because, as the functional people famously like to espouse, "more of the system is able to fit in one's head." There just isn't that much there to need to understand and digest.

Better Tools make Simpler Intelligences able to Do More.

Then I had to build Bob.

The prototype took three days. The next month and a half went into a question I'd managed to dodge: What builds Bob?

I built Bob on Iluvatar and Commander. Then I needed Bob to build Iluvatar and Commander. A lovely little chicken-and-egg problem when you're starting with an empty machine.

Previously published jars can hide that circle for a long time. You change an API, rebuild, and discover that the tool doing the rebuilding still needs the old API. Now you're maintaining a working copy of yesterday's world so you can build today's. This was exactly the sort of bullshit I'd written Bob to escape.

The dependency declarations got a second pass too. At first, moving them into annotations on module-info.java felt like enough. But a version string repeated in Java is still a version string repeated. I was still telling hundreds of modules the same facts about their dependencies.

That became the Kompuwiz catalog. A module has a token: a Java type that states its coordinates, repository, dependencies and what it does. The entry states the release once; consumers refer to that entry. Misspell the type and the compiler tells you. Documentation comes from those entries too. One place to say what a module is, and ordinary Java tooling to work with it.

Crucially, the catalog builds with plain javac. It can describe the whole framework without needing the framework to run.

The other half was already in the JDK: java.util.spi.ToolProvider. Java already knows how to find a named tool, hand it arguments and output streams, and get a status back. javac, jar and jlink already speak that language. My build tools could speak it too.

So the build tools shed Iluvatar and Commander. A small launcher finds the ToolProvider and runs it. A bare JDK builds the catalog and the small nucleus needed to get Bob going; Bob then builds the rest. The machinery that builds the framework can start before the framework exists.

Three days got me a replacement for Gradle. The next six weeks made me question how much of my own software that replacement needed. Apparently All Base Assumptions includes mine.

Bob and the stack are Open Source; you can use them under GPLv3 for free software, or contact me for commercial licensing. But the generalizable takeaway here is to remember: What About Bob? That tool that you've been using for years, and have gained all kinds of "war stories" and a giant knowledgebase of How To Use, may be something you can just throw out for a lovable idiot, and watch as things get faster and more efficient as your agents are unbound from supporting a Tower of Babel and can actually spend their resources doing more useful things.