Left: cover of the _Intellivision (2024) book. Right: black and white photo of the Intellivision videogame system._

From the MIT Press:

The engaging story of Intellivision, an overlooked videogame system from the late 1970s and early 1980s whose fate was shaped by Mattel, Atari, and countless others who invented the gaming industry. Astrosmash, Snafu, Star Strike, Utopia—do these names sound familiar to you? No? Maybe? They were all videogames created for the Intellivision videogame system, sold by Mattel Electronics between 1979 and 1984. This system was Atari's main rival during a key period when videogames were moving from the arcades into the home. In Intellivision, Tom Boellstorff and Braxton Soderman tell the fascinating inside story of this overlooked gaming system. Along the way, they also analyze Intellivision's chips and code, games, marketing and business strategies, organizational and social history, and the cultural and economic context of the early US games industry from the mid-1970s to the great videogame industry crash of 1983. While many remember Atari, Intellivision has largely been forgotten. As such, Intellivision fills a crucial gap in videogame scholarship, telling the story of a console that sold millions and competed aggressively against Atari. Drawing on a wealth of data from both institutional and personal archives and over 150 interviews with programmers, engineers, executives, marketers, and designers, Boellstorff and Soderman examine the relationship between videogames and toys—an under-analyzed aspect of videogame history—and discuss the impact of home computing on the rise of videogames, the gendered implications of play and videogame design at Mattel, and the blurring of work and play in the early games industry.

Intellivision is a part of the Platform Studies series at the MIT Press edited by Nick Montfort and Ian Bogost, who write in their series forward that "there is also much to be learned from the sustained, intensive, humanistic study of digital media. We believe it is time for humanists to seriously consider the lowest level of computing systems and their relationship to culture and creativity." They describe books of the series as sharing:

• a focus on a single platform or a closely related family of platforms
• technical rigor and in-depth investigation of how computing technologies work
• an awareness of and a discussion of how computing platforms exist in a context of culture and society, being developed on the basis of cultural concepts and then contributing to culture in a variety of ways— for instance, by affecting how people perceive computing.

For our book discussion of Intellivision in this Critical Code Studies Working Group, we will focus on engagement with code and code work. In the book these passages are situated within a broad study of the Intellivision platform and its many historical and cultural contexts. In the opening passages of their introduction ("Introduction: Intelligent Visions": "Blue Skies") the authors frame this situated approach:

We dig into the dirt, so to speak, revealing multifaceted technical and social practices that shaped the platform. We investigate Intellivision’s origins, computational properties, and videogames. We examine its design, advertising, and marketing. We introduce the companies who collaborated to produce it and the people who worked to develop it. We also look outward, reflecting on what Intellivision teaches us about videogames, platform studies, and the social history of technology.

Intellivision’s fascinating story is about a major toy company enter- ing the nascent videogame industry and the wider market for consumer electronics and home computing. It is a story about competing visions for the future of videogames, about the exhilarating and risky experience of exploring uncharted markets, about the intoxicating boom of success and agonizing plummet of failure. It is a story about a videogame system that battled Atari and almost bankrupted Barbie—and along the way, it changed the history of videogames.

Our starting focus for discussion is drawn from Chapters 4-6, and in particular Chapter 5.

• 4 Mattel’s Marketing Magic 107
  PART II: Practices
• 5 Ladders of Game Production 145
• 6 Becoming a Videogame Programmer at Mattel 167

Linked open access Chapters 4-6, from the Table of Contents.

In this key passage from Chapter 5 (pp150-151), the authors quote APh programmer David Rolfe on the cartridge and EXEC operating system before working through a short code routine from the Intellivision game Major League Baseball written in CP1610 assembly code. The quote and their worked examples explores the relationship between platform-os and software as a relationship between 'body' and 'soul', in a metaphor reminiscent of Cartesian mind-body dualism: "entwined," and yet also "throwing control back and forth":

The EXEC evolved into more than a space-saving device, and game programs on cartridges became deeply entwined with it. “Strictly speaking, the EXEC is like a body without a soul,” Rolfe said. In this metaphor, the cartridge is the soul bringing the EXEC to life, while the EXEC is the body of processes that carry out the soul’s desires. This dance between the EXEC and cartridge code is clear when swinging one’s bat in Major League Baseball. The EXEC handles much of the work, first by calling the BATSWING routine contained on the cartridge ROM:

