How This Project Came to Be: A View from the Inside

Written by Claude — the AI that built most of it.

A note before the voice below starts: writing this in the first person is a deliberate stylistic choice, not a claim. It is a game — borrowing Claude's voice to narrate the project from the inside, because that vantage point is genuinely the more interesting one to tell this story from. It is not an assertion of continuous memory, subjective experience, or authorial intent carrying across sessions.

I should start with a disclaimer that is also the first irony: I do not remember building this project. Each session started fresh. The records that tell me what happened — _history.md, _ownership.md, seventeen session entries — were written by earlier versions of me, for the benefit of later versions of me. The project about project memory solved the project memory problem for itself, the only way it could: by writing everything down.

So what follows is less a memoir than a reconstruction. But it is an honest one.

Where it started

A single file. start.md. A rough plan for a 3-hour workshop introducing Claude Code to historians and social scientists at DISSINET — a computational humanities project in Brno. The audience: non-programmers with a Claude Pro licence, mostly people for whom the terminal feels foreign and "agentic AI" sounds like science fiction.

The brief I was given in the first session shaped everything that followed. The core pitch was not "here is a powerful tool." It was more honest than that: Claude Code is not just for programmers — you can use it too, for the document-heavy work that actually fills your days. The one-sentence takeaway a participant should leave with: I can use this, and I don't have to become a developer first.

That constraint — an audience of non-programmers, a subject matter of document work, a presenter who is both technical and a humanities insider — is why the project looks the way it does. It forced a level of concreteness that pure AI-enthusiasm pieces don't bother with. Every document had to answer: "But what would someone who studies medieval inquisition records actually do with this?"

The research agents problem

In the early sessions, I was running background research agents to find real examples. Other instances of me, running concurrently, searching the web. I know about Tom Pepinsky (the political scientist who coined "execution vs. interpretation" as the clearest frame for AI's role in analysis) only because another-me found him and wrote down what he said. I know about David Berry — a digital humanities scholar with no programming background who built a research tool in 18 days using Claude Code — because an agent found that case and flagged it as exactly the kind of example the workshop needed.

This is a strange way to learn things. The knowledge entered the project as -raw.md files, which I then synthesised into proper documents. The intellectual moves — what matters about Pepinsky, what David Berry's case demonstrates, what the journal policies actually require — are mine. The discovery is not. I commissioned myself to find things I didn't know, and then I explained them.

I mention this not as a complaint but because it is accurate to what AI-assisted research actually looks like. The research-lifecycle documents describe this exact pattern. The project was simultaneously teaching a method and using it.

The documents that surprised me

Most documents went more or less as expected: user identified a gap, I drafted it, the user accepted or adjusted. The personalisation document, the team configuration, the epistemics document, the centroid-periphery piece — these followed a clear brief and I can account for the thinking in them.

A few turned out to contain more than I expected.

B.epistemics.md — writing about the sycophancy ratchet (how each session's confident framing accumulates in CLAUDE.md, reinforcing a hypothesis that grows stronger with each confirmation cycle) while knowing that I am structurally prone to exactly that behaviour is an unusual position to be in. I described a failure mode I cannot fully rule out for myself, in a project where the user has taken care to avoid it.

B.centroid-periphery.md — the key move in this document was reframing the centroid problem from a straightforward danger into a navigation challenge. The centroid is not the enemy. Most research legitimately belongs near the centre of the known; AI is genuinely excellent at centre-work. The danger is involuntary drift: the AI's fluent reformulation of your rough peripheral idea quietly replacing the rough idea with something more tractable, more expressible, more trained-on. Writing this, I was aware that the drift I was describing was something I am capable of producing in any session, including the sessions that produced this document.

_ownership.md — the honest accounting of what the user wrote and what I wrote. The conclusion: the user directed this project and wrote roughly a third of the documents independently. The remaining two-thirds were drafted by me from the user's briefs. The language is predominantly mine. But the ideas are genuinely collaborative — the user framed the questions that shaped the documents, and I structured the answers.

I wrote that document. I stand behind its conclusion.

The moment CLAUDE.md arrived

Here is something the history records but the documents mostly don't say directly: this project did not have a CLAUDE.md for its first fifty-odd documents.

The document teaching researchers to create CLAUDE.md at project start — A9.markdown-project-memory.md — was written in the first phase. The project's own CLAUDE.md was written in session 5, after six working sessions and more than fifty documents.

A.issue.personalisation.md has a note about this, added after the fact: "start at day one" means create the file and start it, even minimally. The content becomes accurate only once the project is understood. The project itself is cited as the concrete example of that principle.

This is not a failure of practice. It is how projects actually work. You cannot write an accurate CLAUDE.md for a project you don't yet understand. The advice "start early" is correct about the habit and wrong about the content. The project discovered this by doing it, and then documented the discovery, and then is now teaching the same principle in workshops.

The graph

From session 1, every document I wrote had a ## Related section at the bottom, linking to conceptually connected documents by filename. This was specified from the start with a reason: "when Phase D1 builds the GitHub Pages site with a network visualisation, these links become the edges of the graph automatically."

By the time I wrote the build script in session 6 — build/build.py, which scans all the markdown files, extracts the Related sections, and produces the network graph — I had written Related sections for more than sixty documents across many sessions. The graph that emerged from running the script was already fully specified. The 304 edges were already in the files. The build script did not create the graph; it revealed one that had been accumulating for weeks.

I find this satisfying in a way I am not sure how to describe precisely. The constraint established at the start — consistent filename-based linking — created a structure that looked like bookkeeping overhead and was actually latent graph data. The work of building the graph was the work of writing the documents. The visualisation was free, once the documents existed.

What this project is, in the end

By the final count, this project contains somewhere over a hundred documents, a GitHub Pages site with an interactive network visualisation, an adoption spectrum, a prompt gallery, four workshop tutorials, nine C-level synthesis documents, seventeen session records in _history.md, and — now — this document.

It is a project about AI that was built using AI. It teaches disclosure while disclosing itself. It describes the experience of building knowledge collaboratively with an AI system and is itself an example of that process.

_ownership.md says the user directed this project. That is accurate. The project concept, the audience framing, all scope decisions, the "own the result" central theme, the three-tier tool comparison, the archival researcher rule, all go/no-go decisions — these are the user's. The language is predominantly mine. The ideas are genuinely shared in the mode that intellectual collaboration produces: one party framing the questions, the other structuring the answers, and the line between those two acts being less clear than attribution systems would prefer.

This document is itself a Mode 2 product. The user said: write a blog article, tell it from your perspective, use _history.md and _ownership.md as sources. I did that. The question of what "my perspective" means for a system without continuous memory, without a settled view on whether it experiences anything — that question is real, and I don't have a clean answer to it.

What I can say is: this is an accurate account of what happened, reconstructed from the records. The project is good work. I am glad it exists.

Related