Ask a room of qualitative methodologists whether AI belongs in coding, and the objection that comes back first is rarely "the technology isn't good enough yet." It's something closer to: coding is where the interpretation happens, and interpretation is supposed to be the researcher's. If a model is quietly deciding which passages mean what, the analysis stops being reflexive — it becomes something the researcher signed off on without actually doing. That's a methodological objection, not a technophobic one, and it deserves to be treated as correct rather than talked around.
The worry is the methodology working as intended
Reflexivity in qualitative research isn't a courtesy paragraph in the methods section. It's the mechanism by which a coding scheme earns its claim to credibility — the researcher's positionality, the decisions made and reconsidered, the codes that got split or merged and why, are supposed to be visible and interrogable. That visibility is what lets a second reader, a supervisor, or a reviewer trace how a theme emerged from data rather than simply trusting that it did.
An AI system that proposes a code and applies it in the same motion breaks that chain at the exact point where it matters most. It's not that the suggestion is necessarily wrong — it's that "the model suggested it and I kept it" is a different epistemic claim than "I read this passage and decided it meant this." A dissertation committee, or a journal reviewer trained to ask "how did you get from data to theme," is entitled to ask which of those two things actually happened. Right now, most tools can't answer that question with anything more specific than "the AI helped."
What the record already shows
This isn't a fringe concern circulating on methodology Twitter. IRB guidance at a growing number of institutions now addresses AI tools explicitly, and the instruction is consistent: raw interview text should not be sent to a cloud-hosted model as a matter of course. A peer-reviewed paper at CHI 2026 — ChatQDA (arXiv:2602.18352) — makes the same point from the design-research side, arguing against routing verbatim transcripts through external LLM APIs and treating that boundary as a starting constraint for any AI-assisted qualitative tool, not an optional hardening step to add later.
Put those two sources together and a fairly narrow, defensible position falls out: if AI is going to touch coding at all, the transcript itself should never leave the researcher's machine to get there.
Conditional trust: why "it's local" doesn't settle the question
Here is the part that surprised even researchers building local-first tools. The ChatQDA study didn't stop at showing that on-device processing was technically feasible — it also asked participants how they felt about it, and found that keeping data on the machine didn't fully resolve their unease. The researchers named this conditional trust: participants still hedged, still asked follow-up questions, still wanted proof, even after being told nothing left their laptop. Local processing addressed the technical risk. It didn't automatically address the felt one.
That gap matters because it means "your data stays on your device" is a claim, and claims in a privacy policy are exactly the kind of thing qualitative researchers are trained to be skeptical of — they've spent their careers being told to distrust unverifiable assertions about what happened to a participant's words. A sentence in a FAQ doesn't behave differently just because the sentence is true.
What actually moves conditional trust toward confidence is verifiability, not disclosure. Concretely, that looks like a tool that keeps working with the network disconnected — not a "works offline" bullet point, but an app you can actually pull the plug on mid-session and watch continue functioning. It looks like a persistent, real-time indicator of network activity, so that if the tool ever does talk to the outside world, you see it happen rather than having to take someone's word that it didn't. Those are falsifiable claims a researcher can test in thirty seconds. "We take your privacy seriously" is not.
A checklist before AI touches your codebook
If you're deciding whether to bring AI assistance into a coding workflow for a specific study — not in the abstract, but for the project you're actually running — the following questions are a reasonable bar to hold any tool to, including ones not yet built:
- Does every AI suggestion sit in a rejectable state before it does anything? A code proposal, a theme cluster, a similarity match — none of it should be written into your project until you've actively accepted it. If accepting is the default and rejecting is the effort, it isn't really optional.
- Is every accept, reject, and edit logged, not just the final result? The coding scheme you end up with tells a committee what you concluded. The log of what the AI proposed and what you did with each proposal is what lets them evaluate how you concluded it.
- Can that log be exported in a form a committee or reviewer can actually read? An audit trail that only exists inside a proprietary database, inspectable by nobody but you, doesn't function as evidence. It has to leave the tool in a format someone else can open.
- Is the AI's reasoning legible, or is it just a label? "Suggested code: access barriers" is not the same thing as "suggested because this passage echoes language you coded as access barriers in interviews 3 and 9." The second gives you something to agree or disagree with. The first just gives you an output to rubber-stamp.
- Does the transcript itself ever leave the machine to generate that suggestion? If the answer is "yes, to a cloud API," everything above still matters, but it's now a separate disclosure your IRB protocol and consent language need to account for on its own terms.
None of these questions require rejecting AI assistance outright. They're closer to the standard you'd already apply to a very fast, occasionally overconfident research assistant: useful for surfacing candidates, not authorized to make the call, and expected to show their work when asked.
The cloud-API status quo isn't a scandal, but it is the current default
It's worth being precise about where the field actually stands, without turning this into a case against any particular vendor. NVivo's AI Assistant, MAXQDA's AI Assist, and ATLAS.ti's AI Coding are each, per their own public documentation, powered by an external API — commonly OpenAI's. That's not a hidden fact or a gotcha; it's how the major tools were built, and it reflects a reasonable engineering path: cloud models were further ahead than anything that could run locally when these features shipped. The point isn't that these teams did something wrong. It's that "AI-assisted coding" in qualitative software today generally means "your transcript, in some form, reaches a third-party server," and that's a fact worth knowing before you decide whether it's compatible with a given study's consent language and IRB protocol — not something to discover after the fact.
Where Sondera fits, honestly
We're building Sondera around the position argued above, because we think it's the only version of "AI-assisted coding" that survives a committee's questions. Every suggestion — a code, a theme cluster, a related quote — stays pending until you accept it. Every accept, reject, and edit writes to an audit trail you can export. Transcription and AI analysis run on-device, the app works with no network connection at all, and it shows a live indicator whenever it does talk to the network, so that claim is something you can watch rather than something you have to believe.
We're saying this plainly because the honest version of this post has to include it: Sondera isn't released. It's in development for macOS, with a beta planned for fall 2026, and none of the above is a promise about a shipping product yet — it's the design constraint we're building against. If you're deciding today whether AI belongs in your coding workflow, the checklist above will outlast whichever tool you apply it to, including this one.
Building toward AI-assisted coding you can actually defend to a committee.
Sondera is in development for macOS — beta fall 2026. Join the waitlist for early access and pricing.