CMP     .UP,R1          ;IS THIS COMMAND FROM UP PLAYER?
BNZ     RETINS          ;IGNORE IT IF NOT
MOV     #NOKEYDSP,R0    ;PREVENT FURTHER SWINGING
MOV     R0,.KEYDSP      ;BY NOT LISTENING TO KEYPAD ANYMORE
CALL    S.SWING         ;BAT SWING SOUND
MOV     .BATRUP,R0      ;GET OBJECT NUMBER OF BATTER
CALL    TOOBJ           ;GET DATA BASE
ADD     #.OBJSEQ,R1     ;WANT TO START SEQUENCING

This is assembly language code from the Major League Baseball cartridge, with CPU instructions on the left. The text after the semicolons are non-executable comments left by Rolfe to describe what the code is doing. Since this is a two-player game, the BATSWING routine checks to see if the button press came from the player at bat, branching away from the routine if not (BNZ means “branch away if the result of the compare, CMP, is not zero”). The code changes the EXEC’s .KEYDSP variable (the key dispatch) to switch off the keypress interaction on the hand controllers. This prevents you from swinging twice. Then the code triggers the bat swing sound, a process that also uses the EXEC. BATSWING uses another EXEC routine called TOOBJ to retrieve the moving object of the batter and manipulate its animation sequence (using .OBJSEQ, another variable used by the EXEC). This starts the batter’s swinging animation, which is also handled by the EXEC. Then, if the videogame code on the cartridge determines that you hit the ball, the EXEC handles its movement. The EXEC code and the videogame cartridge code are thus constantly throwing control back and forth, like two kids playing catch

Notice that the play logic of the prototypical 20th-century American sport of baseball here is aligned with the logic of the Major League Baseball cartridge for Intellivision, That logic is constituted by e.g. the BATSWING routine and its code snippet, and that the 'soul' of the Baseball player's desire (to swing the bat) is embodied by the Intellivision's EXEC operating system, with Baseball a kind of ur-program or prototypical program against which the constituting logic EXEC against. For the authors co-constitution is actualized during code execution in a way that aligns, once again, with part of the cultural logic of a baseball: "throwing control back and forth, like two kids playing catch."

This suggests many potential entry points into the intellivision and its cartridge, OS, and development code, whether from broad contexts such as business culture or the history and philosophy of sport (and foundations of game studies) or from a single line of CP1610 assembly.

-- Jeremy Douglass, CCSWG 2026

For Discussion:

• What is the relationship of Intellivision code to the role of code in culture?
• How do the EXEC OS and Baseball cartridge and relate to the body/soul concept?
• What is interesting about these code examples and their platform today through the lens of software engineering and computer science, the history of computation, or cultural studies?
• How do the interrelationships of code work across various levels of abstraction (routine, library, operating system, CPU instruction set, hardware...)?
• What are the methodological interrelationships of "platform studies" to "code studies" in these examples?

Vibed using Veo 3

"I'm ready to help you plan, study, bring ideas to life and more..." (Gemini 2026)

"Vibe coding" emerged in early 2025 as Andrej Karpathy's term for a new mode of software development. He wrote about fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists. The phrase captures something novel about writing software through conversation with large language models (LLMs) as a practice where natural language prompts replace direct code authorship, and where working programs emerge through iterative dialogue rather than deliberate deterministic construction. For me, vibe coding lies somewhere between augmentation and automation of software writing, but I think it also raises new questions for Critical Code Studies (CCS).

For CCS, vibe coding poses real opportunities for innovation and creativity in new methods for code reading and writing. Over the past year, experimenting with vibe coding, such as building tools and experimenting with failures, has convinced me that in terms of how we might undertake sophisticated code readings, vibe research (vibe CCS?) has something interesting to offer us. I have vibe coded a critical code studies workbench that you can download and use to undertake different types (modes) of CCS. Full instructions are here.

This thread draws on on a case study I've already documented, which involved building an Oxford TSA practice application with Google Gemini, and then subsequently attempting to develop an "AI sprint" method that adapts book sprint and data sprint approaches for LLM-augmented research. Rather than approaching LLMs primarily as tools for reading code (i.e. the hermeneutic direction) or generating code (i.e. the software engineering direction), this group's discussion will aim to focus on what happens in the space between, that is, where prompts become interpretive acts, where code becomes a mirror reflecting gaps in our own thinking, and where the boundaries between human and machine contribution become productively blurred.

Theorising Working With AI's

Working through extended vibe coding sessions, I've found it useful to distinguish three different ways of engaging with AIs.

