Amit Kvint ES

5 September 2026

'I Taught Claude to Code My Interviews With Me, Not For Me: AI-Assisted Qualitative Coding in ATLAS.ti'

Want to talk about this essay? Email me: · or message me on LinkedIn

Somewhere around the fourth hour of coding an interview transcript, every qualitative researcher has the same thought: a machine should be helping with this.

And somewhere around the fourth minute of trying an AI tool that promises to do exactly that, most of us have the opposite thought: not like this.

The tools that "automatically code your data" produce something that looks like analysis the way a stock photo looks like your family. The format is right, but nobody in the picture knows you.

I have spent the past months conducting and coding interviews as a research assistant to Dr. Gal Levy at the Open University of Israel, on a project about Mizrahi identity among young American Jews. The coding happens in ATLAS.ti, the qualitative data analysis software, against a codebook that has grown to nearly four hundred codes. Recently, ATLAS.ti opened its desktop application to AI assistants through the Model Context Protocol (MCP). That means an assistant like Claude can now see the actual project: the live codebook, the real interview transcripts, every quotation with its exact character positions. And it can write into it.

That changes the question. It is no longer "can AI code my data?" but "what should the division of labor be?"

After several sessions of trial, error, and one lost afternoon of connection troubleshooting, I ended up building what Claude calls a skill: a saved set of working instructions that loads in every session. I think the answer we converged on, a human-in-the-loop workflow for AI-assisted qualitative coding, is worth sharing, because it applies far beyond academic research.

The coding loop: the AI suggests, the human decides, the AI executes

The workflow the skill encodes is a loop with three beats, and the order of the beats is everything.

First, Claude reads the passage and proposes a code. But the proposal has rules. It must come from the live codebook, verified in the moment, never from memory. It must arrive with the code's actual definition and an honest argument for the fit, including the argument against: my instructions explicitly require Claude to name the weaknesses of its own suggestion and to offer the best alternative, so that saying no costs me nothing. Every suggestion is labeled either EXISTING or NEW, and a new code can never be created without my explicit approval, because a codebook that grows without discipline stops being an instrument.

Second, I decide. Use it, skip it, split it into two segments, change the boundary, or reframe it. That last one happens more often than I expected. In one session I pushed back that a passage about legitimacy-vetting was about Jewish normativity rather than Ashkenazi normativity. The skill instructs Claude to treat a reframing like that as a new search query: it went back into the codebook, searched on my terms rather than its own, and surfaced an existing code neither of us had considered. A better fit than its original suggestion.

The disagreement made the analysis sharper. That is what a colleague does. It is not what an automation does.

Third, and only after my decision, Claude writes: it creates the quotation at the exact character span, attaches the approved codes, and confirms what it wrote. Nothing speculative ever touches the project. When we lost the connection mid-session, twice, the first thing the skill demands on reconnection is re-verification of the project's state before a single further write.

Three layers: the Claude skill, the coding brief and the case-status file

The part I find most transferable is not the loop but the way knowledge is stored. There are three layers, and each holds a different kind of knowledge.

The skill holds the method: the loop above, the verification protocol, the honesty requirements. It contains nothing about my study, which means it will work unchanged on my next one.

The coding brief holds the study: scope decisions already made, how dense the coding should be, which situations get which code. It is a living document. After enough sessions accumulate new rulings, Claude drafts the next version and I review it. Mine is on version four; version five is already overdue in the best way.

The case-status file holds the data trail: per-interview progress, decisions pending, and, crucially, the passages deliberately left uncoded, with their exact positions. Uncoded-by-decision is information. It is also the cheapest information to lose and the most annoying to reconstruct.

The machine reads all three at the start of every session and is bound by them, with a clear hierarchy: the study documents outrank the skill. Lessons learned flow downward into the documents through drafts that I approve. Never silently into the tool itself.

AI-assisted qualitative analysis beyond academia: user research, churn, surveys

Strip away the ATLAS.ti specifics and what remains is a general template for AI-assisted qualitative analysis. And qualitative data is everywhere companies are currently drowning.

Customer discovery and user research interviews. Product teams record dozens of conversations and code them, if at all, into hasty themes in a spreadsheet. The same loop applies directly: a maintained codebook of customer needs and pain points, an assistant that proposes tags against it with honest rationales, a researcher who decides, and a data trail that shows which passages were deliberately set aside.

Churn and win-loss analysis. The discipline of "one idea per segment" and "track who is actually speaking" matters enormously here. The difference between a customer's own frustration and their report of a colleague's frustration is the difference between a signal and a rumor.

Open-ended survey responses and A/B test feedback. Quantitative tests tell you which variant won; the free-text responses tell you why, and they are routinely ignored because nobody has time to code five thousand comments. A suggest-decide-write loop with a stable codebook turns that from an unaffordable luxury into an afternoon, while keeping a human's judgment on every category that gets created.

The commercial version of the brief is a research playbook: your interview guide's intent, your taxonomy's scope rules, the decisions your team has already made about edge cases. Most teams carry this knowledge in one senior researcher's head. Writing it down so that a machine can be bound by it has a side effect that may be the real prize: it forces the team to actually make those decisions.

What to copy: the human-in-the-loop contract

Not the tool. The contract.

The assistant proposes with verified evidence and honest uncertainty. The human owns every decision that shapes the instrument. The assistant executes exactly what was decided and documents what it did. And the knowledge lives in reviewable documents, never in silent memory.

Every part of that contract exists because its absence produced a real error in a real session.

AI coding of qualitative data done badly is fast and worthless. Done with this contract, it is still fast (my last two interview sections took a fraction of the usual time) and the analysis is, if anything, more rigorous than what I produced alone, because every code application now arrives with a definition-grounded argument I had to consciously accept or reject.

The machine did not replace my judgment. It put my judgment on the record.

The setup, for anyone who wants to reproduce it

The same pattern works with any qualitative analysis tool that exposes its projects to an assistant.

qualitative-researchatlas-tiai-assisted-codingbuilding-with-ai

← Back