The first casualties of AI were the coders. Software engineering made for easy benchmarks, since you can always tell whether a program runs or not, and there were untold programs posted to Github, just waiting to be harvested for model training. Entry-level engineers were among the first to be cut, as AI swept through the economy. The Digital Humanities has had a vexed relationship to coding, with the admonition “learn to code” always met by “code needs critique!” The critics rightly recognized that applying digital “tools” might risk displacing higher-order thought about the problems right in front of us. But AI, too, has arrived for the DH coders. Understanding how it will transform the field requires us to see more clearly how critical thinking was always part of code work.

Over the weekend, I subscribed to Claude Code. This is the AI tool that allows Anthropic’s name brand model to write code and run it in its own sandbox, with primary use cases in software development. The models have trained on a staggering amount of human-written code, covering a variety of programming languages and complex applications requiring the coordination of untold numbers of sub-programs running in parallel. Claude Code — and similar products offered by competitors — has been around for about a year, but word on the street is that an update to the underlying AI model (Opus 4.5) last November resulted in an appreciable step up in performance.

To be honest, I have held off from AI-assisted coding up to this point. Call it a distrust of code that I don’t already know how it runs. Over the course of my DH career, I have developed my own “house style,” with programming functions and workflows that are battle tested. I would stand behind them during peer review. But, a couple weeks back, Ryan Cordell shared a series of casual projects on social media for tagging newspaper articles, pulling articles published “on this day in history,” and a letter counter app for setting letterpress type. These are light-weight apps that would be nice to have, with world enough and time, but who ever does? It was Ryan’s note on one project “After < an hour iterating with CC, here’s a barebones version” that got me curious.

In a couple afternoons, I whipped up a pair of apps that implement classic DH tools. The first was a DH Toolkit web app that implements simple mapping, network viz, and topic modeling functions. I chose these three applications, since I devoted a week to each of them in an undergraduate Digital Humanities class I am teaching this semester. Students worked with a few classic applications — Google Maps, Gephi, and Mallet — while we talked about the interpretive problems they are useful to address and some of the gritty problems that come up when using the apps. Having all three applications in one place would certainly streamline the teaching, and I may do just that next semester.

The bonkers thing about the first experience is that I do not know how to code a web app. As of this writing, I do not know the Flask framework. I have only vague notions of how it interfaces between Python code on the backend and an HTML frontend. I can produce clunky 90s-style HTML at best, and I struggle with CSS. In the first iteration of the app, pages were static, but I prompted Claude to rewrite the code to permit interactive elements like zooming on maps and networks, which added Javascript elements as well. I have no background with Javascript at all. Despite all of this, Claude generated the code to my specifications and walked me through the process of installing it to a university server.

The second app turned the clock back on humanities computing. GIS, networks, and topic modeling were essential DH tools circa 2012. But casting an eye on previous decades, it was TEI that set the terms for a great deal of theory and practice. Witness, for example, the vast, painstaking efforts of Early English Books Online to manually key rare books of scholarly value (at least twice apiece, for error detection) and to provide them as structured data. The Text Creation Partnership explains that they were motivated to do so because, at the time, OCR generated such poor results. But the state of the art recently leaped forward with the new generation of vision models. I had to give it a try: “Claude, build me an automated OCR-to-TEI markup pipeline.”

The striking feature of the second app was noticing how much time I spent on the prompts. I’ll reiterate that Claude replied in a few minutes with code that would take me a month to produce on my own. But I easily spent at least 30 minutes at a stretch composing prompts to Claude that ran for several hundred words. It takes a great deal of effort to collect reference documents (like example scans from EEBO paired with their full markup files), to enumerate the many errors that arise during debugging, and to define new features that would make the program more useful. I got like 80% of the way to respectable TEI output from the pipeline before I hit my weekly limit for Claude usage.

For the curious or for those who want to kick the tires, I have posted the source code for the DH Toolkit and TEI Pipeline apps. In addition, I have also posted the transcripts of my conversations with Claude that produced each one (DH Toolkit, TEI Pipeline). I have not spent much time with the code nor the transcripts since generating them, but I am confident that both will reveal strange and embarrassing features. Bugs or Claude-specific artifacts may populate the code. My goals clearly evolve over the course of the conversations. Some of the evolution I can easily report (e.g. who I think each program’s user will be), but I would bet that there are other more subtle changes, as well, as I adapt to Claude’s level of proficiency and tics.

The first punchline here is that the old tools of Digital Humanities are now fully encompassed by AI. At a practical level, any remaining workshops on topic modeling and GIS will need to be rewritten for fundamentally different workflows. We are no longer constrained by the old problem of “other people’s software.” If there is a missing feature or an infelicitous data structure in your field’s popular software package, then simply rewrite it! If there is an onerous reformatting process for your data to play nicely with a program, generate a program that does. A silly amount of my instruction time — not to mention research time — has been devoted to massaging data or program outputs, in order to make them useable in a project. That barrier has fallen away.

At a theoretical level, we need to take a hard look at the differences between our various tools. When we start rewriting our GIS programs at will, what stops us from turning them into network graphs or spatial embeddings? The differences between latitude/longitude, edges between nodes, or vectors through geometric abstractions suddenly seem much smaller when our programs can leap between them seamlessly. The differences among various DH techniques have been flattened, or — better — reconstituted as specific manifestations of the general category of AI. Probably, we will need some media theory to account for the different forms of knowledge that each technique affords any more.

The second punchline is that tools are now telos. In order to develop any particular tool through AI, the process consists of articulating goals. As with other AI models, Claude is both eager to complete the tasks presented to it and extremely literal in its interpretation of the instructions. As a result, I put increasing effort into the specification of each tool’s users, outputs, and ways to interact with the data. But I was not telling Claude how to do go about those things. Instead, I was presenting them as desiderata. I was setting goals for Claude to pursue.

To be clear, program specification has always been an essential aspect of code work. Best practices in software engineering dictate that specification precede any actual code writing, and I expect that any self-respecting Digital Humanist would say the same. Indeed, the DHer would probably point to the galaxy of research questions they hope to address, or to the political interventions they hope to achieve, or to a “cool” interface for representing a dataset. Claude’s goal is simply to generate code, and we set its parameters downstream of our goals for the code.

There is no shortage of goals we can set for Claude Code or similar models. What we need now are criteria to select from them, and that means cultivating something like taste with respect to the goals we set for DH projects. The hardest aspect of a DH workshop or course has never been the code work but developing the participants’ intuition for the kinds of research questions that are amenable to computation. Recognizing the computable in humanistic thought and vice versa is a skill, yes, but it also requires a degree of sensitivity and imagination. With AI models like Claude Code, the bounds on our imagination have grown just a bit wider.