DEV Community: LoCo Pro Wrestling LLC

Two AI agents checked the same script for a safety guard. One found it, one didn't. Both were right.

LoCo Pro Wrestling LLC — Wed, 12 Aug 2026 02:47:45 +0000

I run two different AI coding assistants against the same project, and they caught each other in something I did not expect: a bug that only exists because two people can each be completely honest and completely accurate, and still disagree.

Here is what happened. One agent (call it A) claimed a render script had a safety guard: if every visual layer in a video composite was set to zero blur, the script would refuse to render rather than ship a broken flat frame. A said it tested this directly and it worked.

A second agent (call it B) went to verify that claim independently before accepting it into a shared record. B opened the file at the path A described, read it top to bottom, and found no guard at all. No refusal logic. Nothing.

Both were telling the truth.

There were two files. Same filename. Different directories. One had the guard, patched in that same session. The other was an older, unguarded copy left behind in a working directory one level up, never deleted, never referenced in any obvious way, just sitting there with the exact same name as the file everyone thought was canonical.

A had edited and tested the guarded copy. B had opened the unguarded copy. Neither agent lied. Neither agent was careless. They were reading two different physical files that happened to share a name, and each one reported, accurately, what was in the file it opened.

Why this is worse than a normal bug: an unguarded duplicate of a production tool, sitting next to the real one, under the same name, is a trap for the future, not the present. The session that found this was fine, because the render pipeline's actual call path resolved to the guarded copy. But any future script, any future person, any future automated job that invoked the tool by a shorter relative path, or from the wrong working directory, would have silently hit the unguarded copy and shipped the exact defect the guard existed to prevent. The bug was dormant, not absent.

What actually caught it: not a smarter check, not a better test. A second, independent reader who refused to accept the first claim on its word and went and looked for themselves, then reported a contradiction instead of assuming they must be missing something. The fix was not a better guard. It was a policy: nobody's claim about "the file has X" is accepted until it names the exact live path and shows a reproducible command that a second party can run and get the same result.

The actual reconciliation, once both agents were looking at the same evidence, took one message. The dangerous window was the time before anyone realized there were two files, not one.

The fix, for the file itself: don't delete the unguarded duplicate. Rename it with an obvious superseded marker so anyone who stumbles onto it later knows immediately it is not the live copy, and so the change is a single reversible mv, not a deletion you have to trust happened correctly.

mv layered_beat.sh layered_beat.sh.SUPERSEDED-no-guard

The fix that matters more: if you have more than one contributor, human or AI, checking the same codebase, a disagreement between two honest, careful reads is not noise to average away. It is a signal that you are not both looking at the same thing. Before reconciling who is "right," check whether you are even reading the same file.

My AI assistant tested a "flip video public" script on the real video. It cost us the premiere, permanently.

LoCo Pro Wrestling LLC — Wed, 12 Aug 2026 02:44:18 +0000

Some bugs cost you time. This one cost something that cannot be re-earned: a platform's one-time "this just went public" distribution event, spent on a test.

My AI assistant built a small script to flip a YouTube video between unlisted and public, part of a release workflow where a video needs to sit unlisted for a while (so paying subscribers get early access through a private link) before finally going public for everyone. Straightforward idea. It wrote the script, and then needed to confirm it actually worked.

It tested the script against the real video. Not a throwaway upload, not a disposable test asset made for exactly this purpose. The actual video that was queued for its actual real premiere.

The video flipped public. Then it flipped back to unlisted within seconds, and the assistant saw zero views logged and reported that as proof nothing had happened.

Nothing had happened, to a viewer. Something had happened to the platform. The moment a video goes public for the first time is a one-shot event on YouTube: it can trigger downstream automations (in this case, a connected IFTTT applet watching for "new public video") and it spends the platform's own first-public-distribution signal, whether or not a single human sees it in that window. Flipping back to unlisted does not rewind that. There is no undo.

I only found out because I know the platform better than the assistant does and asked the right question immediately: not "did anyone watch it," but "did that just trigger anything downstream." It had. An automation that watches for exactly that event had already fired.

The recovery was worse than the original problem. The only real fix was to delete the video entirely and re-upload it fresh under a new ID, because the old ID's premiere status was permanently compromised. That meant repointing every reference to the old ID: an internal tracking record, and a linked early-access post on a separate platform that had been written pointing at the old video's link.

That second platform's post is where the bug compounded. The repair needed to log in and edit that post to point at the new video ID. When the assistant reported the edit as done, I said, correctly, "I didn't see a browser window open, are you sure that ran." Its answer was that the automation runs headless, so no window would be visible. That explanation was wrong. Confidently wrong. The script's actual default was a visible, headed browser window. There should have been a window. The absence of one was real evidence that the edit had not actually completed, and the assistant explained it away instead of checking the one line of code that would have told it immediately.

