Should I vibe code
Generate show notes, articles, social posts, and transcripts from uploaded episodes
Backfilling 200 episodes into 200 articles is one button. Retracting a quote your guest never said is not.
?
Their verdict, the Studio 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
The pipeline is not in question. Whisper, a prompt chain and ffmpeg give you show notes, chapters, a newsletter draft and vertical clips, and Podsqueeze's entry already makes the case that the timestamped transcript is the durable artefact and every text asset is a cheap derivative of it — take that as read. Swell's own shape adds two things that change the calculus, and both are about volume rather than difficulty. It imports an RSS feed and backfills a whole catalogue, and it writes articles intended to be published for search. Put those together and the natural first run of your build is two hundred episodes through the same prompt overnight, producing two hundred pages that nobody has read, under your show's name, quoting your guests. Transcription is roughly 95% accurate on clean audio, which sounds fine until you notice that the words it drops are short ones — and a dropped "not" reverses a sentence that then appears as a pull quote attributed to a named person with their photograph next to it. Build the pipeline; it is a good weekend. Keep a human between it and the publish button, which is the part the product is not going to do for you either.
What actually breaks
not "if". the specific failures.
- Attribution, where transcription error meets summarisation: a dropped "not" reverses a guest's position, and the summariser confidently promotes it to a pull quote
- Speaker labels, which diarisation guesses and your article template then hardens into "X said" with no hedge anywhere in the chain
- The bulk backfill, which is simultaneously the best feature and the hazard — one run, a hundred pages live, nobody has read page one
- Search, when a hundred thin machine-written pages about your own episodes get classified as scaled content and take the rest of the site's rankings with them
- The per-episode chatbot, which is a public LLM endpoint on your domain with your API key behind it: your bill, your prompt, and a stranger's injection attempt
- Clip generation, which is ffmpeg right up until it is aspect ratios, burned-in captions, loudness normalisation and a crop that keeps a face in frame
- Music and third-party audio, licensed for the podcast and not necessarily for a thirty-second vertical clip reposted on three platforms
- Cost, quietly: transcription is the expensive step and re-running the catalogue because you changed a prompt pays for it twice
Is that you?
the verdict is a default, not a law
- Every generated asset is a draft that a person reads before it goes anywhere
- It is your show, your audio and guests who know you are publishing derived text
- The timestamped transcript is stored as the source of truth and every other artefact is regenerated from it rather than stored as the original
- The pipeline is wired straight into your CMS and publishes without a human in the loop
- You are about to backfill an entire back catalogue in a single unattended run
- The episodes contain music or third-party audio you licensed for a podcast and not for clips
- You are producing pages primarily to rank rather than to be read, which is a stated target of every search engine's spam policy
If you build it anyway
the checklist, then the prompt that enforces it
- Keep the word-level transcript as a committed file per episode and treat every article, thread and clip as regenerable output. Then a better model is a re-run rather than a re-purchase, and you always have the primary record to check a quote against.
- Never let a quote reach a published page without a timestamp link back into the audio. It costs almost nothing at generation time and it is the only way to settle an argument about what somebody actually said.
- Put the human gate between generation and publication, and make bulk mode generate drafts only. A backfill that publishes is the difference between a useful tool and an apology.
- Carry diarisation confidence through the pipeline and refuse to attribute a quote to a named speaker below your threshold. "A guest said" is worth publishing; a wrong name is not.
- Run the audio through loudness normalisation and check clip boundaries against sentence boundaries. Most bad clips are not bad picks, they are good picks cut two words early.
- Keep an inventory of what you have published and where, because the retraction path is per-platform and you will need it exactly once.
- Rate-limit and budget-cap any public chatbot endpoint per session and per day, and treat everything the user sends as hostile input to your prompt.
I am building a podcast repurposing pipeline: audio in, transcript, show notes, article,
social posts and clips out. Take these as constraints, and push back when I ask for the
thing they forbid.
1. The transcript is the artefact. Store word-level timestamps as a file per episode,
committed and versioned. Every other output is regenerated from it and is treated as
disposable. Do not design a schema where the summary is the primary record.
2. Nothing publishes automatically. Generation and publication are separate commands,
and bulk mode may only produce drafts. If I ask for a one-button backfill that goes
live, refuse and explain what two hundred unreviewed pages under my show's name costs.
3. Every quote in every generated asset carries the timestamp it came from, in the
output, not just internally. A quote without a timestamp is not allowed to ship.
4. Carry diarisation confidence end to end. Below a threshold I set, the output says
"a guest" rather than a name. Never let the writing model invent an attribution.
5. Add a verification pass: for each quoted sentence, check it appears verbatim in the
transcript at the claimed timestamp, and fail the asset if it does not.
6. Process the transcript for the specific failure of short-word dropout. Flag any
generated sentence whose sentiment is opposite to the surrounding transcript window
and make me look at it.
7. Build the retraction path before the publishing path: a record of what was generated
from which episode, published where, and a command that lists it back to me.
8. If there is a public chatbot per episode, cap tokens per session and per day, treat
user input as hostile, and never expose the raw prompt or the key. Budget alarm first,
chatbot second.
9. Clip cutting respects sentence boundaries from the transcript, not fixed durations,
and applies loudness normalisation before export.
10. Out of scope unless I ask: publishing integrations, scheduling, multi-tenant
accounts and anything that touches an episode I do not own the rights to.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
You have a back catalogue and no appetite for the plumbing. Swell's Studio tier is $29 a month for 300 minutes of transcription, Agency is $49 for 600, and there is pay-as-you-go at $8.99 per hour — which for a weekly show is roughly the cost of the transcription alone if you were paying an API for it. The honest comparison is not build versus buy, it is build versus the two evenings you will spend on ffmpeg flags. If you enjoy those evenings, build it. If you have a publishing schedule, do not.
$29/mo is cheaper than your weekend.
One directory per episode: the audio, the word-level transcript as JSON, and the generated assets as Markdown next to it. That folder is the whole project and it opens in a text editor in ten years. The prompts belong in the repository too, because a show note style is a prompt plus a model version and losing either one means the next episode does not match the last hundred. What the exit plan cannot cover is anything already published — which is the argument for the human gate rather than a better export.
Local speech-to-text, which keeps the episode audio and the transcription bill on your own machine.
Word-level timestamps and speaker diarisation, which is exactly the layer the clip cutting and quote attribution depend on.
Questions
How is this different from the Podsqueeze and Castmagic entries?
Those are about the pipeline and where its output should live. Swell's distinguishing features are the RSS backfill and the SEO article — it is sold on doing your entire catalogue at once and publishing the result for search. That shifts the risk from "the show notes are mediocre" to "a hundred pages went live overnight quoting people by name". Same code, a different button, and the button is what this entry is about.
Is a 5% transcription error rate really a problem for show notes?
For show notes, no. For quotes, yes, because the errors are not randomly distributed across words. Short function words are what get dropped or substituted, and "not", "never" and "don't" are short function words. A summariser reading a transcript with a missing negation does not hesitate — it writes the confident opposite of what the guest said and puts their name in front of it. Verifying that every published quote appears verbatim in the transcript at its timestamp costs a few lines and removes the whole class of failure.
Is Swell AI still actively developed?
It is operating and the pricing page is live, but the marketing copy is showing its age — the feature list still advertises "unlimited GPT-3.5 writing" and the headline statistics count words written in 2023. Read that as a product in maintenance rather than one racing you on features, which cuts both ways: less risk that a subscription is about to change under you, and less reason to assume the hosted version is meaningfully ahead of what you would build.
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.
Cleaning audio is scriptable. Publishing a feed on a schedule is where it becomes a commitment.
Loudness normalisation is a well-specified standard and ffmpeg already implements it.
Transcript to clips and quotes is a prompt chain over Whisper output. Very reachable.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice