What Can Critical Code Studies Read When Programmers Stop Writing?

Something seems to have happened to the language of programming in the past decade. During the CCSWG 2026 I spent time experimenting with vibe coding, coding in conversation with an LLM rather than writing it directly, and what struck me was not the capacity of these systems but the strange new vocabulary surrounding them. Programmers now wire up hooks, bind components, plug into event streams, subscribe to state changes, mount and unmount lifecycle methods and so on. The everyday language of software development feels to me like it has become the language of plumbing and electrical engineering. It seems to describe connecting pre-existing conduits and wires rather than writing software.

I don't think this is merely jargon though (in Adorno's sense). The older vocabulary of programming, as I am used to it, was mathematical and procedural. Using terms like function, call, return, execute, implement, compile and these words carried within them an image of the programmer as an engineer of software, someone who reasoned through a problem and translated that reasoning into source code to make the machine actualise something. This newer vocabulary of hook, wire, bind, plug in, pipeline, signal, emit, seems to describe a different labour process. It seems to be configuration rather than construction, attachment to infrastructure rather than programming from basic software building blocks.

For CCS, I wonder if this shift poses a new challenge. Critical code studies has generally treated code as a cultural object that can be read, a hermeneutic text connecting it to, for example, ideology, and social context. But the vocabulary change I'm seeing seems to indicate a transformation in what that "text" is. What we might call "framework-era" code is less like a text and more like a wiring diagram. The React hook that seems to be the basic unit of front-end development today does not express thought, instead it declares a connection. It seems to me that when the coder writes useState, useEffect, useCallback, etc. they are not reasoning, they are attaching themselves to flows of "re-rendering" and "state propagation" that the framework manages itself. These hooks (the word itself is so suggestive!) even seem to come with disciplinary imperatives, for example they must be called at the top level, never inside conditionals, because the framework tracks them by "call order". The new infrastructure dictates the discourse but also the coding mental model.

Vibe coding seems to change the paradigm again. The coder is no longer writing functions or wiring hooks. Rather, the user is prompting, guiding, and shepherding. When the LLM produces the code the user can allow or disallow, accept or reject. Does this mean the coder is a manager or does the LLM proletarianise the coder? What does this say about the code that is produced and what happens to CCS and its methods?

So here is my question - if CCS reads code as cultural text, what happens when the text has been progressively emptied of the traces that made it readable? Good old-fashioned programming (GOFP) left traces of individuality and their social context in their code. The new "framework" programming leaves configuration choices and permission traces (allow/accept) but rarely do we see the negative (cancel/reject) as this is seldom written, stored, or documented. The vibe coder leaves only markdown conversations, and the code that results bears little individual trace. Its social context is algorithmically mediated rather than socially situated. Is this vocabulary shift significant for CCS? As it seems to me one could argue the move from mathematical to electrical to conversational, marks a withdrawal of the interpretative from the text.

Does CCS need to follow this withdrawal (follow the actants as it were)? Should we be reading/critiquing prompts, conversations, intermediate objects (as I suggested in this thread) rather than the (generated) code? Or is there something still legible in the statistical patterns of vibe-coded output, something that a close reading of the probabilistic source code might reveal about the collective labour it distills?

Perhaps CCS should be attending to the transitions between human and machine labour, not just the outputs. I think the vocabulary shift here can be read diagnostically. When did programmers actually stop saying "implement" and start saying "wire up," and will they move to saying "vibe up"? Are we following these shifts and paying attention to new directions as the New Work and New Directions discussion asks, or is Critical Code Studies becoming conservative and overly obsessed with good old-fashioned programming (GOFP)?