Something I hadn’t thought of until, well, yesterday:
Like it or not, LLMs are a new form of HCI, and (also like it or not) there’s some non-trivial probability of agentic workflows replacing some, or a lot, of what we now do with a mouse and short search engine queries. At least one designer (YouTube link) argues that 2026 is likely to be a tipping point where GUI-style HCI will decline (rapidly) and agents will rise. That particular video essay I take with a grain of salt, because there seems to be some commercial motivation behind it (and I have other specific objections to it as well), but it did start me thinking:
If current live coding approaches are rooted in the GUI paradigm, what does live coding look like if GUIs decline? It seems to me that there’s a fundamental tension between live coding and LLMs, where LLMs in some ways take us back to mainframe batch processing (submit a huge agentic coding job, wait, and get back a big chunk of probably bloated, insecure code at the end, oh but there’s my bias showing), and live coding necessarily favors brevity (not English’s strong suit…) and rapid response.
I wonder if there’s an opportunity here – could a micro-language-model be trained to spit out Tidal or hydra code fast based on some sort of live-coding-oriented pidgin? What would that even look like? I have to admit, it’s hard for me to imagine (and preparation of a sizable tagged corpus of live coding training data seems… labor-intensive to me). But it’s a little easier for me to imagine, say, 4-5 years down the road: “Algorave? Jeez. Are they still writing code? In 2030?”
I guess live coding was never intentionally an oppositional practice, but it certainly asked excellent questions about the modes of HCI that have been dominant over the last couple of decades. If it’s true that those dominant modes are about to change (seems likely, though maybe not as totalizing as that YT essayist suggests), what are the questions that live coding should be asking about that? Certainly current LLM research is strongly oriented towards particular domains of activity, and the reasons for focusing on those domains are at least as much political and economic as they are scientific. There’s a lot of room for critique there, which could take the form of live artistic activity that resists being folded into the Suno “one prompt and look! you’re a mediocre singer/songwriter, and don’t you dare aspire to anything else” hive.
hjh
Here’s a nice talk on this topic:
I disagree that live coding isn’t oppositional – it was partly motivated by people in the early 2000s assuming that when a computer runs code to make music, it is being creative rather than the programmer. It might not be oppositional to other wholesome ways of making music, but it is political, and is the opposite of vibe coding.
From one perspective it’s nice that software engineering is being automated, so that we can focus on more fully human use of it.
Looking forward [from June 2017], I see great possibilities. All the young people now learning how to write code for industry may find that the industry has disappeared by the time they graduate, and that their programming skills give no insight into the workings of Deep Learning networks. So, it seems that the scene is set for programming to be untethered from necessity. The activity of programming, free from a military-industrial imperative, may become dedicated almost entirely to cultural activities such as music-making and sculpture, augmenting human abilities to bring understanding to our own data, breathing computational pattern into our lives. Programming languages could slowly become closer to natural languages, simply by developing through use while embedded in culture. Perhaps the growing practice of Live Coding, where software artists have been developing computer languages for creative coding, live interaction and music-making over the past two decades, are a precursor to this. My hope is that we will begin to think of code and data in the same way as we do of knitting patterns and weaving block designs, because from my perspective, they are one and the same, all formal languages, with their structures intricately and literally woven into our everyday lives.
Ha ha ha, yes, “I’m sorry I can’t because I’m part of the f off AI music movement” (though unfortunately my department fears irrelevance, and sees AI engagement as the way forward – on the plus side, we find that the students get frustrated pretty quickly with the lack of control over the results that prompting affords you).
Sorry to have dropped the thread. Things were particularly busy at that time, and summer holiday turned into “more holiday, less research” than I should have done.
BTW while back in the States, I did a live coding lecture-demo at my parents’ retirement community. The response was better than I expected. I don’t think anyone in the audience is going to seek out this kind of music, but they were genuinely curious about how it’s being done. So part of the answer in this thread may be not to worry about it too much: it’s something different, and there will always be people who are curious about things that are different.
What I meant by “never intentionally… oppositional” is that live coding never sought to supplant other modes of programming, such as traditional app development (where LLM generation of code explicitly seeks to supersede all other methods – and the youtube-o-sphere has picked up on the fact that you can attract viewers by declaring that X, Y, or Z tool “is dead,” framing the whole thing in a quite damaging way… you notice how everything “is dead” now? Why is everything “dead”? Who benefits? We know who benefits… Dario and Sam).
NGL I did just have a good experience vibe coding an online exhibit of field recordings made by first year students in my department (no link yet though). It would have taken me at least a week to get up to speed enough in JavaScript, and even then, I might not have bothered with some features. To me, that was fine. It was going to be tedious and time-consuming, but I was able to finish it off in, like, not even half a day. (This is also a case where code quality didn’t matter.)
Anyway… There’s a paper topic kicking around in my brain, So, I wondered if I could solicit this forum for comments or any sort of loose musings about what live coding might look like in the future:
- how to be oppositional without remaining stuck in UI paradigms that may be soon to disappear (although even that assessment gets complicated by the fact that LLM working methods are kind of a throwback to mainframe workflows)
- how to apply machine learning to code that one would display to an audience (I have some reasons for thinking this might just not work, though, as the goals of live coding and LLM coding are in some ways diametrically opposed)
- how to make live coding dialects more communicative for humans without sacrificing brevity (
s("- ho").fast(4) is pretty good; my way \fork(" \ins("-", 4, 1)|||") is not exactly inviting for the viewer; “put an open hi-hat on every 8th-note offbeat” communicates well, but conflicts with rapid typing)
TIA,
hjh
