B. Personal Use Cases: AI as Research Assistant in Practice

Purpose: Nine cases from the presenter's own research work — complete small cycles, honest about what worked and what did not. They are not success stories. They are meant to ground the conceptual material in lived experience and to give workshop participants something concrete to compare their own practice against.

Case 1: Reviewing a technically unfamiliar dissertation

Phase: Evaluation / close reading Tools: NotebookLM, Claude Desktop

The problem. A colleague submitted a doctoral dissertation on epidemiological modelling in ancient Rome — a technically demanding piece that combined computational disease models with ancient historical sources. The task: write a substantive review. The challenge was double: unfamiliar methodology (quantitative epidemiology) and an unfamiliar historiographical tradition.

The challenge. A dissertation is long, dense, and not designed to be read quickly. Writing a credible review required genuine engagement with both the technical and historical argument — not just a summary. The reviewer cannot fake this.

The solution. Two tools, two different functions. NotebookLM was used first for a broad orientation — uploading the dissertation and asking questions about the overall argument and methodology. Then Claude Desktop with the dissertation text for active critical reading: iterative, question-driven, working through specific sections with pointed challenges.

The good. "Reading through asking questions" works surprisingly well. The ability to move freely through a large text — jumping to specific claims, asking for clarification, then pressing on weak points — felt like having a reading partner. The session produced structured notes and a working critique. The "produce a markdown artefact with section-by-section notes" prompt at the end was a first experiment with structured output — a pattern worth repeating.

The bad. Claude Desktop's file handling was frustrating: repeated uploads, lost context across long sessions, the upload dance. The workflow had to be fragmented across multiple sessions.

The ugly. The doubt that stayed: Is this still my review? The critical tone came partly from iterating with Claude on weaknesses. The assessment felt accurate — but it was assembled collaboratively. This is the third-party problem in a personal, non-collaborative form: the colleague is responding to a review that was shaped, partly, by a process they know nothing about.

Takeaway. Active reading through questions is the killer feature for long, dense texts — but the ownership question does not go away just because the output is accurate.

Case 2: Quick orientation before a review meeting

Phase: Evaluation / orientation Tools: NotebookLM (podcast), Claude Desktop

The problem. A recently defended doctoral thesis in an adjacent field — overlapping methodology, some shared domain. The task: get up to speed quickly before a formal review meeting. What are the main achievements? Where are the weak points? What is this person's approach to the problems I work on myself?

The challenge. The adjacent-field context introduced a specific risk: strong prior views that could bias the reading. The goal was not just comprehension but calibration — finding out what this thesis actually does, not what I expected it to do.

The solution. NotebookLM's podcast feature for the first pass: an audio overview generated from the thesis, listened to in a lightweight context (commute, background). The podcast's tone was unexpectedly cheerful — almost celebratory — which provided an orientation but was clearly not a critical reading. Claude Desktop then for targeted active reading: specific chapters, pointed questions about methodological choices and gap treatment.

The good. The podcast as a lightweight entry point works. The funny, upbeat tone was actually useful — it provided a confident first map of the argument without the weight of a close read, leaving critical attention for the Desktop session. The combination felt efficient.

The bad. The podcast cannot counterargue. It narrates; it does not challenge. Using it alone would have left me with the author's framing intact.

The ugly. The prior-overlap doubt persisted: Am I using this to confirm my existing views, or to genuinely understand theirs? The sycophancy risk is sharpest when you already have a stake in the territory.

Takeaway. Podcast as map, Desktop as critical instrument — two different tools for two different reading modes.

Case 3: Preparing a university course from scratch

Phase: Planning, design, material preparation Tools: Claude Desktop (conceptual), Claude Code (materials)

The problem. A new graduate-level course introducing computational text analysis methods to humanities students — corpus analysis, topic modelling, word embeddings, LLM-assisted annotation — with no prior version to build on. The students work with religious texts, social media data, and interview corpora. Start from a blank canvas.

