DEV Community

Motaz Hefny
Motaz Hefny

Posted on

Why your AI video prompts produce morphing hands and flickering faces (and the syntax that fixes it)

Most AI video generators fail for the same three reasons: the camera moves when it should not, hands melt, and faces shift between frames. I have spent the last few months building prompt frameworks for Kling, Runway, Sora, and Luma, and the failures are not random. They follow patterns.

1. Video prompts are shot briefs, not sentences

Text models read a prompt as one stream. Video models decompose it into shots: camera, subject, motion, lighting, duration. If your prompt reads as a sentence, the model guesses the shot structure. If it reads as a brief, the model executes it.

Weak:

A man walking in a rainy street at night, cinematic, beautiful.

The camera is undefined, so it drifts. "Beautiful" is undefined, so it samples. Better:

Close-up, locked camera. A man in a dark coat walks toward the lens on a wet asphalt street, neon reflections. Shallow depth of field, 35mm look. Slow push-in only. Rain in focus. 5 seconds.

Every verb is assigned to exactly one layer: camera, subject, environment, optics, duration.

2. Motion must be budgeted — one primary movement per shot

The number one cause of morphing is competing motion. If the subject walks AND the camera pans AND the background crowds move, the model spends its motion budget on all three and none stays stable.

The rule I apply in the CINE framework:

  • One primary motion (subject or camera, never both).
  • Secondary motion limited to environment (rain, steam, hair).
  • Everything else frozen.

3. Anti-morphing constraints are syntax, not adjectives

"High quality" does nothing. Specific negative constraints do. What actually holds faces and hands together:

  • Facial integrity: "consistent facial features across all frames, no identity drift"
  • Anatomy guard: "stable hand anatomy, five fingers, no merging of limbs"
  • Temporal smoothing: "smooth temporal interpolation, no flicker or frame popping"
  • Anti-flicker: "consistent lighting across frames, no exposure jumps"

On Kling and Runway these go in the negative-prompt field or as explicit constraints in the prompt. On Sora-style single-field models, they must be stated positively: "the face remains identical in every frame."

4. Engine-specific tuning

Each engine has quirks worth knowing:

Engine Quirk Fix
Kling (v1.5/v2.0) Ignores negative prompts partially State constraints positively in the main prompt
Runway Gen-3/4 Drifts camera if two verbs One camera verb max
Luma Temporal flicker in fast motion "smooth slow motion" + duration cap
Sora/Veo Over-interprets "cinematic" Specify lens and lighting explicitly

5. The three frameworks

I built this into a small tool — Fahhim (فهّم) — as three separate frameworks because the failure modes differ:

  • CINE — cinematic scenes: camera, lens, lighting, motion budget.
  • I2V — image-to-video animation: locks the input image's identity, animates only what you specify.
  • SHOT — commercials and social video: hook in frame 1, fast cuts, aspect ratio, on-screen text zones.

The app is free, works offline, and keeps your prompts on the device — which matters if your prompts contain unreleased product footage descriptions or client names.

If you are building video prompts today, the single highest-leverage change: write the camera instruction first, then forbid secondary motion. That one move fixes more flicker than any "cinematic" adjective.

Top comments (0)