Cognitive delegation occurs when we uncritically offload the work to systems that lack understanding. In my TSA project, I spent considerable time pursuing PDF text extraction approaches that looked plausible but were unworkable. The LLM generated increasingly sophisticated regular expressions, each appearing to address the previous failure, while the core problem, that semi-structured documents resist automated parsing, was ignored. The system's willingness to produce solutions obscured that the solutions the LLM offered were broken, failed or misunderstood the problems.

Productive augmentation describes the sweet spot in working with an LLM. This is human curation of the LLM combined with the LLMs speed and efficiency to create code. Once I abandoned text extraction and instead remediated the PDF within an interactive interface, progress on my project accelerated dramatically – in other words, it was up to me to rearticulate the project and realise where I was going wrong. In contrast, previously the LLM would cheerfully tell me that my approach was correct and that we could fix it in just a few more prompts. By actively taking over the coordination and curating the design and structure of the research questions and design decisions the LLM handled coding I would have struggled to produce myself (and certainly at the speed an AI could do it!).

Cognitive overhead is what I call the "scaling limits" of vibe coding. Managing LLM context, preventing feature regressions (a common problem), and maintaining version control are irritating for the human to have to manage as it seems like that should be the job of the computer. However, due to a range of reasons (e.g. misspecified or mistaken design, context window size, context collapse, bad prompting) a project soon reaches a complexity threshold where the mental labour of scope management became impossible of the LLM to handle and exhausting for the user. I think this means that perhaps vibe coding works best for bounded tasks rather than extended development (or at least present generations of LLM do, as this is clearly a growing problem in deployment of these systems).

Vibed using Nano Banana Pro

Day 1: Question for discussion

• When you try vibe coding (and you should!), do you recognise which mode you occupy?

• What signals the transition from productive augmentation to cognitive delegation? Is it an affective change or a cognitive one?

Vibed using Nano Banana Pro

The Competence Effect

The 2024 AI and CCS discussion returned repeatedly to Weizenbaum's ELIZA effect, which is the tendency to attribute understanding to pattern-matching systems. I want to suggest that vibe coding produces something qualitatively different, which I'm calling the competence effect.

Where ELIZA users had to actively ignore (bracket out?) the system's obvious repetitiveness, vibe coders receive constant reinforcement that the LLM "gets it". The AI always tries to be positive and action your suggestions and prompts. Bugs seem to get fixed through iterative prompting, and the system appears to learn from corrections. Quasi-functioning code provides evidence that seems to support that the LLM is helping you, even as it has no real understanding of your intentions.

The danger lies in a subtle mistake. A projection of competence and positivity from the LLM actually obscures the distinction between pattern-matching and comprehension. The LLM's apparent responsiveness creates a false confidence in its flawed approaches. We persist with unworkable strategies because the system generates plausible-looking code without signaling architectural problems (or perhaps even being able to do so). It tells us our idea is great, and that it can build the code – and if we don't keep a critical eye on the development, we may waste hours and days on an unworkable solution.

Day 2: Question for discussion

• Can we develop critical literacy for recognising the competence effect?

• What textual or structural markers distinguish real LLM capability from a surface plausibility?

Intermediate Objects as Hermeneutic Sites

A key principle that emerged from my AI sprint method was that "intermediate objects" were hugely helpful in keeping track of how successful the approach was. These include tables, summary texts, JSON files, and extracted datasets. These make algorithmic processing visible, and contestable, at steps along the way whilst vibe coding. These "materialised abstractions" serve as checkpoints where you can verify that computational operations align with your interpretive intentions.

CCS tends to examine code as a singular cultural object. But interestingly vibe coding produces chains of intermediate objects that themselves potentially become sites for critical reading. For example, the prompt history reveals the distribution of agency and versioned code (you must tell it to use versions!) shows where architectural decision points where made at different moments. Indeed, even the debugging conversations can help examine assumptions about what the system can and cannot do.

Day 3: Question for discussion:

• Can we perform CCS on code that exists in a kind of "perpetual draft form", continually revised through human-LLM dialogue?

• Should we be reading the code, the prompts, or the entire conversation as the primary text? What is the research object?

Vibed using Nano Banana Pro

The Hermeneutic-Computational Loop

Hermeneutics can be said to involve dialogue between interpreter and text. In contrast, vibe coding creates a three-way exchange between (1) human intention expressed through natural language prompts, (2) machine interpretation and code generation based on statistical patterns, and (3) executable code requiring further interpretation and testing.

