Learn · Qualitative coding
A local AI model can suggest first-cycle codes for your interview data — on your own computer, free, with no transcript sent to a cloud service. This guide shows how to get useful suggestions, and the more important part: how to review every one so the analysis stays yours. The model proposes labels. You decide what anything means.
After this guide you will be able to:
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.
So the honest frame: a local model is fast at proposing candidate labels and blind to what they mean. It has read no ethics application, met no participant, and holds no theory. It is a tireless first-pass labeller whose every output is a draft. The value comes from a human reading each draft against the data — which is exactly where interpretation lives, and exactly what a reviewer will want to see you did.
Give every suggested code exactly one status. There is no score for "true" — the model does not know truth, and neither status system should pretend it does.
| 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.
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.
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.
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.
A coding prompt should pin the model to the text and forbid invention. The rules that keep it honest:
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.
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 QualiVahti Local — €49Upstream: transcribe interviews offline with Whisper. Downstream: make your analysis code citable. More on the Learn page.