10 Year Coding Birthday

I recently hit my 10-year coding birthday. To celebrate, I revisited one of my earliest projects. Partly because it helped shape how I think about programming, complexity, and learning itself, but mostly because it's fun to reminisce.

In my very first computer science class, my partner and I decided to implement a Rubik's Cube solver. We were exceptionally naïve. Not only had neither of us actually solved a cube, but we also had no experience building any kind of user interface for inputting a cube's current state. Suffice it to say, the project was a spectacular failure. We never got working code, and I'm thankful the teacher took pity on us. Partly, I suspect, because he felt bad for not steering us toward a more manageable project.

Okay, enough about the past. Let's fast-forward to today.

I wanted to see if I could circle back to this project with ten more years of experience and ten years of progress in software. A lot has changed. I'm no longer using Java to make applets (I'm still not entirely sure what those were, lol). These days, I've fallen in love with building quick, cheap, fun projects and deploying them effortlessly with Vercel. This project fit the bill perfectly.

My second curiosity was how well AI coding assistants would handle the algorithmic portion of a Rubik's Cube solver. I used Claude Code specifically. I already knew it would absolutely crush the UI, and it did. What took us three weeks of effort ten years ago was knocked out in about twenty minutes with a few prompts and some iteration.

Claude Code even did a fantastic job building a move "engine": a way to track cube state, define notation, enumerate possible moves, and apply transformations to that state. All of that worked beautifully.

Then we hit a huge wall: the actual solving algorithm.

Starting naïvely, I asked Claude to come up with its own algorithm. This led to the usual confident stream of output. The algorithm might have worked, but it was over 20,000 moves long, so verifying it on a physical cube was completely out of the question.

Next, I tried having Claude use web search to work from established algorithms, based on some external research. We landed on the Thistlethwaite algorithm because it's considered relatively friendly for computer solvers. While we did manage to produce a sequence of moves that supposedly solved the cube from any state, it didn't hold up under manual verification.

After burning many prompts and tokens trying to define correct behavior through automated tests, it still wasn't working. Eventually, Claude suggested finding a reference implementation of the algorithm in code so it could use that directly. We found one easily enough on GitHub, but at that point, the experiment felt like it had failed. Sure, we could copy an existing solver, but that's not really in the spirit of the problem. At that point, we might as well just plug the UI into solver api.

That's when a different challenge caught my interest.

I knew Rubik's Cubes can represent groups in the mathematical sense of the word. So why not use the UI I'd already built as a group theory playground? That pivot let me combine my interest in math while still salvaging the project, and honestly, it felt more interesting anyway.

So we pivoted.

Feel free to check out the group theory playground. And a quick disclaimer: it's been ages since I last took abstract algebra.