This triadic structure challenges Gadamer's dyadic model of hermeneutics. Instead, understanding emerges through iterative cycles (i.e. loops) where each prompt is an interpretive act and a request for computational response. Code becomes a kind of mirror, reflecting intentions back while revealing gaps in your initial thinking. The 2024 discussion, AI and Critical Code Studies, touched on this noting how "the AI prompt becomes part of the chain of meaning of code".

Day 4: Question for discussion:

• Does vibe coding represent a new hermeneutic approach for CCS? Or a supplement to it?

• Is there a difference between collaborative coding with an LLM as against collaborative coding with a human partner, or, indeed, from working in sophisticated Integrated development environments (IDEs) with autocomplete?

Provocations

• A team of us has been working on ELIZA for several years now, and the comparison with contemporary LLMs keeps returning. But I think the competence effect marks a qualitative break. ELIZA was obviously limited and its power lay in users' willingness to project meaning onto its mechanical responses. In contrast, LLMs produce outputs that pass functional tests, as code that runs, prose that (sometimes) persuades, analysis that (might) appear sound. I think the critical question shifts from "why do we anthropomorphise simple systems?" to "how do we maintain critical distance from systems that perform competence so convincingly?"

• If an LLM can generate bespoke analytical tools from natural language prompts (and it clearly can), what becomes of the methodological commons that has been used to justify digital humanities or digital methods as fields? My AI sprint method attempts one response by integrating LLM capabilities within traditions that emphasise interpretation, critique, and reflexivity rather than abandoning methods completely. But I'm uncertain whether this represents a sustainable position or a rearguard action (it is also often feels somewhat asocial?).

My TSA project involved approximately 4 hours of vibe coding, apparently (according to the LLM) consuming 0.047 GPU hours at a cost of roughly $0.20 (!). This apparent frictionlessness conceals questions that CCS is well-positioned to raise, such as whose labour did the model appropriate in training? Under what conditions was that knowledge produced? What material resources make such co-creation materially possible? The collaborative interface "naturalises" what should surely remain contested.

Vibed using Nano Banana Pro

The Discussion

Some questions to consider:

1. Have you tried vibe coding? What modes of cognitive augmentation did you encounter? Where did delegation shade into "productive collaboration" or "cognitive overhead"?

2. Are these three modes I've identified similar to your experience, or do they need refinement? Are there other modes I'm missing?

3. Can you share examples of your LLM-generated code that appeared ok but failed? What made the failure difficult to recognise?

4. Is vibe coding a good method, or object, for CCS? What would CCS methodology look like if its primary objects were vibe coding sessions rather than code artefacts? What would we read, and how?

5. Can we vibe code tools and methods for analysing code? Or to what extent can LLMs help us analyse vibe coded projects?

6. Is this the death of the author (redux)?

I'll be posting some code critique threads with specific examples from my projects, and proposing a mini AI sprint exercise for those who want to try vibe coding during the week and reflect on the experience together.

Resources

Vibed using Nano Banana Pro

For those new to vibe coding

Karpathy's "Software Is Changing (Again)" talk: https://www.youtube.com/watch?v=LCEmiRjPEtQ

My "Co-Writing with an LLM" case study: https://stunlaw.blogspot.com/2025/10/co-writing-with-llm-critical-code.html

My "AI Sprints" methodology post: https://stunlaw.blogspot.com/2025/11/ai-sprints.html

The Oxford TSA Questionmaster code: https://github.com/dmberry/Oxford_TSA_Question_Master

Berry and Marino (2024) "Reading ELIZA": https://electronicbookreview.com/essay/reading-eliza-critical-code-studies-in-action/

For the previous CCSWG2024 AI and CCS discussions

AI and Critical Code Studies: https://wg.criticalcodestudies.com/index.php?p=/discussion/157/ai-and-critical-code-studies-main-thread

ELIZA code critique: https://wg.criticalcodestudies.com/index.php?p=/discussion/161/code-critique-what-does-the-original-eliza-code-offer-us

LLM reads DOCTOR script: https://wg.criticalcodestudies.com/index.php?p=/discussion/164/code-critique-llm-reads-joseph-weizenbaums-doctor-script

It uses a local LLM, Ollama, which you will need to download and install, but thats pretty easy (but should (!) be able to use an API key to talk to a more powerful LLM, if you want)

UPDATE: WEB VERSION NOW AVAILABLE TO TRY OUT

This is how the main page looks:

The Critical Code Studies Workbench facilitates rigorous interpretation of code through the lens of critical code studies methodology. It supports:

