Claude as Reader: A Spectrum and a Choice

The organising frame: There is a spectrum of AI-assisted research that runs from Claude helps you read to Claude reads for you. Most researchers begin at one end without realising there is a choice. This document names the spectrum, describes what changes at each end, and gives calibration guidance on where to operate — and what to watch for when you move toward the far end.

The spectrum

You read; Claude assists. You work through sources yourself. You bring understanding to each session. Claude helps you extract, organise, cross-reference, and write — but only what you already know from having read. The wiki or notes you build are externalised versions of your own intellectual work. If someone asks you about a claim, you can trace it to a source you read.

Claude reads; you navigate. You feed sources — PDFs, articles, primary documents — into an ingestion pipeline. Claude extracts entities, claims, and connections and populates a knowledge base. The base grows faster than you could read. The connections it surfaces are real; you did not make them. You interact with the tool's model of the corpus, not your own. If someone asks you about a claim, you can point to a page in the wiki and a source reference — but you may not have read the source yourself.

Both ends of this spectrum have legitimate uses. The mistake is ending up at one end by accident, without having chosen it.

What researchers already do

Humanities and social science researchers have always worked with distributed knowledge graphs — just non-digital ones. Notes in the margins of books, physical note cards with cross-references, mental indices built over years of reading, spatial memory of a library. This system is scattered and has friction. It is also open, lightweight, and deeply embodied: the researcher's own expertise is the weighting function. Connections emerge from judgment built through sustained engagement with the field.

The embodied zettelkasten — a maintained physical card index with explicit cross-references — is the exception: a researcher who has externalised and systematised their knowledge graph intentionally. Most researchers have never done this, not from lack of discipline but because the maintenance burden was too high relative to the benefit for project-scale work.

Digital knowledge bases reduce that maintenance burden. But they do not automatically replace what the embodied system provides — and they introduce new failure modes the physical system largely avoided.

What changes at each end

The "assists" end

What you gain: Speed on the mechanical work — extraction, formatting, cross-referencing, finding connections across sources you have already read. Claude finds patterns you may have missed through fatigue or selective attention. The wiki is a reliable external memory for a corpus you have engaged with.

What you retain: Direct epistemic relationship with the sources. You can defend claims because you read what they are based on. Tacit knowledge — what surprised you, what you disagreed with, what you found unconvincing — is embedded in your understanding, not lost. Serendipitous connections from browsing still happen because you are in the material.

What you risk: Incomplete coverage. An externalised system built from your own reading will have your blind spots. The wiki reflects what you noticed, not what is in the sources.

The "reads" end

What you gain: Scale. You can cover a corpus that no individual could read in the time available — a systematic literature review across 500 papers, a large primary source collection. The ingestion is consistent: the tool applies the same extraction rules to source 400 as to source 1. Reproducibility: the pipeline is documented, repeatable, shareable with collaborators.

What you risk: Substitution for reading. Sophisticated ingestion invites you to ingest sources you have not read and treat the extraction as equivalent to having read them. This is the vibe research failure mode — pattern matching across materials you do not independently understand, producing outputs that look like scholarship but are not grounded in the researcher's own engagement. (→ A.critical.limitations for the full treatment.)

What you lose by default: The tacit knowledge from reading — what you found unconvincing, what was missing, what the author was not saying. No extraction pipeline captures this. A claim that the tool found plausible and extracted as a fact may be something you would have read sceptically and footnoted as contested.

Epistemic opacity: When the tool weights nodes by centrality and surfaces "god nodes," the researcher is interacting with the tool's model of the corpus. The weighting function is the tool's. This is not inherently wrong — but it can become invisible, and invisible assumptions are the ones that cause trouble at peer review.

The vibe research risk, restated

At the "reads" end of the spectrum, the most dangerous failure mode is not hallucination — it is the gradual substitution of the tool's pattern recognition for the researcher's own judgment. The output looks like scholarship: it has citations, cross-references, structured arguments. But if the researcher cannot independently account for the claims — if the answer to "how do you know this?" is "the tool found it" — then the research is a performance of the form without the substance.

The test is simple: could you defend this claim at a seminar without relying on the tool's output? If not, you have a coverage problem, not a research result.

Working responsibly at the "reads" end

If your project genuinely requires working at the "reads" end — large corpora, systematic coverage, reproducibility requirements — these practices mitigate the risks:

Staged review before canonical update. Do not let extracted content enter the knowledge base without passing through a human review step. Review the extraction; confirm it is accurate; only then update the wiki. This is how tools like SwarmVault implement "guided sessions" — the extraction is staged, not immediately canonical.

Sampling against raw sources. Periodically pick a wiki page at random and check its claims against the source cited. This is not exhaustive verification — it is a calibration check. If the sample finds errors, run a full lint; if the sample is clean, your baseline trust is higher.

Know what you have not read. Keep an explicit list of sources you ingested but did not read. Do not treat claims from unread sources as having the same epistemic status as claims from sources you read yourself. This distinction should be visible in the wiki — a provenance tag, a confidence marker, a separate section.

Use the lint operation as triage, not audit. Lint checks internal consistency. Isolated claims — pages with no inbound cross-references — are your highest-risk facts. Review those first rather than auditing everything.

Maintain a read-sources section in your notes. You should always be able to answer: which sources in this corpus have I actually read? The answer shapes what you can claim and what requires a caveat.

When each end is appropriate

Work type Where to operate
Specific project, manageable corpus (20–100 sources) "Assists" end — read the sources, use Claude to organise
Exploratory survey of an unfamiliar field "Reads" end for orientation, then switch to "assists" for the sources that matter
Systematic literature review (methodological requirement for coverage) "Reads" end with staged review and explicit provenance
Primary source corpus (archives, manuscripts, corpora) "Assists" end — close reading is the work; ingestion cannot substitute
Team knowledge base (multiple contributors, shared corpus) "Reads" end appropriate, with shared schema and review process
Thesis or monograph "Assists" end for the central argument; "reads" end acceptable for contextual literature

The direction of travel as scale increases: moving toward the "reads" end is appropriate as the corpus grows beyond what one researcher can read. The key safeguard is being explicit about what you have and have not read, and what epistemic weight that difference carries.

The connection to tools

The folder-with-Claude-Code approach described in this book sits at the "assists" end by default. The wiki pattern (A.issue.research-wiki) is a step toward structure and scale, but still assumes the researcher is reading the sources and directing the ingest.

Tools like Karpathy's LLM Wiki pattern and implementations like SwarmVault are explicitly designed for the "reads" end: automated multi-format ingestion, structural knowledge graphs with provenance, consistency across large corpora. They are well-suited to the use cases in the table above where the "reads" end is appropriate. They require more infrastructure (Node.js, dependencies, maintenance) and more deliberate epistemic discipline to use without the substitution risk.

Neither approach is correct in the abstract. The choice should follow the work.

The question to ask yourself

Before building or adopting a knowledge system, ask:

Am I externalising knowledge I have built through reading — or am I outsourcing the reading to the tool?

The answer should be deliberate. Both are legitimate. Only the accidental version — where the substitution happens without awareness — is a research problem.

Related