slop16 was an attempt at writing a SWEET16 interpreter in Zig using ChatGPT.
The actual transcript of the ChatGPT session is in chatgpt.txt.
The generated code is obviously just slop, not fit for purpose, and seems to have no relation to SWEET16 but looks more like a simple/generic 16 bit processor, but I decided to clean it up and fix up the obvious bugs and get it running just to see how much work it would take to turn it into something useful.
Looking at the git timestamps, I spent nearly an hour fixing up sloppy code that was generated in mere seconds. Rather than throw it away I've decided to put it back on Github for the record. Perhaps the models will have something to train on, to generate better code, next time around.
I've written a couple of virtual machine interpreters as part of romforth (https://github.com/romforth/romforth). While working on the 6502 port in romforth, I thought of implementing a SWEET16 interpreter as well. Since AI is the new hotness, I was nerdsniped into attempting to get ChatGPT to write the SWEET16 interpreter in Zig for me - consider this my attempt at turning into a true, real man "10x programmer" with my newly acquired AI superpowers.
Unfortunately, the prompt that I used:
Write an emulator for SWEET-16 in Zig. Add tests for each opcode.
was clearly insufficient for the ChatGPT model to generate anything close to the actual SWEET16 ISA. I think I may have used ChatGPT's "O1 mini" model for this - only because it was the one available for free without any signup on their website at https://chat.openai.com
It is reasonable to ask if better prompt engineering on my part would have
generated better code. I'll let other folks who are more proficient at this new
field answer that question. I'll admit that I did not try to keep saying "make
it better" after each iteration. I did try to see if it could figure out the
version change in Zig that caused the @intCast error: expected 1 argument, found 2 by using the expedient approach (that used to work on Google, earlier)
of feeding back that error into ChatGPT, but that did not result in any changes
so I've left it out of the transcript.
I assume Zig 0.13.0 is too new to have made it into any of OpenAI's training sets so we'll just have to wait and see if this class of issues gets resolved in a better way over time.
Anyway, this does give me an intro into the brave new world of coding where I assume most folks will be cleaning up generated slop that will inevitably make its way into code everywhere.
Although I'm disappointed in the current code that was generated, I have to assume that with better models and newer techniques, things will get better over time. Even if it doesn't, even this sloppy code does give a framework on which you can build and it is code that I didn't have to laboriously type in and induce carpal tunnel on my aging fingers and for that I'm truly grateful.
In this age of generated code I have to wonder how code licenses will be affected. To start off, SWEET16 was developed by Woz so I assume the license for that belongs to Apple, but the generated code here is most definitely nothing like SWEET16 so I assume Apple will almost certainly not want to have anything to do with this code or the slop16/SWEET16 name which is used here.
The US courts have previously ruled that AI generated content does not carry copyright so I'm tempted to stick a CC0 on this or put it under public domain and call it a day. Using the liberal MIT license would be yet another reasonable approach, but then, who exactly is the "author" who needs to be credited in the MIT license for this abomination?
After cogitating over it for a bit, I think that the reasonable way to figure out who owns copyright is to see who spent time and effort on it. In this case the AI companies trained the models on code that they may or may not have the rights to use so I'll chalk that up as a copyright wash between the AI companies and the coders. So we are left with how much effort it took to generate and fix the code. Generating the code took seconds and given that the majority of time was then spent by me to get it to this state makes me in some sense the "owner" of this disappointingly sad piece of code. Add another hour thinking about the LICENSE to be applied to this code and by all measures, I own this thing!
So I'll stick my favorite license which is the AGPL/Affero GPL license on it so that any additional changes that may happen to this code in the future will remain openly accessible to anyone to read and/or make further changes. The likelihood of any changes at all to this code is pretty unlikely, if you ask me, but as Yogi Berra may have said, the future is very hard to predict.