Thunderdome Has Rounded Corners
Digital humanities · 1949 to 2026
The humanist can make the app now
In 2011 a Stanford graduate student told me that collaboration with computer scientists could feel more like colonization. I thought that was true. I was one of the technical people scholars had to ask whether an idea was possible, and my answer was bounded by the software I knew and the code I could write.
That arrangement has changed. A scholar can ask a model to build the database, interface, and chart, then argue with the result until it runs. If the old problem was dependency on toolbuilders, why isn’t the ability to make our own weird code being treated as a real shift in power?
Why this journal
A public record you can argue with
The ability to build and revise an application without waiting for a specialist is a real change. Looking at DHQ’s record helps place that change among the other decisions that shape scholarly work.
Digital Humanities Quarterly is a useful case because I know it as a former editor and author, and because its public record is unusually inspectable. The XML corpus gives us 806 published items through 2025. The repository adds issue structure, taxonomy definitions, community commitments, and an AI policy. DHQ is the case, not a stand-in for the whole field.
The tools came long before this AI wave
Digital humanities did not wait for chatbots to invent mediation. In 1949, Roberto Busa’s Aquinas project already meant IBM, punch cards, operators, and years of checking.DHQ’s reconstructionmakes the human work inside that automation hard to miss. Later, TEI put shared encoding under community rules. The web turned archives into interfaces people could click.
ORBISturned an argument about Roman movement into a network model you could argue with. TheLDA special issuewas my attempt to make the old collaboration problem concrete: put an imported model beside its makers, users, critics, and tools. None of that reduced mediation. It moved the boundary between interpretation and implementation.
AI-assisted coding gives the person asking a research question more control over the software used to explore it. A scholar can try a data transformation, build an interface and revise a chart while the question is still taking shape.
ShowsThirteen documented changes in how ideas become software.Does not showA story of smooth progress, or equal labor in every project.
From punch cards to agents, 1949–2026
Editors group the field before you read it
DHQ reports 710 peer-reviewed articles and case studies through 2025: 386 in the regular stream and 324 in special issues. Those routes have different histories, so they are not simply competing acceptance rates.
In this 806-item public corpus, 353 items sit inside 38 named clusters. A cluster gathers work under a shared question before a reader, or a recommendation system, ever arrives.
A surge in a subject can reflect growing interest among scholars or an editor’s decision to gather work on it. The ability to build software changes neither of those earlier choices about what gets published together.
ShowsWhere published items sit in public named clusters.Does not showWhy a paper was accepted, or comparable acceptance rates by route.
Named public clusters in the 806-item corpus
More names on the byline
The standard AI demo is solitary: one person, one prompt, one finished app. DHQ’s published record was already moving the other way before the present AI wave.
Items with two or more listed authors rise from 32.1% in 2007–11 to 54.7% in 2022–25. Annual rates fluctuate more because the journal published between 6 and 79 items a year; in a small year, a few papers can move the percentage substantially.
A byline is a narrow record. It does not say who wrote code, cleaned data, designed an interface, found funding, or kept a server alive. It only says that named coauthorship became more common.
ShowsHow often published items list one name or several.Does not showWho did what labor, or why teams formed.
One author vs. multi-author published items
What DHQ calls its subjects now
In the current XML, media studies sits on 36.7% of items published in 2007–11 and 3.4% in 2022–25. History rises from 15.6% to 21.2%. Race rises from 0.9% to 14.4%. Project report peaks at 26.7% in 2017–21.
These subject tags come from DHQ’s own vocabulary. An item can carry several tags, so the percentages can add up to more than 100. The category definitions let us check what each bar includes.
One bar is so extreme that it deserves its own question. Media Studies begins as DHQ’s most common controlled category. What does it mean for that category to nearly disappear?
ShowsHow often current controlled tags appear by publication window.Does not showMutually exclusive topics, field-wide prevalence, or labels assigned at publication time.
Change in emphasis over time
DHQ stopped treating the digital as a medium
Media Studies appears on 40 of 109 items from 2007–11 (36.7%), then on just 8 of 236 from 2022–25 (3.4%). A conservative family of narrower media tags briefly absorbs some of the difference, but the whole explicit media ecology still contracts from 45.0% to 13.1%.
The deeper change is what Media Studies no longer connects. Early on, 6 of 14 tools articles and 11 of 27 articles tagged “DH” also carried Media Studies. In the latest window those overlaps are both zero. Its overlap with project reports falls from 6 of 19 to 1 of 40; with cultural criticism, from 7 of 17 to zero of 21.
Early DHQ often grouped interfaces, electronic publishing, collaboration and tools under Media Studies. Later articles more often place that work under methods, projects, disciplines and politics. I read this as a change in emphasis: digital systems increasingly became ways to study a subject, while the systems themselves received less attention under that shared label.
ShowsHow Media Studies retreats overall and from four categories it once connected.Does not showUnlabeled media analysis, full-text topics, or the whole field of digital humanities.
Media Studies appears less often alongside other subjects
The tools tag is not where all the tools are
The explicit tools category does not trace a simple fall. It marks 12.8% of the opening window, rises to 24.0% in 2017–21, and returns to 13.6% in 2022–25. Project reports follow a similar arc. An item carrying either tag accounts for 27.5%, 27.2%, 44.1%, and 26.3% of the four windows.
DHQ’s tools tag covers platforms, workflows, reviews and tool criticism. Many articles use software without being about tools, and project reports overlap with the category. Counting items with either tag gives a broader view of explicitly practical work.
The elision becomes stark in 2024–25. 28 of 91 items carry machine learning, NLP, data analytics, or data visualization; only 1 of those is tagged tools. All 13 recent formal case studies are practical work, and none is tagged tools. Practice became method, case, and situated intervention rather than “here is a tool.”
ShowsHow explicit tool discourse relates to DHQ’s own project-report category.Does not showEvery computational method, software dependency, or kind of practical labor.
Tools, project reports, and either one
A turn toward consequence but not away from making
Compare the opening and latest windows and the largest gains are not a roll call of traditional disciplines. Race rises from 0.9% to 14.4%. Ethics goes from zero to 11.9%. Minimal computing goes from zero to 7.6%. Social justice, global DH, archives, and gender all gain ground; history is the major conventional field among the eight.
Literary Studies falls from 23.9% to 12.3%, alongside tags such as collaboration, infrastructure and publishing. Taken together, these changes suggest growing attention to who digital work serves, where it happens and what it costs. That is a different shift from simply moving toward traditional humanities disciplines.
The journal’s founding question was how to shape digital humanities. Its currentcommunity statementmakes the desired shape explicit: inclusive, global, equitable, accessible, and attentive to the labor that sustains scholarly community. The tools remain. Their obligations moved to the foreground.
ShowsThe eight largest percentage-point gains from the first to latest window.Does not showWhy the changes occurred, editorial causation, or a field-wide topic model.
The topics gaining the most ground
AI fits the methods and collides with the mythology
DHQ already shows us how the present field meets AI. Its2023 volume 17.2includes a named “Code Legibility and Critical AI” section. Across the issue’s 26 items, tools and code studies appear nine times each, cultural criticism four times, machine learning three times, and Media Studies not once. AI is not rejected as computation. It is read as code, method, opacity, bias, gender, and politics.
AI-assisted coding addresses part of the problem I described in 2011: a scholar can try unusual software without first persuading a programmer to build it. But the old problem also involved fitting a rich question into the limits of available tools. A model can reproduce those limits if it keeps proposing the same conventional databases and interfaces.
Current DH adds a harder test. DHQ’sAI policypermits supportive use, but keeps direct agency, disclosure, accuracy, and responsibility with human authors. AI conflicts with today’s DH not because the field stopped computing, but because the product mythology of effortless substitution collides with a field now organized around situated labor and human scholarly relations.
AI gives scholars more control when it lets them change both the software and the terms of using it: access, language, ownership and responsibility for the results.
ShowsHow one issue containing an explicit Critical AI section was tagged.Does not showEach article’s stance, all DHQ writing about AI, or consensus across the field.
How DHQ filed AI and code in volume 17.2
Where that leaves us
More control over code, new dependencies to examine
The record suggests that tools and projects remain important to DHQ. Their combined share is close to where it began. Media Studies has receded as a common way to discuss them, while questions about history, race, ethics, access and community have become more prominent.
AI-assisted coding expands who can experiment. A scholar can test a database, interface or chart without waiting for a programmer to agree that it is worth building. That shifts some authority toward the person with the research question.
It also introduces new dependencies. A model’s training, its provider and its default solutions influence what gets built. A scholar may gain freedom from a local technical bottleneck while finding it harder to understand why the new software takes the shape it does.
Those dependencies meet concerns already central to DHQ: control of data, language, labor, access and responsibility for errors. Its AI policy allows supportive uses while leaving disclosure, accuracy and responsibility with the human author. The practical question is whether a particular use helps scholars do that work well.
The humanist can make the app now. The next step is to make its choices understandable and revisable, and to decide who will have the power to maintain it.