Learn · Qualitative coding
Use a local AI model for qualitative coding, with human review
A local model can suggest first-cycle codes without sending transcripts to a cloud service. That is the easy part. The work is reviewing every suggestion against the source, recording what changed, and keeping interpretation with the researcher.
After this guide you will be able to:
- Get first-cycle code suggestions from a local model, with no data leaving your machine.
- Review each suggestion with a clear four-status system.
- Explain why a model's confidence score is not evidence a code is right.
- Keep an audit trail your reviewers and co-authors can follow.
What AI can and cannot do in coding
From our own coding. Across one small study, a local model's suggestions broke down like this: a handful we accepted as written, about half we edited, and a large share we rejected. The model has habits — it reaches for emotion words ("waiting anxiety") where the data calls for a situation ("waiting for results"), and it splits one idea into three labels. None of that is a flaw to hide. Rejecting suggestions is not the tool failing; it is the method working.
The useful frame is simple: a local model is fast at proposing candidate labels and blind to what they mean in this study. It has read no ethics application, met no participant, and holds no theory. Every output is a draft. The value comes from a person reading each draft against the source and recording the decision.
The four review statuses
Give every suggested code exactly one status. There is no score for "true" — the model does not know truth, and the status system should not pretend otherwise.
| Status | Meaning |
|---|---|
| accepted | the suggested code fits the excerpt as written |
| edited | close, but your label is better — you write the final code |
| rejected | wrong, too vague to reuse, or a duplicate of another code |
| unclear | you cannot decide yet — a legitimate resting place, revisited later |
Only accepted and edited rows should feed anything downstream — your codebook, your frequency counts, your themes. Rejected and unclear rows stay in the record but out of the analysis. Keeping them visible, rather than deleting them, is part of the audit trail: a reader can see what the model proposed and what you did with it.
One row, worked
Here is a single excerpt through the whole pass, the way it looks in practice:
| Field | Value |
|---|---|
| Excerpt | "The waiting for the phone call is worse than the scan… once it was nine days." |
| Model suggested | waiting anxiety (self-reported confidence 0.8) |
| Your status | edited |
| Final code | waiting-for-results |
| Note | code the situation, not the emotion; "anxiety" is an interpretation to make later, not a first-cycle label |
The confidence was high and the label was plausible — and you still changed it, because the discipline is to name what is in the excerpt, not what the model felt about it. That note in the last row is worth more than the code: it is the reason a co-author or reviewer can follow your decision.
Why "confidence" is not accuracy
Local models often attach a confidence number to each suggestion. Treat it as a self-report, not a measurement. A model can be confidently wrong, and — this is the one that matters — the model agreeing with your reading is not evidence your reading is correct. Two readers who share the same blind spot will agree all day. If you want a genuine check, it has to come from a different source: a second coder, a second model, or the data pushing back through a negative case. Agreement is cheap; independence is what counts.
Choosing a local model · matched to your computer
Bigger models write better first-pass labels but need more memory. Because you review every suggestion anyway, a small model is a safe place to start — a weaker model means you edit more, not that your analysis is worse.
| Your RAM | Start with |
|---|---|
| 8 GB | a 3–4B model (e.g. llama3.2:3b, qwen3:4b) |
| 16 GB | an 8B model (e.g. hermes3:8b, qwen3:8b) |
| 32 GB+ | a 14B model (e.g. qwen3:14b) |
Run them locally with Ollama (free). For non-English interviews, the larger models are noticeably better at smaller languages — try your own language before deciding.
The prompt matters: force provenance
A coding prompt should pin the model to the text and forbid invention. The rules that keep it grounded:
- Use only the excerpt given. Do not bring in outside knowledge about the topic.
- Do not invent participant details, and do not guess demographics unless they are stated.
- Keep the code (what is in the excerpt) separate from interpretation (what it means for the study).
- Mark uncertainty, and quote the words in the excerpt that triggered the code.
- Return contradictions and near-misses rather than smoothing them over.
A model told to quote its trigger words is far easier to review — you can see at a glance whether the label actually comes from the text or from the model's imagination.
A necessary caveat
This workflow speeds up first-cycle labelling. It does not find your themes. A pile of frequent codes is not a theme, and a cluster a model draws is not a theme — a theme is a patterned meaning you construct, state in a sentence, support with evidence, and test against the cases that do not fit. Frequency describes how often a code was applied; it is not importance. Keep those two apart in your writing, and the AI stays a labeller while you stay the analyst.
You can build this yourself with Ollama, a coding prompt, and a spreadsheet for the review statuses.
If you would rather have it ready — the prompt with provenance rules, the four-status review file, a codebook that never gets overwritten, an audit trail, and a worked demo study — QualiVahti Local packages the whole local workflow around this exact discipline.
See the vault that speeds your coding — €49Related guides
Upstream: transcribe interviews offline with Whisper. Downstream: make your analysis code citable. More on the Learn page.