Can you “vibe code” in Common Lisp?
Short answer, no.
I set out to give it a try. The idea behind “vibe coding” is to use an AI to generate the code and to blindly accept everything it generates. You offer some feedback about error messages and whether the code is doing something close to what you want, but you specifically don’t try to analyze and understand the code being generated. You certainly don’t try to debug it and fix it.
A.I. is trained on a lot of open source code. If your language is popular, there is a lot of code to train on. Chances are, if you have a problem, then not only has someone attempted to code it up in Python, but several people have given it a try and someone has ported it to JavaScript. Someone has solved your problem on StackOverflow.
Common Lisp is not a popular language. There is not a lot of code to train on, and most of it is someone’s homework. So for any particular problem, the A.I. doesn’t have a lot to go on. It becomes clear pretty quickly that the A.I. has no understanding of what it is doing, it is just trying to synthesize something that is similiar to what it has seen before, and if it hasn’t seem much, you don’t get much.
So I tried to vibe code in Common Lisp. I decided to try to write a Minesweeper game. That seemed like it had probably been done enough times before that the A.I. might be able to generate some vibe code.
I told it that we were going to write a video game and that it
should generate an asd file for the game, and some skeleton code
that would be a good start. It generated an asd file and
four small
files: main.lisp, game.lisp, input.lisp,
and graphics.lisp. There was little actual code in the
files, just some function stubs, but you could see where the
cross-file dependencies were going to be.
The asd file wouldn’t load. The generated files had some minor dependencies upon each other and imported the required symbols from the other files. This imposed an implicit load order because a file couldn’t be loaded until the file it depended on had created the package for the symbols that it referenced. This is an old problem in Common Lisp, and the solution is to set up all the packages before loading anything. But I was vibing, so I told the AI that the forward references of the symbols were causing problems.
The AI added require statements into the files to try
get them to load in a working order. It didn’t
help. require statements have a whole bunch of issues
and aren’t used very much thes days. The modern solution is to make
the dependencies explicit in the system definition file. I gave the
AI a direct instruction to make sure that
the package.lisp file loaded before any other. Rather
than edit the asd file, it decided to add even more require
statements.
I declared failure at this point and manually edited
the package.lisp file to create the packages and import
the inital symbols, I added a dependecy on
the package.lisp file to every other file, and I
removed all the spurious require statements. It was
clear the AI was not going to hit upon this solution.
The AI obviously has no model of what the package system is. It
doesn’t reason that you need to load it first. It simply knows that
it can insert require statements to express a
dependency. So it thrashes around added require
statements in the hope that it will converge to a solution. It
converged to a circular dependency instead.