Should I vibe code
Clean, assemble, publish, and package a recurring spoken-word podcast episode
Cleaning audio is scriptable. Publishing a feed on a schedule is where it becomes a commitment.
?
Their verdict, the Podcaster price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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 processing chain is achievable with existing tools. The publishing side means an RSS feed that podcast apps cache, so mistakes propagate and stick.
What actually breaks
not "if". the specific failures.
- The RSS feed, which is the actual distribution surface — every directory reads it, and a malformed one delists you everywhere at once
- Episode GUIDs, where regenerating them republishes your entire back catalogue to everyone's podcast app
- Loudness normalisation to broadcast targets, which is a specification rather than a volume slider
- Noise reduction and levelling, which sound fine on your headphones and terrible on a phone speaker in a car
- Enclosure URLs, which must keep resolving for years because apps re-download episodes from them
You refactor how episodes are stored and the GUIDs change with them, because they were derived from the file path. Every podcast app treats a changed GUID as a new episode. Overnight, four hundred subscribers get sixty-one notifications and their apps begin downloading your entire back catalogue on mobile data. There is no recall. The feed is correct now, in the sense that it validates, and the damage is entirely in the apps of people who trusted you enough to subscribe.
Is that you?
the verdict is a default, not a law
- GUIDs are stable, opaque and never derived from anything that can change
- You use an established feed library and validate against a real podcast validator
- Audio processing is a fixed chain you tested on phone speakers and car stereos
- Episode identifiers derive from filenames, URLs or ordering
- The feed is hand-assembled with string concatenation
- Enclosure URLs might change or expire
- You have not listened to the output on a phone speaker
If you build it anyway
the checklist, then the prompt that enforces it
- Generate a GUID once per episode, store it, and never recompute it. This is the single rule that prevents the worst outcome in this category.
- Build the feed with a library and validate it against a podcast feed validator in CI, not by eye.
- Keep enclosure URLs permanent and on a domain you control, because apps re-fetch them long after publication.
- Normalise loudness to a stated target rather than by ear, and check the result on a phone speaker before publishing.
- Keep the processing chain fixed and reversible: preserve the raw recording so a bad chain is not baked in permanently.
- Test the feed in at least three real podcast apps before announcing it. They disagree about optional fields.
Before you build podcast production and publishing, apply these and push back if I ask you to break them. 1. Generate an opaque GUID per episode once, store it permanently, and never derive it from a filename, URL, title or index. Tell me that changing GUIDs makes every podcast app treat old episodes as new, notifying and re- downloading the entire back catalogue, and that this cannot be undone. 2. Build the RSS feed with an established library and validate it against a podcast feed validator in CI. Do not assemble XML by string concatenation. 3. Keep enclosure URLs permanent and on a domain I control. Explain that apps re-fetch these for years and that a changed or expiring URL breaks episodes that were already downloaded. 4. Normalise loudness to an explicit target rather than by ear, and tell me what target you are using and why. 5. Preserve the original recording untouched. Every processing step must be reproducible from the raw file, so a bad noise-reduction setting is not permanent. 6. Before I publish, tell me to listen to the output on a phone speaker and in a car. Studio monitoring hides exactly the problems podcasts have. 7. Handle episode ordering, seasons and publication dates explicitly, and never let a re-publish change an existing episode's date. 8. Test the finished feed in at least three real podcast apps before announcing. 9. Out of scope unless I ask: dynamic ad insertion, private feeds, transcripts, chapters.
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
$38 a month is fair if publishing regularly, mostly for feed correctness and a processing chain that has been tested on real listening devices. The editing and assembly are approachable; the feed is where a mistake reaches every subscriber simultaneously and cannot be withdrawn.
$38/mo is cheaper than your weekend.
Own the feed URL and the media domain, and keep GUIDs stable — those three things are what let you change every other part of the stack without disturbing a single subscriber. Keep raw recordings archived separately from published audio.
Long-running open-source multitrack audio editor and useful implementation prior art.
Questions
Why are GUIDs so much more dangerous than other feed mistakes?
Because most feed errors are visible and fixable — a wrong description shows up wrong and you correct it. A changed GUID does its damage in other people's apps, immediately, to everyone at once. There is no mechanism to tell those apps it was a mistake, and the subscribers who suffer most are the ones with the largest back catalogue downloaded.
Is loudness normalisation really a specification?
Yes — there are published integrated loudness targets that streaming and podcast platforms normalise toward, measured over the whole programme rather than by peak. Mixing by ear produces episodes that are inconsistent with each other and get adjusted unpredictably by the listener's app, which is why the target matters more than the volume knob.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice