This week, Carly Schnitzler (@cschnitz) and I got together for a chat around the week's topic, New Work and New Directions.

Join us with your thoughts and reactions!

References and Links

• Alan Blackwell, Moral Codes
• “The ‘dead internet theory’ makes eerie claims about an AI-run web. The truth is more sinister”
• Google trends show when social media tanked zine interest and when the Dead Internet brought it back
• Ursula Franklin, The Real World of Technology
• Preserving AI Voices
• kathy wu, “Into Uncertain Weathers”
• Ensemble Park (eds. Kyle Booten and Katy Ilonka Gero)
• Anxiety of Conception by Katy Ilonka Gero
• Friedrich Kittler, The Truth of the Technological World
• Jessica Pressman, Bookishness

EDIT: I had not added a transcript, which is now here! It is still very rough, but I tried to do the fastest of cleanups.

The agenda of the book, as I occasionally observe to colleagues in computer science, is to argue that the world probably needs less AI, and better programming languages. I wrote the book to try and persuade a wider audience (including policy makers) of this, observing that many of the most intractable problems of AI - explainability, alignment, controllability - are precisely the established priorities of programming language designers.

I draw on my own long experience of designing end-user programming languages, especially those that extend the spreadsheet paradigm or support creative imporovisation. These are often diagrammatic, or data-centric, or use direct manipulation, meaning that the “code” they allow is not the kind that easily invites close reading. Which is not to say that close reading would be pointless - I suspect many spreadsheets are crying out for it!

A deeper, but probably subtler, theme of the book reflects on the attention economy of AI, of social media, surveillance capitalism, enshittification and all that. I argue that the investment of attention is the fundamental unit of human consciousness, and that the drive to make machines conscious reflects a systematic devaluing of our own consciousness, as a consequence of the technofeudal attention economy (similar to Pasquinelli’s labour theory of AI). From this perspective, programming is fundamental to the exertion of individual personhood. As Geoff Cox and Winnie Soon said, “program, or be programmed”.

The last part of the book speculates on where vibe coding may take us, through an explanation of basic craft principles in software engineering. But the book was originally written before the launch of ChatGPT, and published before Karpathy invented “vibe”, so those chapters are quite a hostage to fortune. There is an extended historical centre, in which I discuss the evolution of the GUI out of programming innovations of Alan Kay, Ivan Sutherland, and others who all saw their work as a kind of programming. For me, critical attention to all of these technologies benefits from the ability to view them as notational systems, each having their own kinds of code-like properties.

So overall, I would not advocate Moral Codes as a text in critical code studies, because it is not really doing the same thing as CCS. Nevertheless, the arguments are likely to be familiar to students of CCS, and I hope offer some value to the field, by reminding us the ways in which code may continue to be important, even if we become obliged to access it at second-hand via a chat dialog.

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)?

Software/Hardware Requirements

Markdown is a plain text formatting syntax and a text-to-HTML conversion tool. The original implementation was a Perl script (Markdown.pl) that processed .md or .markdown files into HTML. Unlike Scribe, which required a PDP-10 and BLISS compiler, Markdown runs anywhere Perl runs, which by 2004 meant essentially any Unix-like system, including Mac OS X and Linux. The format itself requires no special software to write, only a text editor, and remains human-readable without processing.

Context

This code critique accompanies the Scribe code critique in Week 2. Where Scribe (1980) represents the emergence of structured document markup in academic computing, Markdown (2004) represents something like a return of the repressed, a deliberate simplification that prioritises human readability over formal rigour. Together, they bookend the "word processing parenthesis," the period of WYSIWYG dominance – and Markdown might be a signal that it is closing.

Markdown matters for three reasons. (1) Its syntax decisions have become infrastructural, shaping how millions of people write documentation, notes, and web content – it is also the (current) format crucial for powering the AI moment we are having in 2026. (2) Its licensing (or lack thereof) contrasts sharply with Scribe's commercialisation, representing a different political economy of software. (3) Its subsequent fragmentation into competing dialects (CommonMark, GitHub-Flavored Markdown, MultiMarkdown) raises questions about standardisation, power, and whose conventions become normalised.

Code

The Markdown Syntax

Markdown uses ASCII punctuation characters to indicate structure. Unlike Scribe's @ commands or HTML's angle brackets, Markdown syntax was designed to be "publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions" (Gruber 2004).

Headers use hash marks:

# Heading 1
## Heading 2
### Heading 3

Emphasis uses asterisks or underscores:

*italic* or _italic_
**bold** or __bold__

Lists use dashes, asterisks, or numbers:

- Unordered item
- Another item

1. Ordered item
2. Another item

Links and images use brackets and parentheses:

[Link text](https://example.com)
![Alt text](image.png)

Block quotations use the email convention of angle brackets:

> This is a quotation
> spanning multiple lines

Code is indicated by backticks (inline) or indentation (blocks):

Inline `code` here

    Four-space indented code block

Design Philosophy

Gruber's specification emphasises readability over "parseability":

The overriding design goal for Markdown's formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it's been marked up with tags or formatting instructions.

This inverts the usual priority in markup language design. SGML, XML, and even Scribe prioritised unambiguous machine parsing. Markdown prioritises the human reader of the source file, accepting some parsing ambiguity as the cost.

The Perl Implementation

The original Markdown.pl is approximately 1,400 lines of Perl. It processes text through a series of regular expression substitutions, transforming Markdown syntax into HTML. The code is procedural rather than structured around a formal grammar, reflecting Markdown's origin as a practical tool rather than a formally specified language.

A representative excerpt shows the pattern:

sub _DoHeaders {
    my $text = shift;

    # Setext-style headers:
    #     Header 1
    #     ========
    #  
    #     Header 2
    #     --------
    #
    $text =~ s{ ^(.+)[ \t]*\n=+[ \t]*\n+ }{
        "<h1>"  .  _RunSpanGamut($1)  .  "</h1>\n\n";
    }egmx;

    $text =~ s{ ^(.+)[ \t]*\n-+[ \t]*\n+ }{
        "<h2>"  .  _RunSpanGamut($1)  .  "</h2>\n\n";
    }egmx;


    # atx-style headers:
    #   # Header 1
    #   ## Header 2
    #   ## Header 2 with closing hashes ##
    #   ...
    #   ###### Header 6
    #
    $text =~ s{
            ^(\#{1,6})  # $1 = string of #'s
            [ \t]*
            (.+?)       # $2 = Header text
            [ \t]*
            \#*         # optional closing #'s (not counted)
            \n+
        }{
            my $h_level = length($1);
            "<h$h_level>"  .  _RunSpanGamut($2)  .  "</h$h_level>\n\n";
        }egmx;

    return $text;
}

This code reveals several things. The use of Perl's extended regular expression syntax (/x modifier) allows readable formatting of complex patterns. The dual support for "Setext-style" (underlined) and "atx-style" (hash-prefixed) headers shows Markdown inheriting conventions from earlier plain text traditions. The regex-based approach, rather than a formal parser, explains both Markdown's flexibility and its parsing edge cases.

Provocations

On the politics of simplicity. Markdown's design prioritises ease of writing over formal specification. This has democratic implications, anyone can write Markdown without learning a complex syntax, but also creates problems. The original specification left many edge cases undefined, leading to the fragmentation problem that CommonMark later attempted to address. Is "simplicity" a neutral design value, or does it encode particular assumptions about users and use cases?

On plain text as ideology. The preference for plain text has deep roots in Unix culture and hacker ethics. But "plain" text is never simply plain. UTF-8 encoding, line ending conventions (LF vs CRLF), and character set assumptions are all contested terrains. The apparent simplicity of .md files conceals layers of standardisation and historical compromise. What would it mean to read plain text ideologically?

On licensing and the gift economy. Gruber released Markdown under a BSD-style license, essentially giving it away. Aaron Swartz, who contributed to the specification as a teenager, later became famous for his information-freedom activism and died in 2013 while facing federal prosecution for downloading academic articles. The contrast with Reid's sale of Scribe and insertion of time bombs could not be sharper. What do these different political economies of software reveal about the conditions under which technical infrastructure emerges?

On fragmentation and standardisation. Markdown's success created its own problems. GitHub-Flavored Markdown added tables, task lists, and syntax highlighting. MultiMarkdown added footnotes, citations, and metadata. CommonMark attempted to create an unambiguous specification. The format that solved HTML's complexity problem has reproduced complexity at another level. Who gets to decide what "Markdown" means?

On LLMs and markup. Large language models are trained on vast quantities of Markdown-formatted text from GitHub, documentation sites, and technical blogs. When we prompt an LLM to write, it typically produces Markdown. Does this training data bias encode particular assumptions about document structure? Whose conventions are being reproduced and naturalised through AI-mediated writing?

Resources

Markdown in the CCS workbench as a sample: https://ccs-wb.vercel.app/

Gruber, J. (2004) "Markdown." Daring Fireball. https://daringfireball.net/projects/markdown/

Gruber, J. (2004) "Markdown: Syntax." https://daringfireball.net/projects/markdown/syntax

Original Perl implementation: https/daringfireball.net/projects/downloads/Markdown_1.0.1.zip

CommonMark specification: https://spec.commonmark.org/

MacFarlane, J. (2017) "Beyond Markdown." https://johnmacfarlane.net/beyond-markdown.html

Dash, A. (2026) "How Markdown took over the world." https://anildash.com/2026/01/09/how-markdown-took-over-the-world/

Wikipedia entry on Markdown: https://en.wikipedia.org/wiki/Markdown

The Source Code

The original Markdown.pl (version 1.0.1, 2004) is available from Daring Fireball:
https://daringfireball.net/projects/downloads/Markdown_1.0.1.zip

Later implementations in other languages are numerous. Notable examples include:

• Python-Markdown: https://github.com/Python-Markdown/markdown
• marked (JavaScript): https://github.com/markedjs/marked
• commonmark.js (JavaScript reference implementation): https://github.com/commonmark/commonmark.js
• Pandoc (Haskell, converts between many formats): https://pandoc.org/

Questions About the Code

1. How does Markdown's syntax encode assumptions about document structure? The format handles paragraphs, headers, lists, links, emphasis, and code, but struggles with tables, footnotes, and metadata. What model of "documents" does this imply? What kinds of writing does Markdown make easy or difficult?

2. The original implementation uses regular expressions rather than a formal grammar. What are the consequences of this design choice? How does it relate to the parsing ambiguities that later motivated CommonMark?

3. Gruber explicitly borrowed conventions from email (blockquotes with >), Usenet (emphasis with *), and earlier plain text formats (Setext headers). What does this genealogy reveal about the communities whose practices became infrastructural?

4. Markdown was designed for web writers producing HTML. But it has spread far beyond that context, into note-taking, documentation, academic writing, and AI training data and AI output format. How do tools and formats exceed their original design intentions? What happens when a format becomes infrastructural?

5. The contrast between Markdown (given away, BSD license) and Scribe (sold, time-bombed) represents different political economies of software. What conditions enabled Gruber to give Markdown away? What does the gift economy of open source depend on that we might not see?

Take a look in the CCS workbench now

Title: Yandex Maps
Author/s: Yandex Corporation
Language/s: JavaScript
Year/s of development: 2021
Software/hardware requirements (if applicable): Web

Code

/**
 * Возвращает куку, отвечающую за статус Крыма.
 *
 * @see https://st.yandex-team.ru/MAPSUI-720
 */
function getCrimeaStatusCookie(cookies: Record<string, string>): string | undefined {
    if (!cookies.yp) {
        return;
    }
    const values = yandexYCookie.parseYpCookie(cookies.yp);
    return values.cr && values.cr.value;
}

Context

In 2023, the source code of Yandex, the equivalent of Google in the Russophone internet, was leaked. Given the ties of the Yandex engineers with their western counterparts, and the ties of the Yandex management with the government of the Russian Federation, this is quite a unique corpus, as it inscribes both corporate and governmental power. It is also an incredible challenge to make sense of it.

I attempted to do that in a paper that was recently published createPoliticsResponse: the political computation of state borders in Yandex maps (edited by @orladelaney9 and @davidmberry). Most of the article is focused on tracing how Yandex Maps decides which borders to show, to whom, and under which conditions. In this sense, it is a material testimony of what is already asssumed, but hard to prove at the interface level, and in thus case it really shows the specific contribution of CCS to platform studies.

One code snippet that I looked at in the paper was the function above, from the frontend part of Yandex.Maps, which seems to extract a value about Crimea's status from a client cookie. So on one side, it is quite obvious that a Kremlin-linked Yandex wants to treat one of the most contested geopolical areas of Europe as an edge case. But on the other side I have found it particularly hard to show how exactly this is treated, and as which kind of edge case. This is a big limitation of the critically studying this function: it only allows us to study the reading of a value, and not its writing, hence telling only half of the story.

One reason for this is that the size of the Yandex codebase is orders of magnitude more vast than the usual snippets that constitute most of the corpus of CCS: the whole leaked codebase clocks in at upwards of 44Gb, and the maps module at more than 4Gb; both are mostly composed of plaintext files (see the resources section for a repo containing the maps section of Yandex's source code). This shift in quantity seems to me to be a shift in quality, and asks new questions for methods of CCS, some of which I've sketched out below.

Questions

• Quite an uncritical start, but where is the value of the crimeaStatus cookie field set? How do we handle variable names changing as they get passed as arguments/references/assignments?

• How does one go about reading 44Gb of code? The default means of search in textual software (matching patterns of characters) is heavily biased towards a syntactic approach, rather than a semantic approach. Could tools that focus on the structure of code (e.g. class relationships, function definitions and references, data structuring, argument passing) rather than on the surface of the code? If we do CCS on large corpora with only tools that enable such lexical analysis, rather than tools that do static structural analysis, what are we missing?

• Is it enough to focus on the name of a function (e.g. getCrimeaStatusCookie) as an argument to critique the relationship between a private corporation and the (imperial) policy of a nation-state, without knowing exactly what the function does? In other words, what is the relationship between lexical choices and semantic choices as epistemic building blocks in a critical code study? Is there a critique of the data structuring that is independent of how data structures are called?

• Thinking of structure, how much can/shold CCS draw on existing CS entities and denominations? I'm thinking here of design patterns, best practices, testing strategies, application architectures or language features? Specifically here, what kind of parts a CCS grammar could something like middlewares or localizations be (getCrimeaStatusCookie being both of these)?

• The nature of leaked code seems to always imply a lack. In this case, there is missing documentation, specification, as well as all the ML components of Yandex. So how does one investigate incomplete code? How does one account for the part that is lacking, and how can one make extrapolations about it? What kind of forensic is this?

Resources

• Maps module of the Yandex leaks, with the code snippet being in localization-middleware.ts:153
• GICAT and ICE, tools developed at the Computational Social Science research lab at RWTH, enabling code study of software used in social science research.
• zoekt, the main lexical analysis and parser tool used for exploring source code

In the examples below you can see I have compared Llama 3.2 and Gemini 2.5 Pro, but you could also compare two models from the same family (e.g. Pro vs Flash or even the same LLM Pro vs Pro). See below.

Source code (fully open source, and built on open source software) is available here: https://github.com/dmberry/LLMbench

It's still in early development so I don't have a deployment to share, but you can install it yourself by following the instructions here.

UPDATE: It is now deployed and can be used from this address (currently only working with non-local LLM models): https://llm-bench-mu.vercel.app/

To connect up a free API model

Go to https://openrouter.ai and sign up for an account

Click Get an API key

Write this API key down somewhere as you are going to need this later.

Then Explore Models

I use the model: "google/gemma-3n-e2b-it:free" (which is free) but there are many others to choose from.

In the LLMbench app

Now paste this information into the LLMbench settings window (click top right gear):

Provider: Open-AI-Compatible API (or choose the one you have if you pay for it)
Model: Custom Model
Custom Model ID: google/gemma-3n-e2b-it:free
API Key: your API key from above
Base URL: https://openrouter.ai/api/v1

Do this for both panels - as a test you can send to the same model. Later you can choose another free model from OpenRouter such as:

• nvidia/nemotron-nano-9b-v2:free
• openai/gpt-oss-20b:free
• google/gemma-3n-e2b-it:free
• deepseek/deepseek-r1-0528:free
• meta-llama/llama-3.3-70b-instruct:free (supports multilingual dialogue)

Then click X to close and it should work...

This is what it currently looks like (it already has a dark mode!).

And here it is with annotation added:

Here are some examples of the same Gemini model family. In the first (Pro vs Pro) you can see the effects of the probabilistic generation in the slightly different outputs from the same prompt given to two instantiations of the model simultaneously.

The one above is Gemini Flash vs Pro.

UPDATE: It is now deployed and can be used from this address (currently only working with non-local LLM models): https://llm-bench-mu.vercel.app/

I try to justify the privilege of academic sabbatical leave by undertaking research investigations that would not be supported by conventional public or private funding, applying radically new methods to longstanding problems. As an engineer / critic, I take Agre’s critical technical practice to mandate not only properly informed theoretical perspectives on technology, but also subjecting any speculative concepts to Pickering's mangle of practice, learning what I don’t know by making different things in different contexts.

Next year will be the last time in my career that I’m entitled to take a year of research leave. I’ve done it twice before. In my first sabbatical, I spent 7 months living in a New Zealand forest, creating the purely visual art programming language Palimpsest, through a daily process of creative exploration that avoided specification or explicit functional goals (perhaps “vibe coding,” but working directly in Java). My second sabbatical asked what AI would look like if it were invented in Africa instead of the USA, a question that I explored ethnographically, working with computer scientists and local communities in Ethiopia and Namibia.

The massive surge of interest in AI since then has inspired many to reconsider the foundations of computing, and the longstanding tension between AI and programming as explored in my book Moral Codes. For this last sabbatical, I plan to undertake a practical investigation of alternative foundations. Informed by critical histories such as Wendy Hui Kyong Chun’s “Programmed Visions”, and Matteo Pasquinelli’s "Eye of the Master,” I bring together my ethnographic investigations of AI alternatives with some decades of personal experience inventing domain-specific and end-user programming languages. I am making plans to work directly with creative and scholarly communities in two countries - in Lagos, Nigeria inspired both by Helen Verran’s “Science and an African Logic” and by Fela Kuti’s Afrobeat, and in my home country of Aotearoa New Zealand, where mātauranga Māori does not separate people and their environment in the same way as colonial metaphysics.

In 2018, when starting my investigation of AI in Africa, computer science colleagues asked how the fundamental principles would be any different, simply by working in a different place. Yet observing the work of my graduating students as they join DeepMind, Facebook AI, Spotify and other corporations, I wondered how AI on another continent could possibly be the same. Those tensions seem even greater, in turning my attention to programming languages. Aren't the basic principles of computation mathematical laws, within which today’s programming languages represent a natural compromise of engineering practice and architectural principles? Yet Chun, Pasquinelli and others attest to the contingency of so many supposedly fundamental principles. I really don’t know what, or whether, new things might be discovered by this somewhat Quixotic project. But I hope that a spirit of playful humility and moral engagement may uncover some alternative paths into the forest.