Should I vibe code
Text-based audio and video editor with transcription and AI tools
Text-based editing is a beautiful idea sitting on top of very fiddly media plumbing.
?
Their verdict, the Hobbyist 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
Transcribe, align, cut by words — each step has a library. Making the round trip lossless and fast across long recordings is the part that takes a team.
What actually breaks
not "if". the specific failures.
- Word-level alignment, which is the whole premise — deleting a word must cut exactly the right audio, including its breath and its silence
- Cuts that land mid-phoneme, producing a click or a clipped consonant that a waveform editor would have shown you
- Multitrack sync, where cutting one speaker's words has to move everyone else's timeline identically
- Video, since a text edit implies a frame-accurate cut and a jump that needs concealing
- Re-transcription after an edit, which can renumber every alignment you were relying on
You delete a filler word and the sentence closes up cleanly in the text. In the audio it does not: the alignment put the boundary two hundred milliseconds late, so the cut takes the start of the next word and leaves a fragment of the deleted one. Played alone the glitch is obvious. Played inside a two-hour episode, it is one of ninety such edits, and you find them the way your listeners do — one at a time, while doing something else.
Is that you?
the verdict is a default, not a law
- It is transcript-driven navigation and a real editor performs the cuts
- Cuts snap to silence rather than to alignment boundaries
- You listen to every edit point before exporting
- Cuts are made purely on alignment timestamps with no snapping or crossfade
- It edits video where a jump cut needs concealing
- Multitrack timelines are not kept in sync by construction
- Nobody listens to the result before publication
If you build it anyway
the checklist, then the prompt that enforces it
- Snap every cut to the nearest silence within a window rather than to the raw alignment boundary. Alignment is approximate; silence is not.
- Apply a short crossfade at every join. It is a few milliseconds and it removes almost all audible clicks.
- Keep the edit as a non-destructive decision list over the original media, so a bad cut is adjustable rather than baked in.
- Preserve alignment ids across re-transcription, or re-derive edits from timestamps rather than word indices.
- For multitrack, apply cuts to the timeline rather than per track, so speakers cannot drift apart.
- Make it trivial to audition each edit point, and require it before export.
Before you build a text-based audio editor, apply these and push back if I ask you to break them. 1. Tell me that word-level alignment is approximate, typically off by tens to hundreds of milliseconds, and that cutting on raw alignment boundaries produces clicks and clipped consonants. Every design decision below follows from that. 2. Snap each cut to the nearest silence within a search window around the alignment boundary. Fall back to a zero crossing if no silence is found. 3. Apply a short crossfade at every join by default. 4. Keep edits as a non-destructive edit decision list referencing the original media by timestamp. Never modify the source, and make every cut adjustable after the fact. 5. Reference cuts by timestamp rather than word index, so re-running transcription does not invalidate existing edits. 6. For multitrack projects, apply time changes at the timeline level so all tracks stay in sync by construction rather than by being edited consistently. 7. Build a one-key audition of each edit point, and require reviewing them before export. 8. If video is in scope, tell me a text cut implies a visible jump cut and ask how it should be concealed before building it. 9. Out of scope unless I ask: voice cloning, filler-word removal at scale, studio sound enhancement, screen recording.
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
$24 a month buys alignment and cut placement tuned against a great deal of real speech, which is exactly the part that is subtly wrong when built casually. Transcript-driven navigation over a conventional editor is a good, much simpler project that captures most of the workflow benefit.
$24/mo is cheaper than your weekend.
Keep the original media untouched and the edit decision list in a readable format, so a project can be reconstructed or moved into a conventional editor. Export a plain audio file as well — a project that only opens in your tool is a project that ends with it.
Mature open-source video editor; useful alternative but not text-first SaaS clone.
Questions
Why snap to silence instead of trusting the alignment?
Because alignment models place boundaries approximately, and speech does not have clean edges — words run into each other, consonants start before the vowel you hear. Cutting at a silence a few tens of milliseconds away is almost always inaudible; cutting exactly where the model said the word ended frequently is not.
Is transcript-driven navigation without editing actually useful?
Very. Most of the benefit of this workflow is finding the moment — scrolling text instead of scrubbing a waveform to locate the bit you want. Clicking a word to move the playhead, then cutting in a normal editor, gives you the speed without the alignment precision problem entirely.
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