# Your coding agent can't see the video it just made > Source: > Published: 2026-08-24 07:23:03+00:00 I spent a week letting an agent produce short video clips end to end. It reported success on every run. Roughly one in five was broken. Not subtly broken. One had a two-second frozen frame in the middle. One had narration drifting a full second off picture by the end. Two had audible clicks at every splice point. The agent had no idea. From its position, every step returned exit code zero. An agent orchestrating video generation is working blind. It can: What it cannot do is **watch the output**. So "the third clip froze" is not a state it can reach. This is different from how agents fail at code. A failing test is a signal the agent can read. A frozen frame is not — it's a property of pixels the agent never inspects. Which means: without something to close the loop, **you are the only quality gate**. And that caps your throughput at what you can personally sit through. The thing that changed this for me was finding that the `dlazy` CLI ships validators that run **locally against the rendered file** — no model call, no generation cost: ``` validate_freeze # frozen-frame intervals validate_av_sync # video ≈ audio ≈ subtitle duration coherence validate_audio_pops # pops at cut boundaries validate_cut_boundaries # per-cut pHash sampling on the render ``` Each maps to a failure mode that survives casual review: ** validate_freeze** — generated video stalls more often than people admit. A two-second freeze is easy to miss on a distracted first watch and impossible to miss once published. ** validate_av_sync** — a three-way duration check. Drift accumulates. 200ms off at the start is a second off at the end, and by then your narration is describing the previous shot. ** validate_audio_pops** — the thing that makes assembled audio sound amateur. Nearly invisible until it's on decent speakers. ** validate_cut_boundaries** — perceptual-hash sampling to catch cuts that landed somewhere other than intended. Off-by-one-frame errors in an edit list produce exactly this. These don't call a model. Running them is effectively free. That sounds like a minor cost note. It isn't — it changes *when* you run them. A check that costs something gets run on the final version, if at all. A check that costs nothing gets run on everyrender — including the ugly intermediates, which is when the error is cheapest to fix. Generalise it: **the value of a check is a function of how often you're willing to run it, and that's mostly a function of what it costs.** Cheap checks get run. Expensive checks get skipped exactly when you're under pressure, which is exactly when you need them. The prompt shape that works: ``` After rendering, run the freeze, A/V sync and audio-pop checks. If any fail, regenerate only the affected segment and re-check. Report which checks ran and what they returned. ``` That last line is non-negotiable. An agent that says "done" without stating what it verified has told you nothing. Once this is in place the loop actually closes: generate → validate → regenerate what failed → report. **You review the summary, not the footage.** These catch *mechanical* failures. Freezes, drift, pops, misaligned cuts. They cannot tell you the video is boring, off-brand, or says the wrong thing. That distinction is useful rather than disappointing — it tells you where to put your attention. Let the validators own the mechanical layer completely, and spend your review time on judgement, which is the part they can't touch. Ask what it does *after* generation. Most AI video tooling stops at the model call and hands you a file. That's fine for one clip. At any volume, the interesting engineering is entirely in the verification layer — and its presence or absence tells you whether someone actually shipped video at scale with this thing, or just demoed it. Install is one line if you want to try it: ``` curl -s https://files.dlazy.com/cdn/cli | bash ``` Then `dlazy -h` for the tool list. I'd start with a throwaway clip and deliberately break it — generate something, then run the validators and confirm they actually complain. A check you haven't seen fail isn't a check you trust yet.