Forge, meet Claude

For years, I used Xmonad to organize my screen. I spent hours customizing it but I kept running into minor annoyances from not running a “proper” Desktop environment (e.g., daemons not starting on login because I was responsible for starting them). When I started using a laptop more regularly, these annoyances kept popping up and I decided to switch to Gnome and manually organize my screen.

Every so often, I would look at the options for tiling window managers in Gnome and found a reason not to try them until recently when I tried PaperWM. I liked the discrete workspaces that I had in Xmonad and found the scrollable tiles of PaperWM to be too unfamiliar. After uninstalling it but still feeling motivated, I looked at some screencasts from Forge and they looked great. I saw that Forge was looking for a maintainer but the last commit was a couple of weeks ago so I thought, maybe things are still moving along, albeit slowly.

The first issue that I encountered was that make would not run on my system. Having used Claude recently for a project (gamify-ccda), I figured that it would easily fix the Makefile, resulting in my first PR. After installing the extension and using it for a bit, I was hooked. There were a few bugs and differences from my Xmonad environment but this was great.

In the last few weeks, I have spent a lot of time playing with Claude on “greenfield” projects and I have been curious about how it would perform on an existing project. I wanted to see if I could use Claude to make a dent in the backlog of issues (140 as of today) and reduce some of the testing burden.

Strategy

The strategy that I am following is as follows:

• Export all the issues from the repo using gh in JSON format.
• Use Claude to review issues and create a ROADMAP.
• Focus Claude on bugs that do not require a lot of code changes.

In parallel, on a different branch, I am having Claude write comprehensive testing for the “vanilla” code base. My goal is to have one branch that fixes as many issues as possible and another that implements a complete suite of unit tests, including the demonstration of all known bugs. The test would then be, does the “fixed” branch pass all the generated unit tests?

Progress

Over the last couple of days, I have been iterating with Claude and have made some progress. Based on Claude’s assessment (which may be wrong) we have fixed 33 issues:

Conclusion

So far, this seems like it might be worthwhile. I do not trust that Claude has actually fixed all the bugs “correctly” but I am running the modified version now. Hopefully the strategy of fixing bugs in one branch and building a test suite in another will be helpful for verification. I am interested to explore how Claude does on more complicated bugs. Unfortunately, I hit my subscription limit for the week and will have to continue this exploration another time.

Bonus

I find cheat sheets super helpful when learning keyboard shortcuts so, following the theme of this post, I had Claude make one (PDF).

Links

• Fork with fixes
• Fork with unit tests
• Cheatsheet