Vibe Clojure 2: Ahead of Time

I wrote previously about my attempt to write a Clojure dialect in Rust. I’ve been using coding agents to do some of the work here, really to see if these tools can truly accelerate the development of significant and, importantly, useful software.

I’ve gotten far enough that it can run a significant test suite, both interpreted:

cargo run -p cljrs test --src-path clojure-test-suite/test

Or compiled with AOT to a native binary:

cargo run -p cljrs compile -o ./test-suite --test clojure-test-suite/test 
./test-suite

This feels like a significant milestone; it should be possible to compile a significant Clojure program (provided it’s portable enough) and run it as a native binary on this system. It’s a reasonable step up in performance, too: interpreted the full test suite takes about 47 seconds. AOT compiled it takes about 10s. Clojure on the JVM can do it in about 7 seconds. Next up in the plan would be JIT compilation of Clojure code and optimization phases.

I did want to take an aside on the coding agents I’m using to do some of this and provide some commentary. I had done a lot of the work with Claude Opus 4.6, but I’ve recently started experimenting with running Qwen3-Coder-Next locally on my laptop with a quantized version. The quality and speed of the local model are definitely not as good as the hosted model, but I also haven’t had to stop work to wait for token limits to clear. It’s been kind of a meme among people trying to use Anthropic models recently: if you ask something at the wrong time of day, you basically get somewhere between 3 and 5 prompts before your token limit is reached. I genuinely thought something was going wrong when I tried doing something in the morning, it would get halfway through the first thing I asked it to do before it ran out of tokens. I hope not, but this feels like where these AI companies are headed: equipment, electricity, training, and inference are so expensive that they won’t be able to offer much for the small fees they charge. Running things locally might be the endgame here; for data control and costs, keeping it local is the best bet. Also, it’s becoming increasingly clear that it’s the harness, not the model, that’s important. Claude Code can work admirably against a smaller, local model.

Anyway, I might be looking to get an external system sometime soon to offload local models; running inference on the same laptop I’m trying to use isn’t the best experience.

That out of the way, though, my next struggle here is to determine whether this code is any good. It interprets Clojure, but does it do so efficiently? It compiles Clojure to native code, but is that native code optimized well? Even if both of those have “yes” as an answer, is that code understandable and extensible easily? By either a machine or a human?

It’s very difficult to answer this, to be honest. I’m going through the code that was generated and trying to get a sense of whether it is doing things sanely, but garbage collectors and compilers are well outside my career experience, so I’m out of my element trying to judge what the machine emitted. I know it cut corners and punted important things off for later. I found a few of these and asked it to fix them, or fixed them myself. That could only be what was easily visible, leaving so much poor, unmaintainable code scattered all over. Or maybe it’s all perfect, easy to maintain, and extend. Who knows?