Writing Lisp is AI resistant and I'm sad

In case you’re not familiar, I will point you to the classical program synthesis literature. There the task is to take a spec written in say first-order logic, and output a program that satisfies this spec.

I think the biggest barrier to adoption of program synthesis is writing the spec/maintaining it as the project matures. Sometimes we don’t even know what we want as the spec until we have a first draft of the program. But as you’re pointing out, LLMs could help address all of these problems.

With Gemini 3, I wrote an Emacs Lisp which can tell if a number is prime or not using only primitive recursive functions. That was done at the end of last year, and none of the frontier LLMs were able to do it earlier in 2025.

I had some test functions where minimization could be optionally used, but wanted to do one where minimization was needed, like the Ackermann function. Most of the frontier models struggled with doing this, although I may have been prompting incorrectly. Although - if I had been prompting totally correctly, I probably could have gotten what I got out of a frontier LLM in early 2025 and before.

Incidentally the test function that tells you if a number is prime in Emacs Lisp with primitive recursion is

(defalias 'prime (c (c (c (r 's (c 'z (p 1))) (p 1) 'z) (c (r (p 1) (c 's (p 2))) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 1) (p 2))) (p 2) (p 1)) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 2) (p 1))) (p 2) (p 1)))) (c (c (r 'z (c (r (p 1) (c 's (p 2))) (c (c (r 'z (c (r (p 1) (c 's (p 2))) (p 2) (p 3))) (c (c (c (r 's (c 'z (p 1))) (p 1) 'z) (c (r (p 1) (c 's (p 2))) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 1) (p 2))) (p 2) (p 1)) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 2) (p 1))) (p 2) (p 1)))) (c (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (c (r 'z (c (r (p 1) (c 's (p 2))) (p 2) (p 3))) (p 2) (c (r 'z (c (r (p 1) (c 's (p 2))) (p 2) (c (c (r 's (c 'z (p 1))) (p 1) 'z) (c (r 'z (c (r 'z (c (r (p 1) (c 's (p 2))) (p 2) (p 3))) (c 's (p 2)) (c (c (r 's (c 'z (p 1))) (p 1) 'z) (c (c (c (r 's (c 'z (p 1))) (p 1) 'z) (c (r (p 1) (c 's (p 2))) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 1) (p 2))) (p 2) (p 1)) (c (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (c (r (p 1) (c (c (r 'z (p 1)) (p 1) 'z) (p 2))) (p 2) (p 1))) (p 2) (p 1)))) (c 's (p 2)) (p 3))))) (c 's (p 1)) (p 3))))) (p 1) (p 2))) (p 1)) (p 1) (p 2)) (c 'z (p 1))) (c (c (r 'z (c (c 's 'z) (p 1))) (p 1) 'z) (p 1))) (p 3) (c 's (p 1))) (p 2))) (p 1) (p 1)) (p 1)) (c 's (c 's 'z))))

Working with Lisp dialects (because of proper Lisp REPL) is nothing short of magic. I hooked up my Emacs AI tools to it. ECA and gptel-agent are able to change any elisp code, run check-parens, apply changes immediately - unload, reload things, changing the behavior of my editor on the fly. I once even have asked a model to use the built-in profiler and it worked. I vibe-coded my MCP servers through Clojure REPL.

On Mac I can poke virtually any aspect of my system - my Hammerspoon config is written in Fennel - has a REPL.

On Linux, I have a babashka loop with nrepl, that "talks" to Hyprland's IPC through a socket - AI can diagnose the state of WM and move things around, change color temp, affect gamma, etc.

I have made little prototypes with nbb and Playwright, and the model had no difficulty understanding the REPL loop - it was able to inspect every DOM element going to it through the REPL.

We have a few services written in Clojure, we keep nrepl on staging k8s cluster. I have vide-coded, fixed and tested things on the go - LLM can directly eval things there. Fixing bugs in Python, Java and Go takes completely different kind of loop - sometimes it feels like AI even gets excited when there's a REPL to mess around.

If anything - being a lisper in AI-era only reinforced my belief that making a deliberate choice to learn and understand the philosophy of Lisp years ago was the best choice I could've made. I future-proofed myself for decades.

Working with Lisp for a human programmer requires mindset adjustment - AI is no different here - you just have to tell it where the REPL is.

I've been vibing a full r7rs scheme on ChezScheme and a proper language MCP and LSP go a long ways. Especially around keeping parenthesis balanced at all time. Give the LLM instructions to vote for features on the MCP and then you help reduce its friction points.

N=1 anecdote, but I've actually found I'm more likely to use different languages now that I'm using LLMs because I don't have to think about the different syntax as much.

For example I've been on the lookout for a better language than bash to use for shell scripting, but didn't like the options I was familiar with for various reasons (go, python, js, swift, etc). I did some research and Nim seemed to fit my needs perfectly. I was able to quickly convert some scripts I had to Nim using an LLM, where in the past I wouldn't have bothered to get used to a whole new language just for a few scripts.

Or right now I'm working on a personal full stack project and chose Go for the backend services, TypeScript/React for the frontend, and also have one service in Python because the library I need is easier to use there than in Go. Normally it would be a frustrating to context switch languages, but with LLMs I'm thinking more about the architecture and logic than specific syntax so it's been pretty frictionless.

I've generally always been one to want to use the best language/stack/platform for the job, so I'm probably biased, but I think LLMs actually make it easier to use languages you're less familiar with as long as you understand fundamental programming concepts. I'm hoping they end up promoting the usage or uptake of some of the less popular languages like Nim due to the lower learning curve needed to get useful output from them.