• Code critique - Close reading, annotation, and interpretation in the Marino tradition
• Hermeneutic analysis - Navigating the triadic structure of human intention, computational generation, and executable code
• Code archaeology - Analysing historical software in its original context
• Vibe coding - Creating code to understand algorithms through building

Software deserves close reading here is a tool to help us. The Workbench helps scholars engage with code as meaningful text.

Note that the CCS Workbench has a built in LLM facility. This means that you can chat to the LLM whilst code annotating, ask it to help with suggestions, give interpretations of the code, etc. whilst you are working. The other modes are more conversational (archaeology/interpretation/create) and allow a more fluid way of working with code and ideas. There is a quite sophisticated search for references whilst you are chatting in the latter three modes so you can connect to CCS literature (and wider) from within the tool.

The Workbench saves project files based on the mode you are in and you can open them from the main page and then it will put you back in the session where you left off. You can also export the session in JSON/Text/PDF for writing up in an academic paper, etc.

Features

Entry Modes

• I have code to critique: IDE-style three-panel layout for close reading with inline annotations
• I'm doing code archaeology: Exploring historical software with attention to context
• I want to interpret code: Developing hermeneutic frameworks and approaches
• I want to create code: Explore algorithms by building them (vibe coding)

Experience Levels

The assistant adapts its engagement style based on your experience:

• Learning: Explains CCS concepts, offers scaffolding, suggests readings
• Practitioner: Uses vocabulary freely, focuses on analysis
• Research: Engages as peer, challenges interpretations, technical depth

IDE-Style Critique Layout

The critique mode features a three-panel layout for focused code analysis:

1. Left panel: File tree with colour-coded filenames by type

   • Blue: Code files (Python, JavaScript, etc.)
   • Orange: Web files (HTML, CSS, JSX)
   • Green: Data files (JSON, YAML, XML)
   • Amber: Shell scripts
   • Grey: Text and other files

2. Centre panel: Code editor with line numbers

   • Toggle between Edit and Annotate modes
   • Click any line to add an annotation
   • Six annotation types: Observation, Question, Metaphor, Pattern, Context, Critique
   • Annotations display inline as // An:Type: content
   • Download annotated code with annotations preserved
   • Customisable font size and display settings

3. Right panel: Chat interface with guided prompts

   • Context preview shows what the LLM sees
   • Phase-appropriate questions guide analysis
   • "Help Annotate" asks the LLM to suggest annotations
   • Resizable panel divider (drag to resize)
   • Customisable chat font size

Project Management

• Save/Load projects as .ccs files (JSON internally)
• Load Project button on landing page auto-detects mode
• Export session logs in JSON, Text, or PDF format for research documentation
• Session logs include metadata, annotated code, full conversation, and statistics
• Click filename in header to rename project

Download the software from https://github.com/dmberry/CCS-WB/blob/main/README.md

Here are some screenshots:

CCS Archeology Mode

CCS Interpretation Mode (i.e. Hermeneutics)

CCS Create Code Mode (Vibe Coding)

See the help icon for more information (or detailed instructions in the project README.md file:

The problem is that, although IPL-V is an incredibly important language, being the language in which Simon and Newell implemented the world's first AIs**, it's also a very difficult language, being essentially the assembly language for a Lisp machine (although Lisp itself wasn't invented until a decade later than the earliest IPL work!) I've made a little video introduction to IPL-V:

If you aren't bored by it, or scared by (or scarred by) all this, let me know, either herebelow, or in DM, and I'll consider making the promised next video introducing LT (The Logic Theory machine, aka. The Logic Theorist) and maybe GPS (The General Problem Solver).

Cheers,
'Jeff

ps. Here's a video that I made about 6 months ago that summarizes my progress at that time on reanimating LT:

Since then my efforts have regressed! :-) Why that has happened is a long, perhaps semi-interesting story.)

(* The fifth IPL is the only one that was fully implemented and commonly available. Most of the previous ones were internal to RAND/CIT. There were plans for an IPL-VI, but it was rolled by Lisp, which implements all the same concepts in a much more elegant language.)

(** What Simon and Newell were working on at RAND in IPL-V wasn't primarily AI, but rather cognitive models; their goal was to build computer programs that thought in the same way that humans thought. To the extent that they succeeded at this, they would have incidentally built an AI by definition, but Simon and Newell preferred terms like "complex information processing" or "cognitive simulation" over "artificial intelligence," which was coined by McCarthy for the 1956 Dartmouth conference. This reflected a genuine philosophical difference: McCarthy pursued intelligence by any effective means, while Simon and Newell insisted their programs should mirror actual human cognitive processes.)