qlaude: using AI in qualitative coding without losing control
A qualitative coding tool that uses AI to propose codes and draft analysis, while the researcher can always trace back to the original text and decide what to keep.
- Role
- Designer, Researcher & Developer
- Team
- Solo project
- Duration
- 3 months (ongoing)
- Client
- Personal tool / Open development
The project in one minute
The Challenge
AI-assisted qualitative analysis needs a visible connection between interpretations and the source passages.
My contribution
I designed the research workflow and built the application, codebook editor and scoped AI interactions.
Results and scope
A suggestion carries an exact passage, a code and an explanation. The researcher can inspect the interpretation before accepting it.
01Observation
A plausible summary can conceal where an interpretation came from.
02Interpretation
A code expresses an interpretation; it is not simply a keyword match.
03Design decision
Attach each proposal to exact source text, codebook context and a review decision.
Reading of the project reconstructed from the case study, not an original research artifact.
What remains to be established: The account is grounded in my own research practice; independent evaluation and broader adoption are not documented.
Presented at URCA 2026
I presented the human-in-the-loop model behind qlaude at URCA 2026, a two-voice talk on AI as a partner in qualitative analysis.
The Challenge
What I was responsible for
- Identified the problem from my own work as a researcher
- Designed the end-to-end workflow from project setup through report generation
- Designed the six AI interaction points and their Claude prompts
- Built the full-stack application (Next.js, Supabase, Vercel AI SDK)
- Designed the codebook management UI with drag-and-drop organization via React Flow
- Iterated on prompt engineering to ensure methodological rigor in AI outputs
Generic AI summarization tools can cut reading time, but they often return conclusions that are hard to trace back to the data. In qualitative research, that makes it hard to see how a result was built.
Qualitative coding takes time because every meaningful passage has to be read, compared against a codebook and placed within a broader interpretation. After years of doing it by hand, I wanted to find out which parts could be sped up without losing the link to the sources.
qlaude grows out of that constraint: the AI can make a proposal, and that proposal has to stay verifiable. Every suggested code is linked to the passage it came from and can be accepted, edited or discarded by the researcher.
"People analyzing interviews need to speed up the repetitive part while keeping codebooks, quotes, cross-case comparison and the ability to revisit decisions made during coding."
Beyond time, the risk is losing the ability to check how a theme or a conclusion was reached.
Manual coding scales badly with the number of interviews; automated summaries, on the other hand, tend to compress the material too early and hide the intermediate steps.
Research
Observations from my research work
Most of the time goes into re-reading
60% of coding time goes into re-reading: first to understand, then to code, then to verify, then to synthesize. AI can take on the proposal, leaving the decision to the researcher.
Generic AI summaries lose the structure of the method
Generic AI summarization produces text that resembles an analysis without its structure: no codebook, no traceability to source text, no consistency between researchers. It needed an AI that works with the same concepts researchers use.
3-5 hours per transcript
Average manual coding time for a 60-minute interview. With 10+ interviews per project, this single phase can consume 30-50 hours.
Comparison with existing tools
Many tools add AI without rethinking the workflow
Tools that have added AI (Dovetail's summaries, NVivo's auto-coding) use it as a separate feature without integrating it into the workflow. The AI doesn't know the codebook structure, doesn't cite specific text and doesn't explain its reasoning.
Coding and analysis often stay separate
Coding tools stop at the codebook and the report gets written elsewhere. The researcher has to reconnect coded passages to the narrative analysis in their head, a kind of synthesis where AI can help a lot.
Without a link to the source, a suggestion can't be checked
Academic and professional research requires that every claim trace back to source data. Any AI assistance must preserve this chain: quote → code → theme → insight.
Key Insights
AI can suggest; the decision stays with the researcher
This is the basic interaction model. Claude suggests themes, highlights passages and drafts analysis; every result is a proposal the researcher reviews, edits, accepts or rejects.
The interface uses the concepts of qualitative research
The interface follows how researchers already work, with themes, codes, codebooks and evidence, instead of reducing everything to generic tags and summaries.
Every AI suggestion has to trace back to the source
When Claude proposes a highlight it cites the exact text and segment and explains its reasoning. When it writes analysis, it cites specific participant passages.
Suggestions stay inside the codebook
AI suggestions are constrained by the codebook the researcher chose. Claude doesn't invent categories: it works inside the framework the researcher set up, which keeps transcripts consistent.
Cutting coding time without skipping review
The aim is to remove the mechanical work so the researcher can spend more time on interpretation. The time saved goes into deepening the analysis.
Goals & Principles
A first version of the codebook with AI
Given a research scope, Claude proposes an initial set of themes and codes: a structured starting point the researcher refines.
Coding suggestions on transcripts
Claude reads transcripts against the codebook and proposes highlights: exact text passages matched to specific codes, with reasoning for each suggestion.
A first draft of the analysis from the codes
From coded data, Claude generates publishable-quality analysis sections: continuous prose with participant quotes, recurring patterns and prevalence quantification.
Report synthesis with links to the evidence
Aggregate all coded data across interviews into a complete thematic analysis report, structured by the codebook, with cross-participant pattern analysis.
Guiding Principles
The researcher has the final word
Every AI suggestion is reviewable and reversible. The researcher's judgment overrides AI proposals at every stage.
Make steps and evidence visible
AI reasoning is always visible. When Claude proposes a code, it explains why. When it drafts analysis, it cites sources.
AI help grows with the project
AI helps more as the project matures. Early stages (codebook design) get light suggestions. Later stages (report writing) get heavier drafting, because the researcher has established the analytical framework.
Solution Design
Interactive diagram
An interpretation with a path back to its source
Select a node to highlight its connections and read the design decision behind it.
Excerpt
The exact passage anchors the analysis. Its surrounding context must remain accessible.
Connected to: AI proposal · Source context
Conceptual provenance chain based on the case study. No participant data or AI output is generated here.
A first codebook structure with AI
Starting from an empty codebook is hard: you know you need themes and codes, but until you've read the transcripts it isn't clear where to begin.
Alternatives considered
- No AI: blank codebook (traditional approach, high friction)
- Pre-built template library (generic, rarely fits specific research)
- AI-generated initial codebook based on research scope (tailored, editable)
Claude reads the research scope and streams a structured codebook proposal: 4-6 themes with 2-4 codes each, following KD notation (KD1.1, KD1.2). The researcher reviews and restructures using a drag-and-drop codebook manager built with React Flow.
The AI proposes a first hypothesis that the researcher refines by working with the data, without coding in their place. It helps get past the blank page while leaving analytical control with the researcher.
Trade-off: Risk of anchoring bias: researchers might accept AI suggestions uncritically. Mitigated by designing the UI to encourage editing (all fields are immediately editable, no 'accept all' button).
Suggestions directly on the transcripts
Reading transcripts line by line to find codable passages is the most time-consuming part. The researcher knows what they're looking for (the codebook defines it), but finding it means reading everything.
Alternatives considered
- Manual highlighting only (accurate but painfully slow)
- Keyword search / regex matching (too literal, misses semantic meaning)
- AI-powered semantic matching against the codebook (understands meaning, proposes highlights)
Claude receives the full transcript with segment IDs, the complete codebook with UUID mappings, and any existing highlights (to avoid duplicates). It proposes 5-15 highlights per transcript, each with: exact verbatim text, the segment it belongs to, the code it matches, and 1-2 sentences of reasoning.
The prompt work was decisive here. Claude must quote text exactly (no paraphrasing), reference specific segment UUIDs (for accurate positioning) and respect existing highlights (no duplicates). Structured output via Zod schema ensures consistent, parseable responses, streamed in real time.
Trade-off: AI proposals need review: false positives are possible. Reviewing 10 proposals is still much faster than reading 200 transcript lines, and the accept/reject interface is designed for quick decisions.
From codes to a first analysis draft
After coding there's another manual phase: reading all passages tagged with a code and writing the narrative analysis. That means re-reading every quote, finding patterns and synthesizing the findings into text.
Alternatives considered
- Manual synthesis (rigorous but slow, typically the final bottleneck)
- Basic summarization (loses quotes, flattens nuance)
- Guided analytical writing with strict methodological constraints
Two levels of analysis. Per code: Claude writes continuous prose about all quotes tagged with a code, identifies patterns, quantifies prevalence and weaves in verbatim quotes with participant attribution. Full report: Claude synthesizes the whole project into a publishable thematic analysis, with connections between themes.
Most of the design work is in the prompt constraints. Claude has to write in prose (no bullets), quantify prevalence ('three of five participants...'), always quote verbatim with attribution, surface minority views and contradictions, and write in the participants' language. With these constraints the text follows the conventions of qualitative analysis.
Trade-off: Generated analysis is a draft and needs review and refinement by the researcher. A structured draft with correct citations is still a very different starting point from a blank page.
Outcomes & Impact
qlaude now covers the workflow from defining the codebook to the final synthesis. The AI speeds up the first pass and the drafting, while codes and analysis stay linked to the original passages and to the changes the researcher made.
6 distinct AI interaction points across the full research workflow
Codebook scaffolding generated as a structured, editable proposal
5-15 highlight proposals per transcript, streamed in real-time
Full thematic-analysis draft generated from coded project data
AI responses validated against typed Zod schemas before entering the workflow
Researchers spend more time on interpretation and less on scrolling through transcripts
Every proposal shows its reasoning, so the researcher can evaluate it
Codebook consistency across transcripts is maintained by the AI working within researcher-defined codes
Report drafts include proper citations and prevalence quantification out of the box
Themes, codes and saturation are central concepts in the tool
What I delivered
- Full-stack application: Next.js + Supabase + Vercel AI SDK
- First version of the codebook generated by AI from the research scope
- Semantic transcript coding with highlight proposals and reasoning
- Per-code and per-theme analysis generation with citation requirements
- Full report synthesis across all interviews and themes
- Drag-and-drop codebook management via React Flow
- Real-time streaming for all AI interactions
Reflections
The hardest part was deciding what to show next to each proposal so a researcher could evaluate it.
What I would change
- Would prototype the analysis generation prompts with real research data earlier: the quality difference between generic and research-specific prompts was enormous
- Would add an explicit 'AI confidence' indicator to help researchers prioritize which proposals to review first
- Would build collaborative features sooner: multiple researchers coding the same project with AI-assisted inter-coder reliability
What worked and what was difficult
What Worked
Prompts built around the method's constraints
The writing rules in the analysis prompts (no bullets, quote, quantify prevalence, surface minority views) produced much better results than open-ended generation. Describing to the AI how a qualitative researcher works produced text that actually follows the conventions of qualitative analysis.
Structured output made the integration more reliable
With Zod schemas and the Vercel AI SDK's streamObject, every AI response was typed and validated, with no regex parsing. That was essential for highlight proposals, where the response has to contain exact UUIDs and segment references.
Separating suggestion and decision makes the workflow easier to control
Treating every AI intervention as a suggestion makes it easier to evaluate critically. That's why every proposal shows where it comes from and why it was made.
Challenges
Designing prompts means designing part of the experience
The hardest design decisions concerned the prompts more than the interface. Getting Claude to quote exact text (no paraphrasing), point to precise segments and write in the participant's language took many iterations, closer to interaction design than to engineering.
Helping without taking control away from the researcher
Too much AI and researchers feel passive. Too little and the tool doesn't save time. Finding the right level of suggestion (enough to accelerate, not enough to override) required constant calibration of how much the AI proposes at each stage.
Next project
NotionViz: workspace intelligence