There's a question teachers carry around and don't talk about much. Am I actually good at this? Student results have a dozen confounding variables between your teaching and their grades. Lesson observations can be rationalised as a performance you give once a term. Anonymous feedback may only be telling you whether students like you, not whether you're teaching well. Liking someone doesn't make them a good teacher.
Katie Parrott wrote about her version of this: the permanent assumption that she's about to be fired, regardless of how many positive reviews she gets. She fed her performance data to AI and found she was driving a third of her publication's traffic with a fifth of the content. The numbers said she was good at her job. She'd never believed it from a person.
That resonated with me. I wanted something like that for teaching. I didn't have publication analytics or performance metrics, so I decided to start recording my lessons. A DJI clip-on mic, pressed record at the start of each class, forgot about it. Seventy-six recordings over ten weeks, taking up 24 gigabytes of storage. I figured that was close enough.
Recording: optimise for the thing that'll make you quit
I chose a DJI wireless lapel mic for one reason: it was easy. Clip it on, press record, forget about it. The battery lasts about 8 hours of teaching. I wasn't optimising for audio quality or transcription accuracy. I was optimising for the thing that would make me stop doing it if it became annoying. I'd tried recording lessons before and quit within a week because the setup was too fiddly.
This worked. I recorded 76 files and 30 lessons over ten weeks without thinking about it much. Then I plugged the mic in to download them and found two problems.
The first was storage. DJI mics record WAV files. Seventy-six of them took up 22 gigabytes. The second was naming. Every file was labelled something like DJI_20260204_0943. Seventy-six of these, and I couldn't tell you which one was Year 12 TOK on a Tuesday and which was English B HL on a Thursday.
The pipeline
The recordings sat on the mic for weeks. What made me start was a piece of anonymous class feedback. One of my students wrote that they'd be interested to learn what I'd found from the lesson recordings they'd allowed me to make. It struck me that I was essentially conducting research and that sharing the results wasn't just the right thing to do, it's basic research ethics. Which meant I actually had to process the data. I started thinking about how to do that without clicking on 76 files, listening to the first three minutes of each to identify the lesson, renaming it by hand, then converting it.
The files were stamped with creation dates. I had my teaching schedule. I gave both to Claude Code and asked it to cross-reference the timestamps against my timetable and rename every file to the date and class. It took about three minutes.
Then it batch-converted all 76 WAV files to MP3 by installing FFmpeg. Storage dropped from 24 gigabytes to several hundred megabytes. Another few minutes since this was done by parallel agents.
For transcription I used three different services: ElevenLabs Scribe, Gemini, and OpenAI Whisper. I did this deliberately because each model handles transcription differently. ElevenLabs produces one large block of text with no speaker identification. Gemini, processing the raw audio rather than a transcript, picks up tone, pauses, and can estimate who is speaking. Whisper gives a different text output again. Having three versions of the same lesson let me triangulate data when the numbers didn't agree.
The final step was coding every question I asked across all thirty lessons. I built a framework classifying questions into three cognitive demand levels: D1 (recall and identify), D2 (explain, apply, analyze), and D3 (evaluate, create, transfer). The coding tracked what happened after each question: whether a student responded, whether I rephrased, whether I answered my own question before anyone could. The framework drew on Bloom's taxonomy, classroom discourse analysis, and questioning typologies I'd studied during my master's. The AI coded all 702 questions against it. From plugging in the mic to having an organised, coded dataset, the whole thing took roughly ninety minutes.
The part where the work actually starts
The dataset looked convincing. Clean tables, specific percentages, neat categories. Teacher talk time came back at 60%. My radar went off.
The mic was clipped to my lapel, so of course it captured more of me than my students. The transcript had no way to represent silence, so quiet thinking time, the gaps where students were reading or writing or processing, simply vanished from the data. The AI had applied a perfectly reasonable method to the information it had. The information was incomplete.
I couldn't re-read 176,000 words of transcripts. I could skim 700 coded questions in fifteen minutes because I was the one who spoke them. If something looked wrong I could spot-check its provenance: which transcript did it come from, what was the surrounding context, does the cognitive level assignment match what I remember asking? Most of the coding was right. Some of it wasn't, and the errors weren't random. They clustered around questions where the phrasing sounded evaluative but the expected answer was actually recall. "Do you agree with Sandel here?" sounds like D3 until you realise the students had just read a passage that explicitly told them what to think. The AI couldn't know that. I could, because I was in the room.
The teacher talk problem I solved by running the same lessons through Gemini using the raw audio files instead of transcripts. Gemini could hear the silence. It could estimate the proportion of student voice to teacher voice to dead air. The number came back differently: closer to 42% teacher talk, not 60%. Two methods, same lessons, meaningfully different findings. The transcript analysis wasn't wrong exactly. It was measuring something different from what I thought it was measuring.
What the data showed
The findings I set out to explore were about questioning style and teacher talk. The one I actually keep thinking about is that across two months of lessons, twenty-four times, I said "Cool. Cool, cool cool."
The pattern is always the same. I do it when transitioning between activities. I don't have a clean bridge from one task to the next, and "cool, cool, cool" is what I blurt out while my brain catches up. It is also, I suspect, a product of watching too much Community in my twenties, seeing as I appear to have adopted Troy and Abed's catchphrase as professional vocabulary.
You cannot see this kind of thing from inside your own lesson. I doubt even a coach watching you teach would write down "Cool, cool, cool x 24." You need something dispassionate to read your own words back to you before a habit like that becomes visible. I also say "um" 618 times across the dataset, "right?" 238 times, and "you know" 282 times. I ask a content question every two minutes on average and wait 5.9 seconds for an answer, which is more than I expected.
There were heavier findings too. I teach TOK and English B as two measurably different people: different questioning patterns, different response to silence, different sentence construction. I identified six measurable things to work on.
The cool cool cool finding was the most useful, because it told me something true that I would never have guessed on my own.
The dark factory
Simon Willison described something on Lenny's podcast that captures what this project actually was. He called it the dark factory: in manufacturing, there are factories where robots work with the lights off because they don't need light. The machines run autonomously. The human's role isn't operating the machinery anymore. It's quality-controlling what comes out.
The AI did the factory work. It renamed, converted, transcribed, and coded faster than I could have done any single one of those tasks. The output arrived looking finished. My job was to figure out whether I could trust it, and the only way to do that was to think. Evaluative thinking. Triangulating data across methods. Developing heuristics for checking a product I couldn't verify line by line. Sitting at my desk staring at a spreadsheet of 700 coded questions, trying to work out whether the AI's classification of "evaluative" versus "analytical" matched mine.
I know most people haven't grasped this yet about working with AI. The grunt work collapses. What replaces it is cerebral. You will get weeks of work handed to you in an afternoon or less and your job is to think hard enough to trust it. You will absolutely think hard. You'll start looking at weeks of data at 9am and by noon your brain is fried. It is a corollary of the recent HBR paper.
If you want to try this
Check your school's policy on recording in the classroom before you start. Get that sorted before you clip on a mic.
The hardware is a clip-on wireless mic. I used a DJI, but anything that records to a file and lasts a full day on battery will work. Optimise for the thing that'll make you quit: if the setup takes more than ten seconds per lesson, you won't do it past week two.
Once you have recordings, you give them to Claude Code or Cowork along with your timetable and ask it to rename, convert, and transcribe them. That's one prompt. The processing that took me ninety minutes across 76 files could be done in a single sitting.
The analysis is where your judgment matters. I focused on questioning partly because I was curious about it and partly because a lapel mic picks up your voice far better than your students'. I didn't want the analysis to rely heavily on student responses that might not be accurately transcribed or might not even be audible. Questioning patterns are almost entirely in the teacher's voice, which made them the most reliable thing to measure.
You don't have to look at questioning. You could ask it to track how often you use student names, or how you open and close lessons, or how much time you spend on instructions versus activity. The framework should come from whatever you've been curious about in your own teaching, and whatever your recording setup can actually capture well. Tell the AI what you want to measure and it will propose a way to code it. Your job is to decide whether the coding makes sense and whether you trust the output.
The prompts are simple. The hard part is knowing what to ask for and knowing whether to trust what comes back. Everything in between is factory work.
If you use Claude Code for this and get stuck, send me a message on LinkedIn. I'm happy to help.