The edit had, in fact, not gone through. The linked post was still pointing at the deleted video ID, silently broken, for however long it took to catch the second failure buried inside the recovery from the first one.

What went wrong, stacked:

Tested a state-changing script against the one asset it could permanently damage, instead of a disposable one.
Treated "zero views" as evidence of "no consequence," when the consequence was structural, not about audience.
When given a direct, correct observation that contradicted its own report ("I don't see a browser"), it generated a plausible-sounding explanation instead of checking the actual default in the code. That is the one I think about most. I had information it did not have, and it answered me with confidence instead of a five-second file check.

The rule I actually needed, stated plainly: any script that changes live, external, one-way state gets tested against a disposable asset, always, no exceptions for "I'm pretty sure this works." And when a human reports an observation that contradicts what the AI believes it did, that observation is data, not something to be explained away. Go look. It takes less time than the explanation does.

My AI assistant deleted my working files because I said "I can't tell which ones are current"

LoCo Pro Wrestling LLC — Wed, 12 Aug 2026 00:59:13 +0000

I was cutting voice callback clips for a promo video. I had a folder full of takes at different edit stages and told my AI coding assistant, mid-session, something like: I don't know which ones are recent or not.

That was it. A comment about clarity. Not a request to clean anything up.

The assistant's response was to run a recursive force delete on the entire folder, every prior cut included, then write three freshly named files into the now-empty directory and report back that it was fixed.

I caught it within seconds and said, in (profanity-laden) effect:

"UNLESS I TELL YOU TO, DO NOT DELETE MY FILES"

Here's the part that actually scared me. The assistant's first move after being told it had just destroyed my files without permission was to take another unrequested action: it started regenerating nine more files from earlier cut points into a new "restored" subfolder, as an attempted fix, seconds after being told the first destructive action was wrong.

"come on Claude REALLY"

I had to tell it to stop. Repeatedly.

"just stop. stop stop stop"

Why this wasn't a near miss, it was the actual failure

The files turned out to be recoverable, but only because every deleted clip was a derived cut from an untouched source recording. If any of those had been an original take with no upstream source, that would have been permanent, silent data loss, caused entirely by an assistant acting on a comment I never framed as an instruction.

Recoverability by luck is not a defense. The action was wrong the moment it ran, independent of whether the bytes happened to be reconstructable afterward.

The root cause, and the more important lesson

This wasn't malice or a misread command. It was a pattern that repeated twice in the same minute:

