Why code? To make art and play games!
Essay • 1,218 Words • Software Engineering, Artificial Intelligence, Art, Video Games, 2026 • 08/28/2026 • View in graph
On autotelic programming and what’s worth doing
There are 1312 words in this article, and it will probably take you less than 7 minutes to read it.
This article was published 2026-08-28 00:00:00 -0400, which makes this post and me old when I published it.
In this essay, I will argue that not all programming is about building telic software, and it is in this gap where we can define autotelic software, which is worthwhile to do, even in the age of LLMs. But what does that even mean?
I think that when we think of software, we are mostly thinking about tools, which is to say software with telos, a purpose/goal. A spreadsheet, instant messenger, or music player are all tools to enable us to do certain things. This is telic software. These are all noble applications, but there isn’t much intrinsic value in working on these tools, which means there is space for LLM assistance potentially, especially if you build malleable software.
In my mind, art and games are both instances of things where code can be a constitutive part of an autotelic activity. In other words, you are coding in order to make a piece of art or to play a game. In these particular instances, it is also inseparable from the creation or playing, so it becomes autotelic as well.
Art & Coding
The real boon of coding as a tool for art is how cheap tinkering and experimentation is. You can tweak small parameters and get vastly different results out of it near instantaneously (unless recompiles/computations are heavy). You don’t have to wait for hours for the paint to dry like with oils, or eyeball glaze colors/effects like with ceramics. Even if you can fail fast, you still need to understand your medium. If you are doing shader programming, you need to know what parameters you can change and the cause and effects of your changes, if you want to claim any kind of mastery. Beware of never-skilling.
Knowledge is in part memory, and if you never think about something you will never learn it/commit it to memory.
My students sometimes ask why they should memorise things in the age of Google and LLMs. But internalised facts are your bullshit filters and your raw material for creative association. Facts outside your head are inert.
Henry Shevlin (@dioscuri) on X
Like mentioned in the above tweet, having knowledge immediately accessible to you in your mind allows you to make connections between things very quickly.
Programming has real roots in art and creativity. I’m not talking about design as art, but literal art. I’m talking about Logo! If you’ve ever made a turtle move around a screen, thank Seymour Papert and his team. This concept is something very near and dear to my heart, as I developed a number of visual programming tools, Mosaic chief among them. Visual art is a big space like TouchDesigner and Processing or Scratch and Alice, but also audio with TidalCycles/Strudel.
You can generate AI images, video, code, games, really anything, but what value does it hold? The easier something is to generate, the more disposable it becomes because you can just move onto the next thing so quickly without savoring what you just completed.
I’ve used coding agents to create a creative coding environment (see: createos) before, but it quickly became a sprawling mess because I had no mental model of what was happening and had no control over the codebase at all. Studies show less comprehension on generated code compared to manually authored (there are ways around this though). I also had less emotional attachment to the things that I “created”. There have been studies into the “Ikea Effect” for AI-generated code, but they have had varied results so far [1, 2, 3]. (I am using the Ikea Effect as a stand-in for emotional connection to the end result, which isn’t quite what the effect is, but I think that it is a good enough proxy to demonstrate my point.)
Games & Coding
Bernard Suits, a philosopher of games, defined games as follows, “To play a game is to engage in activity directed towards bringing about a specific state of affairs, using only means permitted by rules, where the rules prohibit more efficient in favour of less efficient means, and where such rules are accepted just because they make possible such activity” (from his book The Grasshopper, emphasis mine). I won’t dive into the theory too much, but I would highly recommend his book.
Consider for instance, code golfing and quines. They are perfect for LLMs because of the parallelization that is possible by a subagent fanout for an autoresearch.
-
Code golfing: using the least amount of characters to write a program to perform a certain task
-
Quines: programs that print their own source code
-
Multi-quines: programs that can be run in multiple languages that prints its own source code
-
Quine relays: programs that print a quine for a different language (that eventually cycles back to the first quine)
-
Not quite a quine, but also something fun:
If you choose to code something with limited/no assistance, you have a goal and restriction: we have a game on our hands! There are other ways to make games as well, something that I think we’ll see a surge of soon. I’ve made hardModeCode where you are completing Leetcode problems, but if you make a mistake, you have to clear the whole editor and start again. MLH also has No Light, where you have a short period of time to recreate a website in HTML/CSS without seeing a render until the very end.
We can also have coding as a way to encode steps to solve a problem (writing out puzzle solutions). These would be games like Human Resource Machine or Jeroo (a teaching tool, but a framework for making puzzles). You could also have code as a tool in the game like SQL in Database Detective: Minor Crimes Division. I don’t have a real sense of this space and I’m not sure how it will evolve over time because a lot of it is usually a skill transfer play; whether the player are bringing in expertise or the game is trying to build intuitions/habits to take into “real” coding.
What this means for me
My relationship to code has been changing and will continue to change. I’m not quite sure where it will end up. I loved coding and was cranking out all kinds of projects by hand from 2016-2026, and was an anti-AI stalwart until I was practically forced to use Claude at work. But then after using it for a while, it unlocked something. I was able to take on tasks that I normally wouldn’t have because of tedium or skill. I was able to make strides on projects that I hadn’t touched in years, ideas that I had saved up that I could finally see if they were any good (they weren’t).
When Hank Green said, “I need to come to terms with the fact that the level of dopamine I’ve been getting from interacting with LLMs…with doing more and more and more and more…is not healthy for me”, it made me realize that coming to terms with what that has done to my reward system too. More is not always better. Being productive is not intrinsically good.
Do whatever makes you happy. Don’t fall into any hype cycles, think critically about your workflow, and protect your humanity.
Sincerely,
Rees