Vibe Coding Didn’t Replace the Job. It Just Moved Where the Real Work Is.

I had a demo video with no narration and a stack of AI tools that could hand me a working script in about the time it takes to make coffee. I used them. I'm not going to pretend otherwise, and I'm not going to apologize for it either — that would be its own kind of dishonesty, and I've got no patience left for either the "AI wrote my whole app" victory laps or the "real programmers don't need that" gatekeeping. Both are posturing. Neither describes how the work actually got done.

Here's the part that doesn't get said enough in either camp: getting a script that runs is not the same thing as getting a deliverable I'd put my name on. That gap — between "the AI-assisted draft works" and "I would actually ship this" — is exactly where the old rules still apply, completely unchanged, regardless of how fast the first draft showed up.

I hold everything I publish to three bars, and not one of them got easier just because a tool helped me get there quicker:

1. Is it secure?
2. Can I — or someone else — actually maintain this in six months?
3. Was building it something I'd want to do again, or was it just babysitting a black box?

Here's how those three held up against a completely unglamorous project: bolting a synced voiceover onto a 2-minute product demo.

1. Secure

The fast path, the moment pip refused to install anything globally, was staring right at me: pip install --break-system-packages edge-tts pydub. One flag, problem gone, tutorial continues. I didn't take it. That error exists because Debian doesn't want a stray pip install quietly overwriting packages the OS itself depends on — it's a guardrail, not a bug to route around. A project-local virtual environment solves the actual problem instead of muting the warning:

python3 -m venv .venv
.venv/bin/pip install edge-tts pydub

Same two extra lines, and now this project's dependencies can't touch the system Python at all, in either direction.

The other place security-mindedness showed up was less about the internet and more about not trusting my own output on faith. I was about to permanently delete the only copy of the raw screen recording and the generated voiceover, on the assumption that the merge had worked. "Probably fine" is not a security posture.

ffmpeg -v error -i final.mp4 -f null -

— which reads every frame and every audio sample and says nothing if nothing's wrong. Only after that came back clean did the originals go in the trash. It's a thirty-second habit that's saved me from turning a small mistake into an unrecoverable one more than once.

And I said so plainly, in the writeup, that the free TTS engine I ended up using talks to an unofficial API — it's riding on the back of a consumer browser feature, not a published, supported product. That's a real caveat, not a footnote to bury. Calling a dependency's actual risk profile by its name is part of the job, whether the code that uses it took five minutes or five hours to write.

2. Maintainable

The generation script is deliberately boring. All the actual content — the narration lines and their timestamps — lives in one plain list of dictionaries at the top of the file:

segments = [
    {"start": 25.0, "text": "First, let's hear the original audio, completely unchanged."},
    # ...
]

Editing the video's narration later means editing data, not re-reading logic to figure out where to poke it. That's not a clever pattern — it's just refusing to let "an AI helped draft this fast" become an excuse for the kind of tangled first-draft code nobody, including future-me, wants to open again.

Every verification step is a plain, copy-pasteable ffmpeg or ffprobe command, not a click buried three menus deep in some app's history. If I — or anyone else — needs to know exactly what happened to this file, it's sitting right there in a terminal history, rerunnable, inspectable, arguable-with. A GUI that "just works" is lovely until it stops working and there's no command to look at.

And cleanup happened in order, not all at once out of tidiness: verify the merge is sound, then delete the sources, then tear down the throwaway virtual environment. Each step only allowed because the one before it actually passed, not because the folder looked cluttered.

3. Fun and rewarding

This is the bar that's easiest to skip and the one I care about most, because it's the tell for whether "vibe coding" turned me into an operator or stayed a tool in an engineer's hands.

The AI-assisted first draft wasn't the satisfying part. The satisfying part was building actual proof that the thing worked: tiling frames from the source video into contact sheets and watching a script beat land exactly where the on-screen action happened. Running a silence-detection pass on the generated audio and watching every segment land within a fifth of a second of its target. Measuring loudness a hair before and a hair after each narration cue on the final muxed file and watching the number jump exactly where it should. None of that required permission from a tool — it required knowing what question to ask the file, and asking it.

That's the part vibe-coding skeptics are right to worry about losing, and the part vibe-coding boosters sometimes skip past entirely. A script that ran once isn't craftsmanship. But refusing every bit of acceleration on principle isn't discipline either — it's just slower, for no one's benefit.

Where I actually land

Neutral, genuinely. AI compressed the part of this project that was never where the value lived anyway — remembering library names, syntax, the shape of a first draft. It did nothing to compress the part that actually is the job: deciding whether a shortcut is safe to take, writing something the next person (including future-me) can read, and checking your own work instead of assuming it's right because it looks right. Those three things took exactly as long as they always have, because they're not a syntax problem. They never were.

A short note on tool choice

Somewhere in this project I could have reached for ElevenLabs instead of a free, hand-assembled pipeline, and it's worth being honest about what I'd have gotten: noticeably more natural delivery, real control over emotion and pacing, a much larger voice library, and — genuinely useful — built-in tooling for aligning generated speech to existing video, which would have replaced a fair chunk of the manual ffmpeg verification work above with an actual product feature.

For one demo video, built on a weekend, the free stack held up fine and cost nothing. If this were a recurring job — a video a week, something brand-facing, something where voice quality is the product — paying for that tooling stops being a luxury and starts being the obviously correct call. That's not a knock on the free path or a sales pitch for the paid one. It's just what "maintainable" and "worth my time" mean once volume changes the math.

The actual takeaway

Use the acceleration. Keep the verification habit. The tools changed how fast the first draft shows up — they didn't touch whether the deliverable has to earn trust the old-fashioned way, one checked assumption at a time.