I got a Claude Max subscription and have been playing around.

First big experiment was to see if we could reimplement a part of our pipeline from Julia into Rust. The quality of the code it produced was really good, and it did good analyses on what parts would be easier or harder to port. Eventually this convinced us that a port wouldn't have been worthwhile, because the Rust <> Julia interop is currently quite difficult. I think it might have taken us several days to come to that conclusion otherwise, so this was a big win.

Second significant experiment was asking Claude Code to optimize a pipeline. It pretty much failed abysmally – it successfully added a lot of profiling and came up with a lot of ideas, but not a single one of them made the code any faster. Later, I was able to make a significant improvement to that pipeline with about half an hour of work. So, a failure here.

Third was a moderately difficult refactor, replacing some dicts with structs, that then get serialized and read in another part of the codebase. Claude Code did really well here – it occasionally produced code that was overly verbose, but nothing was *wrong*, and it took corrections/feedback quite effectively. Another big win here.

In git, commits play competing roles. They represent the mechanical history of your codebase, letting you restore/merge the state at various points. They're also often used as a legible, coherent history meant for reading or git bisect.

These two uses are at odds with each other – for the mechanical part, you want to make lots of small commits all the time, and for the legible part you want to have a small number of meaningful changes.

There are ways around this within git – for example, git rebase -i lets you create a new set of reorganized commits that have the same end result as your original commits. But all of these methods have enough friction that I've never seen a team actually stick to them.

I've been playing around with jj, a version control system on top of git. jj works seamlessly with existing git repositories/commands, and you can undo all operations, so trying it is very cheap.

jj gets around this problem by explicitly having separate concepts for Revisions (representing the mechanical history) and Changes (representing the logical history.)

Revisions are saved every time you do anything in jj, even with commands like jj log. Amongst other things, this lets you undo any command.

Changes, unlike commits, can be edited after creation. Suppose you have Change 1 -> Change 2 -> ... -> Change n, and then notice you made a typo in Change 1. In git, I would usually just make fixing the typo Commit n + 1, and not bother to go back, rebase, etc. In jj, I can just edit Change 1.

I've only been trying this for two weeks, but I like it a lot so far – I find myself making PRs with much cleaner commit histories, and experimenting more because I know I can just undo when needed.