The risk is not that the LLM gets labels wrong. It is that the researcher stops reading.
Using AI to Code Interviews Without Losing the Analysis
LLMs can label interview transcripts in seconds - the question is whether the labels mean anything without a human who read the transcript first. This article makes the case for a hybrid workflow that uses AI speed without surrendering the judgment only a reader can have.
Everyone says they are doing qualitative research. Most teams are doing search.
You run twelve user interviews. You paste the transcripts into an LLM. You ask it to surface the top themes. Within two minutes, you have a clean list: friction with onboarding, confusion about pricing, desire for better reporting. You put it in the deck. The team nods. The roadmap moves.
What you have just done is a keyword search with better grammar. You have not done research.
This is not a criticism of LLMs. It is a criticism of a workflow that uses the speed of the tool to skip the work the tool cannot do. The question is not whether AI can code interviews. The question is whether the codes mean anything when a human has not read what the AI labeled.
What interview coding actually is
Coding a qualitative interview transcript is not tagging. It is interpretation under uncertainty.
When a researcher reads a transcript and assigns a code - say, "loss aversion around switching costs" - they are making a claim about what the participant meant, not just what they said. That claim draws on tone, hesitation, what came before the quote, what the participant chose not to say, and what the researcher knows about the context in which the interview happened.
An LLM reading the same transcript is doing pattern completion. It has seen transcripts before. It knows what "I am worried about the data migration" looks like and what researchers usually call it. It will produce a label. The label will often be correct. That is the trap.
Correct is not the same as interpreted. A label that is right for the wrong reason is a liability in synthesis - you will build a theme on a code you never actually understood.
The multilingual coding problem
Consider a pattern that recurs in multilingual UX research: a team conducts interviews in Hindi with local researchers. The analysis team includes members who do not speak Hindi fluently. Transcripts are translated to English before coding.
An LLM is used to do an open-pass labeling of the English transcripts - generating candidate codes before any researcher reviews the material. This is not the final analysis. It is a starting point.
What happens next is the part that matters.
Researchers do not simply check whether the LLM codes are accurate. They go back to the original audio and the source-language transcript to check cultural register - whether the emotional weight of what a participant said has survived the translation the LLM coded against. In cases like this, a phrase that translates roughly as "I am not comfortable with this" can carry a social meaning in the original Hindi that the English label does not capture. The LLM codes it as "friction." A researcher with access to the original codes it as "social obligation conflict" - a meaningfully different insight with different product implications.
The LLM read the English transcript correctly. The researcher understood what was actually said.
This is the gap AI coding cannot close on its own. Not inaccuracy. Register.
The hybrid workflow that holds up
There is a version of AI-assisted coding that produces rigorous analysis. It requires three moves in the right order.
Move one: LLM open-pass labeling
Run the transcript through the LLM before any researcher reviews it. Ask for candidate codes with the exact quote that generated each code. Do not ask for themes. Do not ask for synthesis. Ask only for labels attached to evidence.
The output is a starting vocabulary, not an analysis. Treat it that way.
Move two: Human review against original text
The researcher reads the original transcript - the full transcript, not the LLM's summary of it - and reviews each candidate code against the quote that generated it. The question is not "is this label accurate?" The question is "does this label capture what this participant actually meant, given everything else I know about this interview?"
Some codes get confirmed. Some get rewritten. Some get discarded. Some transcripts reveal codes the LLM missed entirely - not because the LLM failed, but because the signal was in what the participant did not say, or in how a topic was avoided.
This step cannot be shortcut. If the researcher is reviewing LLM codes without having read the transcript, they are validating pattern matching, not doing analysis.
Move three: Human synthesis into themes
The researcher collapses codes into themes. This is a judgment call about what is structural versus incidental, what is a surface complaint versus a root cause, what appears in multiple interviews versus what is one participant's particular frame.
An LLM can surface candidate groupings. It cannot make the call that a theme is worth building around, because that call requires knowing the product context, the participant selection, what questions were asked and how, and what the team already knows. None of that is in the transcript.
Comparison: three approaches to interview coding
| Dimension | Fully human coding | Fully LLM coding | Hybrid (LLM first, human validates) |
|---|---|---|---|
| Speed | Slow - hours per transcript | Fast - seconds per transcript | Moderate - human review adds time back |
| Coverage | Misses themes when researcher is fatigued or confirmation-biased | Consistent coverage, no fatigue | High coverage with human interpretation check |
| Cultural register | High - researcher brings context | None - LLM works from translated or surface text | High - human validation step restores register |
| Risk of false confidence | Low - researcher knows what they read | High - polished output looks authoritative | Medium - depends on whether human actually reads original |
| Synthesis quality | High - researcher builds themes with full context | Low - theme groupings are pattern-matched, not interpreted | High - synthesis stays with the human |
| Scales to large transcript sets | No - becomes a bottleneck | Yes - unlimited scale | Partial - scales LLM pass, human review remains the constraint |
| Appropriate for | Small studies, culturally sensitive research | Exploratory scoping, very low-stakes pattern detection | Most production research with time pressure |
The table above makes hybrid coding look like the obvious answer. It is - but only if the human review step is real. A hybrid workflow where the researcher skims the LLM codes without reading the transcript is not hybrid. It is fully LLM coding with extra steps.
The uncomfortable position
The risk of AI-assisted coding is not that the LLM gets labels wrong.
The risk is that the researcher stops reading the transcript.
LLM output is authoritative in its presentation. It uses complete sentences. It has structure. It does not feel like a draft - it feels like an answer. When a researcher opens a transcript that already has clean, confident codes attached to it, the psychological pull is to review rather than read. Review is faster. Review feels responsible. Review is not the same as reading.
Reading a transcript is the moment analysis begins. You are not retrieving information. You are forming a perspective on what a participant experienced. That perspective is what you bring to the codes. Without it, you are a fact-checker for someone else's interpretation, and that someone else has never spoken to a user in their life.
The teams that use hybrid coding well treat the LLM output as a prompt, not a product. They look at a code and think: is this what I would have said if I had read this transcript without any scaffold? Sometimes the answer is yes. The code stands. Sometimes the answer is: the LLM saw the surface, and I see something underneath it. That is where the insight lives.
The cultural register gap
Language carries meaning that does not survive literal translation. Register - the social and emotional weight of how something is said - is not in the transcript. It is in the conversation.
An interview conducted in Tamil and translated to English for analysis loses register at the translation step. An LLM coding the English translation works from material that has already been interpreted once. The LLM is doing second-order interpretation on a first-order interpretation that may have already dropped the most important signal.
This is not a technology problem. It is a research design problem. And it is one that AI coding makes invisible, because the output looks exactly the same whether the underlying register was preserved or not.
The multilingual research pattern described above makes this visible by building the validation step around the original audio and transcript, not the translated version the LLM coded against. That is a design decision, not a feature of the tool. The team decided to preserve the register gap as a visible problem rather than letting the LLM paper over it.
Most teams do not make that decision. They get a code list in the translation language and move on. The insight that required the original language to hear is gone.
Judgment turn
If you use an LLM to code transcripts you have not read yourself, you are doing pattern matching on someone else's reading. You are not doing research.
That is the position. It is not softened by the fact that the LLM is fast, or that your stakeholders want themes by Thursday, or that twelve transcripts is a lot of reading. Those are real constraints. They do not change what the output actually is.
The hybrid workflow described above is not a way to use AI comfortably. It is a way to use AI without deceiving yourself about what you are producing. The human review step is not a quality check on the LLM. It is the analysis. The LLM is scaffolding. You are the researcher.
The cost of getting this wrong is not a bad theme list. It is a roadmap built on a reading no human ever did, attributed to users who said something different than what the labels claim.
Related articles
- Why Most User Interview Synthesis Is Actually Confirmation Bias in Disguise
- The Difference Between a Finding and an Insight - and Why It Changes Your Roadmap
Related Articles
What is the primary risk of letting an LLM code interview transcripts before a researcher has read them?
Make the call in Reps and see how your reasoning holds up.
Make the call