Should I vibe code
Transform an episode into show notes, chapters, quotes, and short text assets
The show notes are disposable. The timestamped transcript is the archive, and it belongs in your repo.
?
Their verdict, the Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
This is a transcript with prompts attached, and for one show that really is the whole product. Whisper gives you word-level timing, an LLM turns that into a summary, chapters, quotes and a newsletter draft, ffmpeg burns an audiogram, and a template writes the episode page. Nothing leaves your machine that you have not read. What is worth getting right is which artefact you treat as the output. Podsqueeze bills by minutes because transcription is the expensive step, and that is a hint: the transcript is the durable thing and every text asset is a cheap, regenerable derivative of it. Build it so the timestamped transcript lands as a committed file in your own repository and the show notes are produced from that file on demand, and you have something that outlives your prompts, your model choice and your interest in the project. Build it the other way round — output straight into a database, transcripts thrown away after the summary — and you will re-pay for transcription every time you change your mind about the format.
What actually breaks
not "if". the specific failures.
- Proper nouns, which is where transcription accuracy collapses and also exactly which words end up in a pull quote — names, companies, product names, numbers
- The review step, quietly, because the entire appeal of the tool is that you stop reading the output and it will be several episodes before you notice
- A published RSS description, which propagates to Apple, Spotify and every aggregator within hours and is corrected in your host but not in their caches
- Chapter boundaries, which an LLM places where the topic sounds like it changed rather than where it did, so long episodes get chapters that are confidently wrong
- The transcript, if it was treated as an intermediate file and deleted after the summary — that is the expensive artefact and the only one you cannot regenerate for free
- Prompt rot, when a model update changes the tone of every asset and episode 41 reads like a different show from episode 40
- Cost, if it runs unattended on long files with retries, because minutes are the unit that actually bills
- Guest audio, which is somebody else's voice going to a hosted transcription API you may not have mentioned when you asked them to record
Is that you?
the verdict is a default, not a law
- It is your own show and you read the output before anything is published
- The timestamped transcript is written to a file you keep, and every asset is regenerated from it
- Transcription runs locally, or the guest was told which service the recording goes to
- Nothing auto-posts — the last step is always a human pressing publish
- It publishes directly to your feed, your site or a social account without a review step
- You are running it as a service over other people's episodes, which turns guest recordings into your retention problem
- Quotes are lifted verbatim from the transcript and attributed by name without checking them against the audio
- Transcripts are treated as scratch files and deleted after the summary
If you build it anyway
the checklist, then the prompt that enforces it
- Write the timestamped transcript to disk first, as a plain file in your repository, and make every downstream asset a pure function of that file. Re-running the formatting should never re-run the transcription.
- Keep a human in the loop on anything that publishes. This is one line of code and it is the only real safety mechanism in the entire pipeline.
- Verify every quote against the transcript timestamps and link the quote to its timecode, so checking it against the audio takes five seconds rather than five minutes.
- Give the model a glossary of recurring names, companies and jargon from your show. Most of the embarrassing errors are proper nouns, and most of those are fixable with a word list.
- Record which model and prompt version produced each asset, so that a change in house style is traceable to a change you made rather than a mystery.
- Cap spend per run and per month, and put a length guard on inputs. A retry loop over a three-hour file is the only way this build costs real money.
- Decide where guest audio goes before the first episode and tell your guests. 'It goes to a hosted API' is a fine answer; not having one is not.
- Diff generated show notes against the previous episode's before publishing the first few, which is the fastest way to notice that a model update changed your voice.
I want to turn a podcast episode into show notes, chapters, quotes and social
assets. Treat the transcript as the product and everything else as a derived
view. Build in this order.
1. Transcribe first and write the result to disk as a timestamped, word-level
file in my repository. Never hold the transcript only in memory or only in
a database row.
2. Make every asset a pure function of that file. Re-running the formatting
must never re-run transcription — that is where the cost is.
3. Take a glossary file of recurring names, companies and jargon, and bias the
transcription with it. Proper nouns are where accuracy actually fails.
4. Every generated quote carries the timecode it came from, so I can check it
against the audio in one click. Refuse to emit an unsourced quote.
5. Nothing publishes. Write files to an output directory for me to review; if
I ask for auto-posting to a feed, a site or a social account, push back and
explain that an unreviewed hallucinated statistic ships with my name on it.
6. Record the model identifier and the prompt version alongside every asset, so
a change in tone is attributable.
7. Put a hard cap on spend per run and on input length, and fail rather than
retry indefinitely on a long file.
8. Never overwrite or re-encode the source audio. Read-only on inputs, always.
9. If transcription goes to a hosted API, say so in the README and print it at
run time, because guest audio is somebody else's voice.
10. Make the output diffable — plain text or Markdown in a directory — so I can
see what changed between episodes when a model updates underneath me.
11. Out of scope unless I ask: audio editing, publishing, hosting, analytics,
and anything that runs on a schedule without me watching.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If you have several shows or you are doing this for clients. Nine dollars a month for two hours of audio is not the sort of number you save money against by writing code, and the paid tiers buy queueing, a UI a producer can use and clip rendering you do not have to babysit. For one podcast and a moderate appetite for scripting, the homemade version is genuinely competitive and you keep the transcripts.
$8.99/mo is cheaper than your weekend.
There is nothing to exit if the transcripts are files. Keep one directory per episode holding the audio, the word-level transcript and the generated assets as Markdown, and the entire archive is greppable, portable and readable in twenty years without your code. The scenario worth avoiding is the opposite one: assets in a database, transcripts discarded, and a re-transcription bill the day you decide the show notes should look different.
Local speech recognition with word-level timestamps, which is the expensive step of this pipeline running on your own machine.
Whisper with forced alignment and speaker diarisation, so quotes get accurate timecodes and the right name attached.
Questions
Castmagic is DEMO ONLY and this is SHIP IT. They look like the same product.
They overlap, and the difference is what each entry is warning about. Castmagic's is about accuracy and attribution — misheard proper nouns, wrong speaker on a quote — which is a judgement problem you cannot fully engineer away. This one is about architecture: treat the transcript as the artefact, keep a human on the publish button, and the remaining failure is a bad draft you delete. If you plan to auto-publish, read the Castmagic entry and take its verdict instead of this one.
What does the review step actually protect against?
Fabricated specifics. A summariser working from a transcript with a garbled proper noun will produce a fluent sentence containing a company that was never mentioned or a figure nobody said, and it will read perfectly. The transcript errors are visible if you look; the confident smoothing over them is not. Ten seconds of reading per episode removes the entire category.
Is running Whisper locally worth the trouble versus an API?
For guest audio, often yes — not for cost, but because it answers a question you would otherwise have to raise with the guest. Locally, the recording never leaves your machine. Via an API, it does, and the honest thing is to say so when you ask someone to record. Neither is wrong. Only the unexamined version is.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Transcript to clips and quotes is a prompt chain over Whisper output. Very reachable.
Every episode you have shipped is thirty minutes of clean, isolated reference audio for cloning your guest's voice.
Loudness normalisation is a well-specified standard and ffmpeg already implements it.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice