Podcasts with AI

How AI helps with a podcast

Producing a podcast is much more than recording — planning, editing, transcription, show notes, clips for social. All of these eat up hours. AI dramatically shortens every "after the recording" stage, so you can focus on the content and the conversation.

Planning & preparation

• Research and topics: ask AI for angles and questions for the episode, and background on a guest.
• A conversation outline: a flexible skeleton of points — not a rigid script.
• Interview questions: AI suggests sharp questions based on the guest's background.

Audio editing

• Removing filler words ("uh," "um") and silences — automatically in AI-based editing tools.
• Improving voice quality — noise reduction, balancing, a "studio" feel from a home recording.
• Text-based editing — you edit the transcript, and the audio is cut accordingly. A game changer.

Transcription & show notes

A transcription model (like Whisper — see Multimodal) converts the episode into accurate text. From there AI easily generates:

• Show notes — a summary, key points, timestamps.
• A title and description optimized for search.
• Standout quotes for sharing.
• A full transcript — accessibility and SEO.

Distribution & repurposing

One episode = a lot of content. Turn it into spin-offs: short clips for social, a tweet/thread, a LinkedIn post, a blog article from the transcript, and a newsletter. It multiplies the reach of the same work.

Common mistakes

• Trusting the transcript blindly. Check names, technical terms and every number — those are where accuracy collapses.
• Over-editing. Removing every "uh" makes the conversation artificial. Keep it natural.
• Neglecting clips. The short clips are what bring new listeners. Invest in them.
• Audio quality. AI improves it, but a decent mic in the recording is worth more than any fix.

Recording remotely, which is where most episodes are lost

Almost every fixable disaster in independent podcasting happens at the recording stage, and almost always for the same reason: one side was captured through a call. A video-call recording gives you compressed audio, aggressive noise gating that clips the start of words, and a single mixed track you cannot separate afterwards. No enhancement tool recovers what the codec discarded.

The fix is local recording on each end, then upload — every remote-recording platform now does this, and several do it free. Each speaker's own machine captures their own microphone at full quality, and the files are combined afterwards. The call itself is only used for the conversation. This single change does more for how a show sounds than every processing tool put together.

Separate tracks also pay off in post-production: you can remove the host's chair creak without touching the guest's answer, filler removal works per speaker, and a clip generator can tell who is talking. Three minutes of setup that makes every later stage easier.

One last habit worth having: record thirty seconds of silence in the room before you start. Noise reduction works considerably better with a sample of what the noise is, and nobody ever has one when they need it.

Where the hours actually go

Before choosing tools it is worth knowing what you are buying back. A typical independent interview show, one host, one guest, forty-five minutes of finished audio, breaks down roughly like this: booking and scheduling the guest, half an hour to two hours of correspondence spread over a fortnight. Preparation and research, one to two hours. The recording itself, an hour including the setup and the small talk. Editing, anywhere from one hour to four depending on how much you cut. Show notes, titles and descriptions, thirty to sixty minutes. Clips and social posts, another hour. Publishing and distribution, twenty minutes.

That is somewhere between five and ten hours for forty-five minutes of audio, and the recording is the smallest piece of it. This is the single most useful thing to understand about podcast production: the thing that feels like the work is about ten per cent of the work. Everything else is preparation and post-production, and post-production is where these tools apply.

It also tells you where to spend first. Automating research saves an hour a fortnight. Automating transcription, show notes and clips saves two to three hours every single episode. If you only fix one stage, fix the one after the recording.

Text-based editing, and where it stops working

The genuine shift in podcast production over the past few years is editing audio by editing its transcript. You delete a sentence in a text document and the corresponding audio disappears. For anyone who has done this on a waveform, the difference is not incremental — a task that required finding the boundaries of a sentence by eye and ear becomes a task you can do while reading.

It works extremely well for structural edits: removing a tangent, cutting a question that went nowhere, reordering two segments, deleting the first ninety seconds where everyone was settling in. It also handles filler removal in bulk, and most tools now do that as a single toggle.

Where it stops working is anything that depends on how something sounds rather than what was said. A cut that reads perfectly on the page can land badly in the ear, because the two speakers were overlapping slightly, or because the removed sentence was carrying the breath before the next one. Three specific cases to watch:

• Crosstalk. When both people speak at once, the transcript flattens it into two sequential lines. Deleting one of them cuts audio that also contains the other voice, and you get a clipped, unnatural overlap.
• Breath and pacing. A speaker who pauses to think has a rhythm. Cutting every pause produces a delivery that sounds hurried and slightly inhuman, even though no words changed.
• Laughter and reactions. These often transcribe as nothing at all, so they are invisible in the text view and get removed as part of a larger cut without anyone noticing. They are frequently the warmest moments in the episode.

The practical rule: make structural cuts in the text, then listen to every edit point before exporting. Not the whole episode — just the seams. A forty-five minute episode with twelve cuts has twelve places that can sound wrong, and checking them takes five minutes.

Transcription: what actually breaks

Modern transcription is good enough that the remaining errors are concentrated and predictable, which makes them easy to check if you know where to look. Accuracy on ordinary conversational speech is high. Accuracy collapses in four specific places:

• Proper nouns. Your guest's name, their company, the products they mention. These are exactly the words that must be right, and exactly the ones a model has the least context for.
• Domain jargon. Any field has terms that sound like ordinary words. A transcript that renders a technical term as a plausible everyday phrase reads fluently and is wrong, which is worse than an obvious error.
• Numbers and units. Figures spoken aloud are ambiguous, and a transcript will commit to one reading. Percentages, dates, prices and version numbers all need eyes on them.
• Accents and poor audio. Accuracy degrades with a bad microphone, a room with echo, or a speaker the model has heard less of in training. This is uneven in a way that is worth knowing about rather than assuming away.