The challenge. The scope problem: "Distant Reading" covers a large, fragmented field (corpus linguistics, stylometry, topic modelling, network analysis of texts, sentiment analysis...). Without a map of the field, it is impossible to make a principled decision about what to include and what to set aside. And a teacher who has not mapped the whole cannot make a confident pedagogical case for what they chose to focus on.

The solution. Claude Desktop for the conceptual phase: extended dialogues about the field's structure, what the introductory literature looks like, what a non-programmer student would need to know first. Claude Code for the materials phase: PDF-to-markdown conversions of key readings, draft tutorials, Jupyter notebooks with annotated code examples, syllabi drafts.

The good. The most useful thing was not the outputs — it was the feeling of visibility: "I can see what I am setting aside, rather than avoiding it because I do not have time to research it." This is the difference between a deliberate pedagogical choice and a default caused by ignorance. The feedback cycle on scope also worked: Claude pushed back when the proposed course was too large, which forced a productive conversation about what the course was actually for.

The bad. The scope may still have been too ambitious. A course on "Distant Reading" for non-programmers might be a more modest thing than what this design produced.

The ugly. The authorship question at scale: how much of the course design is mine, and how much is a synthesis of what Claude believes an introductory distant reading course should look like? The centroid problem, applied to pedagogy.

Takeaway. AI makes it possible to see the whole field before deciding what to teach — the real value is the visibility, not the materials.

Case 4: Data analysis — scripts vs. direct conversation

Phase: Data analysis Tools: Claude Code

The problem. A DISSINET research dataset: historical documents from multiple archival sources, encoded as structured sequences for comparative analysis of textual and structural relationships across the corpus. The task: analyse patterns in the data in preparation for a paper with a co-researcher.

The challenge. Two different modes were available: (1) write analysis scripts and run them, reviewing outputs; (2) give Claude direct access to the data and conduct the analysis as a conversation. The question was which to use, and whether they produce different results.

The solution. The experiment ran both ways. Script-based analysis first — standard workflow. Then a second pass as direct conversation: larger context, more flexible method choice, questions like "what else does this data suggest?" that cannot be put into a script.

The good. The conversational approach with larger context produced more: Claude noticed patterns and tried methods that the scripted approach would not have generated, because the scripted approach is bounded by what the researcher thought to ask. Quick iteration and micro-discoveries — the data talked back faster.

The bad. The analytical report produced by the conversation is harder to audit than a script. The reasoning is embedded in the dialogue, not in reproducible code.

The ugly. The third-party question, made concrete: Can I give this report directly to my co-researcher? It was checked, but it carried the marks of a process she was not part of. The "Claude said, maybe check this" note is a partial solution; it is not a full answer.

Takeaway. Direct conversation produces richer analysis than scripts — but the audit trail is weaker, and the co-researcher was not in the room.

Case 5: Turning student course outputs into a public article

Phase: Writing, synthesis Tools: Claude Code

The problem. A course on quantitative approaches to religious studies had produced student analyses of a large corpus of academic theses — metadata, keyword frequencies, thematic networks visualising research trends in the field. The task: synthesise these into a short public-facing article presenting what the data showed.

The challenge. The materials were scattered: student submissions in different formats, at different quality levels, covering different aspects of the topic. No unified narrative existed. Starting from scratch would have taken days.

The solution. A single prompt to Claude Code: here are all the materials, here is the purpose (a public article summarising what the course produced), draft the paper. Claude compiled the materials, identified the through-line, and produced a draft that I then heavily edited.

The good. "Here are the materials, here is the purpose, draft the paper" is a genuinely powerful pattern when the source materials are rich. The draft was much easier to edit than to write. Claude also caught errors in the data that the course teachers had not noticed — the external eye on the results was unexpectedly useful.

The bad. The draft required heavy editing. It was a serviceable scaffold, not a publishable text.

