What happens when your programming language of choice has almost no presence in AI training data? Developer Dan Haskin found out the hard way: $10 gone in 30 minutes trying to build an MCP server tool (a plugin that connects AI assistants to external services) in Common Lisp, a task he had completed in Python in a day or two for a fraction of the cost using cheaper models.
The post is a candid breakdown of why AI coding assistants are nearly useless for Lisp development, and the reasons are structural - not the kind of thing that gets patched in the next model release.
The Training Data Problem Is Already Shaping Which Languages Survive
LLMs (large language models - the AI systems powering tools like Cursor, Aider, and Claude Code) learn to write code by reading enormous amounts of existing code. Python has millions of public repositories. Common Lisp has a fraction of that. The result is that AI assistants confidently write Python, Go, and JavaScript but fumble with Lisp syntax, reach for outdated libraries, and ignore explicit instructions.
Haskin noted that no matter how clearly he told the AI not to use QuickLisp (a Lisp package manager), it kept defaulting to it anyway - because that's what dominated its training data. The AI wasn't being stubborn; it was following statistical gravity toward the most common patterns it had seen.
This has real cost implications. When an AI assistant doesn't know a language well, it generates more wrong answers. You spend more tokens (the units AI models charge by, roughly comparable to syllables) correcting mistakes. A task that costs $0.50 in Python costs $10 in Lisp - and takes longer.
The REPL Problem Runs Deeper
Beyond training data volume, there's a workflow mismatch. Lisp development traditionally revolves around a REPL (Read-Eval-Print Loop) - an interactive environment where you write a small piece of code, run it immediately, see the result, and iterate in seconds. It's a tight feedback loop built for human-speed experimentation.
AI coding assistants operate on a different rhythm: you write a prompt, wait for a response, evaluate it, write another prompt. That latency doesn't play well with REPL-driven development. The interaction model that makes AI assistants so productive in Python - generate a function, test it, refine it - breaks down when the expected workflow involves live, interactive code evaluation.
Haskin frames this through the lens of "Worse is Better" - the decades-old software philosophy arguing that simpler, more popular solutions beat technically superior ones through sheer adoption momentum. His concern is that AI training data creates a feedback loop: popular languages get better AI support, so developers reach for them more, so they generate more training data, so AI support improves further. Languages outside that loop get left behind.
For most developers using mainstream languages, this is background noise. But for anyone working in Clojure, Racket, Haskell, Erlang, or other lower-training-data languages, it's a real productivity tax. The economic pressure to switch to Python or TypeScript - not because those languages are better for your problem, but because AI tools work better in them - is a new and genuinely strange kind of technical constraint.
The practical upshot: if your work is Lisp-heavy and you're paying for AI coding assistance, you're probably overpaying for underperformance. That gap is unlikely to close unless the open-source Lisp community dramatically increases the volume of publicly available code - or someone specifically fine-tunes (adapts a model on targeted data) a model for the language.