The fix is cheap and underused: most transcription tools accept a vocabulary list or prompt — a handful of terms, names and spellings supplied before the run. Feeding it your guest's name, their company and five or six terms you know will come up removes the majority of the errors that matter. It takes two minutes and it is the highest-return habit in this whole workflow.

After that, do not proofread the full transcript. Search it for the guest's name, the company names and every digit, check those, and move on. That is a ten-minute job that catches almost everything a listener or a search engine would hold against you.

Show notes people actually read

Ask a model to "write show notes for this episode" and you reliably get a competent, forgettable paragraph followed by five bullet points that restate the section headings. It is not wrong. It is also not something anyone reads, and it is instantly recognisable as generated.

What makes show notes useful is that they answer a specific question: should I spend forty-five minutes on this? That is a different task from summarising, and it needs to be asked for explicitly. Things worth requesting:

• The actual argument. What position does the guest take, and what would somebody who disagreed say? A summary that could describe any episode on the topic has failed.
• Two or three real quotes, verbatim, with timestamps — not paraphrases. A direct sentence in the guest's own voice does more than a paragraph of description.
• Timestamps for genuine chapter boundaries, not evenly spaced ones. If the conversation turned at eleven minutes and again at thirty-four, those are the marks.
• Every reference made. Books, papers, tools, people. Listeners look for these, they are tedious to collect by hand, and a model working from the transcript collects them perfectly.

That last item is worth the whole exercise on its own. A linked list of everything mentioned is the part of show notes that reliably gets used, and it is the part most shows skip because assembling it manually is dull.

Why most automatically generated clips are bad

Clip generators find moments that look promising by proxy — a spike in volume, a change in pace, a sentence with strong sentiment. Those proxies correlate weakly with what makes a clip work, which is that it is comprehensible to somebody who has no idea what came before it.

A clip works when it contains a complete thought, opens on something that creates a question, and does not depend on a setup the viewer did not hear. Most auto-selected clips fail on the third condition: they are genuinely the liveliest thirty seconds of the episode, and they are unintelligible in isolation because the guest is reacting to something said two minutes earlier.

The workable process is to use the tool for recall and a human for judgement. Have it surface ten candidates, then discard the ones that need context, and for the survivors check that the first three seconds would stop someone scrolling. Three good clips beat ten mediocre ones, and the failure mode of automation here is producing ten.

One more thing worth doing by hand: burned-in captions. Most of this material is watched with the sound off, the captions come straight from a transcript you have already corrected, and a clip with an error in its subtitle is the version of your show that travels furthest.

Synthetic voice: useful, and where the line is

Generated voice has obvious uses around the edges of a show — a consistent intro and outro read, a correction dropped into an old episode without re-recording, an ad read you would otherwise book studio time for, or a second-language version of an episode. In all of those the synthetic voice is doing a job nobody was doing well by hand.

Two places to be careful. The first is licensing: cloning a voice requires that person's consent, including your co-host's and including your own if you are working through a platform whose terms you have not read. The second is disclosure. Using a synthetic voice for narration is unremarkable. Using one to put words into the mouth of a real person, in a medium whose entire premise is that you are hearing someone talk, is a different thing — and the fact that it is technically easy does not make it a smaller decision. If a listener would be surprised to learn a segment was not spoken, say so in the episode.

What none of this does

It does not make the conversation good. A podcast lives or dies on whether the host asks something the guest has not been asked fifty times, and no amount of preparation from a model produces that — the questions it suggests are, by construction, the questions everyone asks, because those are the ones in the training data. Use them as a floor to clear, not a script.

It does not book guests, and it does not build the relationship that makes a good guest say yes. It does not tell you whether an episode is worth publishing. And it does not fix a bad recording: noise reduction and enhancement have improved enormously, but a decent microphone in a quiet room still beats every repair tool, and the gap has not closed.

A realistic end-to-end workflow

1. Before. Background on the guest into a document, generate a list of standard questions, then deliberately write two of your own that are not on it. Prepare the vocabulary list for transcription while the guest's details are in front of you.
2. Record. Separate tracks per speaker if the platform allows — it makes every later step easier. Note the timestamp of anything that felt like a highlight; it takes a second and saves a search.
3. Transcribe with the vocabulary list attached, then spot-check names, terms and numbers. Ten minutes.
4. Edit in the text. Structural cuts, filler removal, then listen to the seams only.
5. Generate the assets from the corrected transcript in one pass: show notes, chapters, quotes, the reference list, title options, the description. One transcript, one prompt, all of it.
6. Clips. Ten candidates, keep three, caption them from the corrected transcript.
7. Publish, and post the transcript as a page. It is accessible, it is indexable, and it costs nothing since you already have it.

Realistically this takes the post-production side from three or four hours to about ninety minutes, most of which is the checking rather than the generating. That is the honest number. It is a substantial saving and it is not the tenfold change these tools are usually sold with.

Is it actually helping?

Worth checking, because it is easy to add five tools and a subscription and end up spending the saved time on managing them. Two numbers tell you most of it: hours from recording to published, and how many episodes you shipped last month versus the month before. If the first went down and the second went up, the workflow is working.

If the first went down and the second did not move, the bottleneck was never production — it is booking, or it is deciding what to make, and no editing tool touches either. That is a useful thing to discover early, because it is also the more common case.