The ugly. The ethical question about student materials: these were student outputs, some of which included personal or sensitive data. The decision about what to include was mine, but the process of aggregation was not. And the students were not part of the AI conversation that shaped how their work was presented.

Takeaway. The pattern works when the materials are rich — but the downstream ethics of AI-mediated student-output synthesis are not yet resolved.

Case 6: Popularizing a published paper as a data snapshot

Phase: Writing, communication Tools: Claude Code

The problem. A recently published research article by a colleague needed a short data-snapshot treatment: a compact, visually focused summary for a general academic audience, not a specialist one.

The challenge. Two constraints in tension: the paper's author needed to be able to stand behind the result (accuracy), but the output needed to be accessible to non-specialists (simplicity). And the presenter was not the author — any summary needed sign-off.

The solution. Upload the paper to Claude Code; ask for a data snapshot with visual emphasis. Two iterations: first Claude produced an interactive graph (the instinct was "data = interactive visualisation"). Second iteration focused on the story — a narrative summary with static visuals. The second was better.

The good. The story-over-graph instinct correction was important: the fetish for interactivity produced something that was technically impressive and communicatively weak. Forcing a narrative-first approach produced something that actually communicated.

The bad. The output still required significant attention from the paper's author to verify and adjust. The time savings were real, but not as large as hoped.

The ugly. The author's attention cost is the hidden tax. AI-assisted popularization does not eliminate expert review — it shifts the burden from production to verification. If the author is busy, this is not faster, only differently shaped.

Takeaway. Story beats graph; but the author's verification time is not zero, and it cannot be.

Case 7: Building a research tool from scratch

Phase: Software development, research infrastructure Tools: Claude Desktop, Anthropic API, Gemini, Cursor

The problem. A DISSINET research project needed a custom application: a semantic search tool enabling natural-language queries over large collections of medieval historical narrative sources, with a validation interface for human review of AI-assisted information extraction. No off-the-shelf tool existed. The project required: Python/R interoperability, a custom web dashboard, and patches to several libraries.

The challenge. Building custom research software requires sustained technical problem-solving across many layers: adapting an R statistical library to run in Python (pymer), building a UI for human validation workflows, managing API integrations. Each layer has its own complexity; the layers interact.

The solution. Agentic use of Claude Code and Cursor across the full development cycle, with Gemini for specific code review tasks. The workflow was iterative and tool-intensive: let the AI manage the complexity of library patching and boilerplate, focus human attention on design decisions and research logic.

The good. This is where agentic AI genuinely shines. Tool complexity management — the kind of work that is tedious, error-prone, and does not require research judgment — was handled by the AI. The researcher-developer could stay at the level of "what should this tool do" rather than "why is this library import failing."

The bad. The boundary between "technical problem-solving" and "design decision" blurred repeatedly. When Claude suggested a UI layout or a data structure, that was a design decision — but it arrived as a technical suggestion and was easy to accept without noticing the shift.

The ugly. Code produced by an agentic process is code you did not write. Debugging it requires understanding it first. When something broke, the time to understand what the AI had built was not negligible — and sometimes the architecture was not what you would have chosen.

Takeaway. Agentic AI for software development is genuinely transformative for researchers who can code a little — with the caveat that you are responsible for code you did not fully write.

Case 8: Reviewing four related research projects for synergies

Phase: Project management, strategic planning Tools: Claude Code

The problem. Four active studies in a small neuroscience laboratory — all connected through shared data, overlapping methods, and a common team of four people each at 20% capacity. The question: given limited bandwidth, how should the lab prioritise, and what synergies between the projects were not being exploited?

The challenge. The project materials were distributed across directories, documents, and informal knowledge. No single overview existed. Any strategic review required first building a coherent picture of what each project was, where it stood, and how they connected — a task that would have taken a long meeting to do verbally.

The solution. Upload all project materials to Claude Code as a shared context. Ask: read all of this, clarify the relationships, identify synergies and blockers, and produce a meeting agenda for a one-hour team discussion with the key decision points.

The good. The output was directly usable: a shared CLAUDE.md synthesising the project context, a meeting agenda with six decision points, and a milestone plan for the highest-priority project. The clarification of ownership splits (who owns which pipeline, which analysis) surfaced ambiguities that had not been made explicit in the project materials.

The bad. The strategic recommendations were reasonable — but "reasonable" often means "centrist." What the AI suggested prioritising was what the average project manager would suggest. The genuinely contested questions (which experimental design to choose, whether to add an additional measurement modality) were not resolved by the review, only structured.

The ugly. This is the centroid problem in strategic planning. The meeting agenda was good for the tractable decisions. For the genuinely hard ones — the ones where the right answer depends on scientific judgment about what is most interesting — Claude could structure the question but not answer it.

Takeaway. AI turns scattered materials into a structured briefing; it does not substitute for the strategic judgment that has to happen in the room.

Case 9: Building this workshop

Phase: All phases Tools: Claude Code

The problem. A three-hour workshop introducing Claude Code and Claude Desktop to humanities researchers at DISSINET — a mixed audience of historians, social scientists, and computational scholars, mostly non-programmers. No prior version of this workshop existed. The materials needed to be self-contained, usable without the presenter, and comprehensive enough to be a reference after the session.

The challenge. The problem was not technical but editorial: what to include, at what depth, in what order — and how to build materials that were intellectually honest about what AI can and cannot do. The scope was large. A workshop that only shows possibilities loses credibility with sceptical researchers; one that only discusses risks loses the audience.

The solution. The workshop was built using Claude Code on the workshop itself — over several sessions, producing 40+ interconnected markdown documents, each one written in dialogue. Claude drafted; the presenter edited, redirected, added cases and nuance. Cross-linking between documents was maintained automatically. The session was agile: a document written in one session would be revised in the next when new material changed the framing.

The good. The scale of output would have been impossible solo. The ability to maintain conceptual coherence across 40+ documents — keeping the terminology consistent, keeping the cross-references alive, revisiting earlier documents when later ones changed the framing — was genuine. This document is one of the 40.

The bad. The presenter cannot always tell what the workshop "thinks" versus what it decided. When Claude drafted a passage and the presenter approved it without a strong rewrite, that passage reflects the statistical average of how workshops like this get written. That is not always wrong. But it is not always right either.

The ugly. The most recursive possible doubt: Is the workshop about AI assistance itself an AI-assisted product? And if so — does that make it more honest or less? The answer is: more honest, probably. The workshop does not claim that AI assistance is risk-free. It was produced under exactly the conditions it describes. But the question does not go away just because the answer is defensible.

Takeaway. The workshop is a product of the method it describes — which is either the best possible demonstration or a conflict of interest, depending on how you look at it.

Patterns across the cases

Looking across nine cases, four things recur:

Active reading through questions is the most transferable pattern. It appears in Cases 1, 2, and 4, and underlies Cases 5 and 9. Giving AI a large text and iterating through it with pointed questions — not asking for a summary, but asking specific challenges — is more valuable than any other single technique. It scales to any text-heavy task.

The ownership doubt appears in almost every case. Not as a decisive problem — the outputs were used, the work proceeded — but as a persistent background question. Is this still mine? Can I give this to a colleague without explaining the process? The doubt does not resolve; it becomes something to manage deliberately.

AI scales the doable; it does not resolve what to do. In every case, the hardest decisions — the critical assessment in Case 1, the scope in Case 3, the design in Case 7, the strategic priorities in Case 8 — remained human problems. AI accelerated the work that surrounded them. It did not make the hard calls easier.

The cases where AI is most powerful involve bulk, structure, and logistics. Case 5 (compiling materials into an article), Case 7 (managing software complexity), Case 9 (building coherent materials across 40 documents). The cases where it is most risky involve interpretation, evaluation, and direction (Cases 1, 4, 8). The engineering-like vs. interpretive distinction is not a theoretical observation — it shows up in practice every time.

Related