The core argument is structural, not nostalgic: if LLMs have made code-writing cheap and fast, the bottleneck moves to the feedback loop — how quickly you can test, debug, and iterate. Common Lisp's image-based runtime, where functions are hot-swapped into a live process without restarts, collapses that loop to near-zero. The interactive debugger, which pauses execution with full stack context instead of crashing, means an LLM agent can inspect and fix errors in-place rather than parsing crash logs and restarting. These are real architectural properties, not marketing. The second lever is conciseness. The author claims Common Lisp programs run six to seven times shorter than equivalent Python, which means more of the codebase fits inside an LLM's context window. This matters because LLM errors correlate with incomplete context — when the model can't see the whole program, it makes changes that break distant code. Fewer tokens also means lower API costs. Both claims are directionally plausible but supported only by the author's personal experience, not controlled measurement. The macro argument extends this further. Because Lisp code is data (lists of symbols), programs can rewrite themselves — macros generate code at compile time. This lets developers build domain-specific languages (DSLs) that encode business logic as language constructs. The ERP example is illustrative: if your enterprise software exposes a well-designed DSL, end users with LLM assistants can customize it without touching the underlying system. Changes inherit the DSL's opinions and constraints, reducing the chance of breakage. The ecosystem weakness is acknowledged honestly: Quicklisp has a couple thousand packages versus npm's millions. The author's counter — that massive dependency trees are a security liability and LLMs can port missing libraries — is half-right. Supply-chain attacks are real and growing. But "just have the LLM port it" handwaves away the hardest parts: testing, edge cases, and maintenance. Porting a library is not the same as maintaining one. The hiring argument is the weakest link. "Just make candidates learn Common Lisp in the interview" conflates learning speed with production competence. A language with a tiny community means fewer battle-tested patterns, fewer Stack Overflow answers for edge cases, and a thinner bench when someone leaves. LLMs partially offset this — they can generate Common Lisp — but the training data for CL is orders of magnitude smaller than for Python or JavaScript, which means LLM output quality for CL is likely worse, not better. What's missing entirely is evidence. No benchmarks comparing LLM-assisted development speed across languages. No measurements of context-window utilization. No data on LLM code quality in Common Lisp versus Python. The 6-7x conciseness claim is unverified. The "your program won't crash" claim glosses over the fact that condition handling requires expertise that most LLM agents don't have. The argument is a hypothesis, not a result. The hypothesis deserves testing. The structural properties are real: image-based development, interactive debugging, homoiconicity, and macro-driven DSLs are genuine differentiators that align with LLM-era constraints. But "I built some apps and they were shorter" is not evidence at the scale this argument requires. Someone needs to actually measure this.
