GoKawiilIn an insulting, ironic blow to the neats, the scruffies created an AI that much prefers to write anything but Lisp.
I use agentic AI a lot at work to do my job as a DevOps engineer. I use OpenRouter with the Goose CLI tool, and I've gotten a pretty good configuration file going with it.
I have lately started writing a tool that converts between different RSS reader formats. I started writing it in Lisp, of course. It's my favorite language.
I had a problem though. I had to teach the AI how to use the REPL. Initially, I had it run commands to interact with the REPL via tmux, e.g. tmux capture-pane -t 0.0 -p | tail -n 1 . It worked okay, but I noticed that REPL development was very hard for the AI. Claude really spun its wheels. Lesser AIs would be very much worse. I'd blow $10-$20 in a handful of minutes with not much to show for it but sort of OK lisp code that I ended up rewriting. I tried doing it with cheaper AIs like DeepSeek and Qwen, which I found did OK at work for some tasks, but it wasn't working.
I figured maybe if I made REPL development smoother, the AI would do a better job. I wanted to give goose unlimited rights to the REPL while still guarding general command rights, too. So, I created a tool called tmux-repl-mcp that would make interacting with the REPL more straightforward. Instead of consuming a ton of tokens, executing a bunch of sleep commands, and parsing tmux output, the could just run execute_command in the repl and get its output.
I wrote this tool in Python since a lot of my AI tooling in my goose configuration file was built around uvx already. I liked that I just had to install uvx and all of a sudden goose could use all these tools. I already had all this stuff built up in my configuration file, so I figured it would be easier for folks to use if it were distributed in the same way. Besides, the official guide to write an MCP server were in non-lisp languages anyway.
The difference in writing Python and Lisp with AI was of course dramatic, downright wild. I got it to write all of the code and all the tests for the code. I had to debug it semi-manually, but I was still able to bang together this more-than-nothing tool in like a day or two, and with cheap models at that. Worst of all, the experience for me was the same in many ways: I wrote code by being a poor man's product owner to the AI for both, only the AI would perform well with the Python. I felt none of the happiness I usually feel just writing Lisp.
Going back to my actual project was painful. I ended up writing one of the files ( src/newsboat.lisp ) by hand. I was in the middle of debugging it when I realized how much harder it was to write with AI in Lisp. I had to switch back to Claude, which at least makes some progress relative to the others. The tmux-repl-mcp tool helped, but I still blew through $10 in like 30 minutes. The signal-to-noise ratio, or in other words, the wheel-spinning-to-progress ratio in the AI session was night and day compared to Python. And in AI, you pay for the noise and the signal together.
Now I'm thinking of rewriting it in Go. With AI, code is cheap, but only if you use a language for which AI has a lot of training data.
Another frustration has been tooling. Lisp has a lot of tools to choose from. I like using OCICL instead of QuickLisp, for example, but I had to tell the AI to not use quicklisp every single session. It was like built into the AI to use it. This also helped me realize that AI generates code sort of on a path of least resistance.
... continue reading