Writing Lisp is AI Resistant and I'm Sad
背景
作者是一位DevOps工程师，日常使用AI agent（Goose + OpenRouter）辅助工作。他同时也在写一个Lisp项目（RSS格式转换工具），却遇到了AI在Lisp编程上的巨大困难。
核心问题：AI在Lisp上表现极差
- Python: 几天时间、便宜模型就能写出完整工具 + 测试
- Lisp: $10在30分钟内烧完，代码质量还很差
原因分析
1. 训练数据偏差
AI按"阻力最小路径"生成代码，倾向于使用常见工具（如Quicklisp）。Lisp在互联网上的数据量远少于Python/Go，AI对其不熟悉。
2. REPL开发模式与AI API不兼容
- REPL开发降低人类开发者的延迟
- 但AI API本身就有高延迟
- AI需要高准确率（因为无法快速迭代试错），而这恰好是Lisp的弱项
3. 工具链问题
Lisp有众多工具选择（OCICL vs Quicklisp等），AI总是试图用Quicklisp，每次都要纠正。
作者的挣扎
作者尝试了各种方法：
- 用tmux与REPL交互（效果一般）
- 用便宜模型（DeepSeek、Qwen）——更差
- 写了一个MCP工具 tmux-repl-mcp 来改善交互
- 最终考虑用Go重写整个项目
深刻洞察
"With AI, code is cheap, but only if you use a language for which AI has a lot of training data."
无论用哪种语言开发，最终体验都是一样：作者变成了"、产品经理"——告诉AI要什么，让它去写。区别在于AI在某些语言上表现更好，而这些语言恰好是互联网音量最大的。
Plank Road类比
作者用一个比喻总结：19世纪的泥泞道路vs木板路vs铁路。木板路比泥路好走，但铁路出现后没人再走木板路。Lisp就像木板路——曾经美好，但当更"高效"的方案（Python/Go）出现时，情怀敌不过效率。
结论
这是"Worse is Better"理论的又一次验证。作者好奇Lisp将如何" surviving the AI era"——也许需要新的工具和方式让AI更好地与Lisp交互。
原文: https://blog.djhaskin.com/blog/writing-lisp-is-ai-resistant-and-im-sad/