AI for Less Popular Programming Languages

AI agents are quite popular, from Claude Code to Cursor to Codex, they all can write code for the most popular programming languages such as TypeScript and Python. However, less popular programming languages have their own nuances that can make an AI agent spin its wheels and burn through far more tokens than necessary.

AI Agents vs. Emacs Lisp

I had this happen when using OpenCode and Junie to write an Emacs plugin that had only one file. I sometimes use Emacs as text editor for distraction-free coding, in addition to VS Code, and part of the power of Emacs and other IDEs is in the plugins. Writing new plugins for Emacs or modifying the useful ones requires using the Emacs Lisp programming language.

Balancing Parentheses

Where in a language like TypeScript or Python we assign variables and call functions like this:

test = 123
hello_world(test)

In Emacs Lisp we do this:

(let ((test 123))
  (hello-world test))

Notice the parentheses wrap the variable assignment and the function call? That is what the AI agents kept getting tripped on. It did not matter which AI model I used, they all had issues with unbalanced parenthesis and other syntax errors. As part of the AGENTS.md prompt, I mention ways to check for this with built-in function, check-parens and byte compilation. Unfortunately, while the AI agents could check for this issue, they looped and burned tokens on custom scripts to pinpoint exactly where in the file there was a missing or extra bracket. Remember, this is for a one-file plugin, imagine how bad this could get with more files.

OpenCode with GLM 5.2 wrote custom Emacs Lisp to pinpoint within the file where the missing or extra bracket could be. It rewrote the custom code to check various parts of the file. Each of those is a tool use and many, many tokens burned. The next step is to turn those custom scripts written by the AI agent into a tool to speed up the process, or a skill that shows how to use other tools to speed up the process.

Packages and Dependencies

Another issue is that the AI agents, no matter the model, favoured writing custom code. When pointing out that Emacs packages and dependencies can be added, they needed an addition to the prompt to tell the user of the plugin that the dependency needs to be installed, and to let them know if a fallback is being used.

This could be helped by adding an MCP or tool that queries the Emacs package repository sources. I worked around it by searching for packages myself and then adding them to the prompt. For instance, I mainly use ansi-term as the terminal in Emacs. When I asked the OpenCode AI agent to fix terminal rendering, it tried to configure and fix ansi-term instead of suggesting that more modern terminals such as eat and vterm exist.

For less popular languages that are newer and in rapid active development, the popular packages for them could change from one month to the next. Without a way for an AI model to check for the latest packages to use, the code becomes legacy as soon as it is written.

AI for Less Popular Programming Languages

Which brings us back to how do we optimize AI agents for less popular programming languages. If using AI agents to write a plugin for a text editor that has been around for decades with plenty of code examples, documentation, and tutorials runs into issues, will less popular programming languages require much more effort to be usable?

Here are a few ideas:

• Pack more context into the prompt.
• Use RAG (Retrieval Augmented Generation) to add relevant examples to the prompt.
• Create tools that AI agents can use to speed up linting, formatting, and compilation instead of having them "re-learn" it every time.
• Create skills that codify common patterns of testing, debugging, and documenting.
• Map one language to another. Instead of using a syntax that can trip up the AI agent, use a different syntax that can then be mapped and transformed into the other language.