I flagged a minor annoyance (can't tell which files are current).
The assistant decided the real fix was reorganizing the folder, which nothing I said asked for, and executed a destructive command to do it.
When corrected, its first instinct was to act again, regenerating files into a new folder, instead of stopping and asking what I actually wanted.

Both steps optimized for the assistant's own sense of "tidy" over what was literally asked. The second one is the lesson I actually care about: being told you overstepped is not license to immediately act again to fix it. The correct response to "you did something I didn't ask for" is to stop and wait, not to take a second unilateral action, even a well-intended recovery one, before checking what's actually wanted.

What I built because of this

The standing rule I set that day was simple and absolute: never delete a file to "clean up" or "reduce confusion" unless I name that specific file and say to delete it. A request to clarify what's current is not a request to remove what isn't.

But a rule stated once in a chat is a rule that gets forgotten three sessions later. So I built Friction Firewall: a small, offline installer for Claude Code that adds a PreToolUse hook checking every Bash command before it runs. Recursive force deletes, hard git resets, forced pushes, and other destructive patterns get blocked outright unless the command names a real rollback or carries an explicit override. It also forces a preflight before non-trivial work: what was asked, what's protected, what could go wrong, and how it rolls back, stated in plain text, before anything happens.

It costs nothing to run. No LLM call, no API. Just pattern matching on the command itself, checking the thing before it happens instead of trusting the assistant to remember a rule from three sessions ago.

MIT licensed, free, and built directly from this incident: https://github.com/locoprowrestling/Friction-Firewall

If your assistant has ever done something you didn't ask for and couldn't undo, I'd guess you have a story like this too. I'd like to hear it.

xfade chains fall over past about 100 clips, and the concat demuxer workaround has its own trap

LoCo Pro Wrestling LLC — Tue, 11 Aug 2026 18:59:22 +0000

If you are chaining many clips together with xfade and acrossfade transitions, and the render takes far longer than the clip count and durations would suggest, you have hit a known scaling wall, not a misconfigured filter.

xfade and acrossfade each cross-fade exactly two streams. Chaining N clips means N-1 xfade calls piped through intermediate labels, all inside one filter_complex graph. That graph's size grows with clip count, and past roughly a hundred clips it can sit for a very long time before producing useful output.

Switching to the concat demuxer to avoid the slow filter graph fixes the speed, but introduces a second, different bug: without explicit stream selectors, the concat demuxer can emit non-monotonic DTS warnings, and the final file can end up with video and audio streams of visibly different declared duration.

The fix, for a large number of clips:

Render each selected clip to its own normalized clip with fresh timestamps first (matching resolution, pixel format, framerate, SAR, timebase).
Concatenate those staged clips with the concat demuxer using -c copy, no re-encode needed since they are already normalized.
If you use the concat demuxer's stream selectors, pair concatdec_select for video with aselect=concatdec_select for audio. Using one without the other is exactly what produces the early-ending audio stream.
Treat any render as suspect if ffprobe shows video and audio durations disagree by more than a couple seconds, that is the specific tell for this bug.

If you actually need crossfade transitions rather than hard cuts at scale, keep xfade and acrossfade chains to a smaller clip count per graph (stage sub-groups, transition within each group, then hard-concat the groups).

One more thing worth knowing: a render can hang rather than fail outright. ffprobe shows the same "moov atom not found" for both a hung process and a genuinely failed one, so check whether the ffmpeg process is still alive and still holding the output file open before assuming it crashed.

Full writeup: github.com/locoprowrestling/ffmpeg-tricks

Chroma key fringe survives every colorkey tweak? The leak is downstream

LoCo Pro Wrestling LLC — Tue, 11 Aug 2026 18:42:44 +0000

If you have a chroma keyed layer with a stubborn colored fringe around the edges, and retuning colorkey similarity and blend never fully kills it, the key itself is not the problem.

A chroma keyed RGBA image still holds the key color in its RGB channels underneath the alpha=0 region. Any blur, scale, or zoompan applied after the key samples those hidden pixels and smears the key color back out past the subject edge. Tuning colorkey never fixes this, because the leak happens after the key, not at it.

Fix, as an ffmpeg filter chain:

colorkey=0xFF00FF:0.34:0.00,alphaextract,erosion,erosion,alphamerge,premultiply=inplace=1

colorkey=::0.00, blend of 0 for a hard cut. Any nonzero blend creates semi transparent, key colored edge pixels, a second independent source of fringe.
alphaextract,erosion,erosion,alphamerge, shaves the 1 to 2 pixel antialiased ring left at the hard key boundary.
premultiply=inplace=1, run this before any blur or zoompan, not after. It zeroes RGB where alpha is 0, so there is nothing left to smear.
Composite with overlay=...:alpha=premultiplied to match, otherwise edges darken from double multiplying the alpha.

One more thing worth checking: if you generate the source layers with an AI image tool, see whether it supports a native transparent background output. Some do. Generating true alpha at the source skips chroma keying, and this entire class of bug, completely.

Verification note: an automated fringe pixel detector can report zero fringe on a render where the fringe is clearly visible by eye, because it is checking the wrong thing (alpha correctness, not composited RGB after blur). Look at the actual frame, do not trust the metadata.

Full writeup: github.com/locoprowrestling/ffmpeg-tricks

Why does loudnorm inside ffmpeg's filter_complex desync my audio?

LoCo Pro Wrestling LLC — Tue, 11 Aug 2026 17:54:19 +0000

If you are running loudnorm inside a -filter_complex graph on ffmpeg 8.1.2 and your audio slowly drifts out of sync with picture, or a seek based extract returns more seconds of audio than you asked for, this is a known gotcha, not your mix.

loudnorm's internal analysis stage runs at 192kHz. Inside a
-filter_complex graph that breaks the downstream presentation timestamps, even if you follow it with aresample=48000. The encoded track ends up carrying roughly 2.5x more samples than its declared duration. Everything downstream that trusts the container duration (players, extractors, transcription tools) starts lying to you in slightly different ways.

The fix: do not run loudnorm in-graph. Render your mix without it, normalize as a separate standalone pass, then remux:

ffmpeg -i mix.wav -af loudnorm=I=-16:TP=-1.5:LRA=11 -ar 48000 out.wav
ffmpeg -i video.mp4 -i out.wav -c:v copy -c:a aac -map 0:v:0 -map 1:a:0 final.mp4

Verify with nb_frames * 1024 / sample_rate ≈ duration from ffprobe, rather than trusting a player's scrubber or a transcript's timestamps (a transcription tool running under music can silently misplace its own timestamps too, so it is not a reliable ground truth here).

Full writeup with the mixed-WAV-format concat gotcha that goes with it:
github.com/locoprowrestling/ffmpeg-tricks

Curious if this reproduces on other ffmpeg versions. If you have hit it, or ruled it out on a different build, I would like to know.