Your coding agent can't see the video it just made An engineer found that AI agents generating short video clips report success on every run, yet roughly one in five outputs were broken—with frozen frames, audio drift, and splice pops that the agent could not detect because it cannot watch the rendered video. The developer discovered that the dlazy CLI ships local validators that run against the rendered file at no cost, enabling a generate-validate-regenerate loop that closes the quality gap and lets humans review summaries instead of footage. 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.