In my last post (Collaborative Optimization on the Cody Frontier), I showed how four people, ostensibly competitors in a Cody competition, came to collaborate on a tricky problem. The storyline there was that Cody rewards you for writing the shortest possible code. All improvements are welcome, whether you're making a big algorithmic breakthrough or shaving a single character with a minor syntactic tweak.

One of the four competitors, Wang Zi-Xiang, even published an article about how to reduce the size of a Cody solution. He noted that some of the techniques are always valuable, while others, though they serve you well in Cody, are not appropriate for working code. Code "golf" is a fun diversion, but it's generally a bad idea to use these techniques willy-nilly in the real world.

Let's break down a few that Wang Zi-Xiang and others mentioned.

Having spent a fair amount of time looking at what four well-trained, well-motivated humans can do, a devilish thought came into my mind. What, thought I, would a Large Language Model make of this problem?

It should no longer be a surprise that AI can solve any Cody problem you give it. After all, these things are acing the International Math Olympiad. If you're playing Cody these days, you're doing it for yourself, for the puzzle-solving thrill and the fun of learning nifty tricks. If, on the other hand, you just want to kick back and let AI solve it for you, well... it certainly will. But it would be like driving the marathon route in your car. Fast, but not much fun, and the runners get in your way.

Even so, I was burning to know how well AI could do on this particular problem. So I pointed Claude Code at Problem 61069, Clueless. It solved the problem quickly enough, coming in with a score of 700. Initially I didn't ask it to make the answer small. But then I set up an auto-improvement loop to shrink the code. I even pointed it to Wang Zi-Xiang's rules. Cody provides an ideal format for auto-improvement, because it comes equipped with a test suite as well as a simple metric for to be improved: size.

As it turned out, Claude ran out of gas well before it challenged the best our human team could do. Across 17 separate improvements, Claude was able to get from 700 to 239, still 87 points away from the human collaboration. The image below shows how it reached diminishing returns after ten or so tries.

After Claude beat its anthropomorphic head against this challenge for a few hours, I showed it the solution from the human competitors.

About the 152 node solution, Claude says this:

This is a beautiful, extremely dense solution.

I studied the 152-node contest winner closely and tried to golf it below 152. I couldn't beat it — and I'm confident it's essentially at the floor for its algorithm.

What makes it 152 (and why it's smaller than my 239): it's a different algorithm. Mine is a monotone constraint-propagation lattice (facts only ever tighten, which needs guards). The 152 instead recomputes the entire belief array from scratch every iteration and reinjects the hard facts afterward — no guards, no idempotence bookkeeping. The whole solver is init + one loop with one deal statement + one extraction, leaning on three contest-grade tricks:

- str2num('...') to collapse constant vectors to 2 nodes
- ans as the unnamed state variable
- a single multi-output deal (all RHS computed first, LHS assigned left-to-right) that fuses the recompute and all fact-reinjections into one statement

Huzzah! Strike a blow for humanity! For their fine bot-defying efforts, I will once again list our four heroes. Well done!

• Stefan Abendroth
• Vasilis Bellos
• Dharmesh Jain (a.k.a. JKMSMKJ)
• Wang Zi-Xiang