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

Motaz Hefny — Sat, 07 Nov 2026 01:29:42 +0000

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.

App: https://play.google.com/store/apps/details?id=com.prompti.app
Web version and prompt library: https://fahhim.moteklab.com

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.

Arabic breaks most prompt templates — here is the structure that survives

Motaz Hefny — Fri, 06 Nov 2026 23:56:40 +0000

Most prompt engineering advice assumes English. You copy a six-part template, translate it into Arabic, and the output comes back almost right. The structure survived. The intent did not.

I have spent the last year building an Arabic-first prompt tool, and these are the failure patterns that kept repeating — plus a template that holds up in practice.

1. Arabic tokenizes differently, so "keep it short" means something else

Arabic is morphologically dense: one word can carry person, tense, and object. Tokenizers split Arabic more aggressively than English, so a 40-word Arabic prompt can consume noticeably more context than the same prompt in English.

The practical consequence: put the instruction first, the context second. If the model has to wade through three sentences of background before learning what you want, output quality drops — especially on smaller models.

Weak:

أنا عندي شركة صغيرة وشغال في مجال التسويق وعندي عميل محتاج حاجة...

The request never arrives. Better:

اكتب ٣ نسخ من رسالة متابعة لعميل. السياق: شركة تسويق صغيرة في القاهرة، العميل لم يرد منذ أسبوعين.

2. Diglossia: pick the register before you write

Arabic is not one language in daily use. If you do not specify register, models drift toward Modern Standard Arabic — even when you wrote in Egyptian Arabic. Your brand voice disappears, and the result reads like a government memo.

One explicit line fixes more than any other instruction:

اكتب بالفصحى المبسطة.
اكتب بالعامية المصرية، بنبرة مهنية.
اكتب بالعامية المصرية، وتجنب الكلمات غير المفهومة في الخليج.

That single constraint is worth more than three paragraphs of style description.

3. The six slots that actually matter

Whether you call it COSTAR or something else, six things reliably change the result:

Context — who you are, where, what already happened.
Objective — the verb: write, summarize, compare, rewrite.
Style — table, bullets, three paragraphs, JSON.
Tone and dialect — formal, warm, Egyptian, Gulf-neutral.
Audience — a hiring manager, a beginner developer, a customer.
Response contract — length, count, format, and what to avoid.

Most weak Arabic prompts contain only #2.

4. Copy-paste template

[المهمة] اكتب / لخص / حلل ...
[السياق] من أنا، وأين، وما حدث بالفعل
[الجمهور] من سيقرأ الناتج
[الأسلوب] جدول / نقاط / ثلاث فقرات / نص جاهز للإرسال
[النبرة واللهجة] فصحى مبسطة / عامية مصرية مهنية
[المخرجات] العدد، الطول، التنسيق
[القيود] ما يجب تجنبه
~~~

## 5. Before and after

**Job application**

Weak: اكتب لي رسالة تقديم لوظيفة

Better:

> اكتب رسالة تقديم لوظيفة محلل بيانات في شركة اتصالات في القاهرة.
> السياق: عندي ٣ سنوات خبرة في تحليل بيانات العملاء باستخدام SQL وPower BI.
> الجمهور: مدير توظيف غير متخصص تقنيًا.
> الأسلوب: ثلاث فقرات قصيرة، بدون مقدمات طويلة.
> النبرة: مهنية وواثقة، بدون مبالغة.
> المخرجات: نص جاهز للإرسال، أقل من ٢٠٠ كلمة، مع سطر موضوع للإيميل.
> القيود: لا تذكر الراتب، وتجنب العبارات العامة مثل "أنا شخص طموح".

**Product post**

Weak: اكتب بوست عن منتجنا

Better:

> اكتب منشور فيسبوك لمنتج عناية بالبشرة طبيعي.
> السياق: صفحة صغيرة، جمهور مصري، الفئة العمرية ٢٠-٣٥.
> الأسلوب: ثلاث جمل قصيرة وسؤال في النهاية.
> النبرة: عامية مصرية دافئة، بدون مبالغة في الوعود.
> القيود: لا ادعاءات طبية، ولا تستخدم كلمة "علاج".

**Technical explanation**

Weak: اشرح لي الـ API

Better:

> اشرح الفرق بين REST وGraphQL لمطور مبتدئ.
> السياق: يعمل على أول مشروع موبايل له.
> الأسلوب: جدول مقارنة ثم مثالان قصيران.
> النبرة: تعليمية ومباشرة.
> المخرجات: أقل من ٣٠٠ كلمة بالعربية، مع الاحتفاظ بالمصطلحات التقنية بالإنجليزية.

## 6. One more thing: keep prompts on the device

Most prompt tools are cloud forms that store whatever you paste. For work documents, CVs, and client data, that is a real concern — especially for teams handling personal data.

I build **Fahhim (فهّم)**, a free Android app that turns these six slots into a guided form in Arabic and English, with a prompt library that stays on the device. It is not the only way to write a good Arabic prompt — a plain notes app and the template above will get you most of the way.

- App: https://play.google.com/store/apps/details?id=com.prompti.app
- Web version and prompt library: https://fahhim.moteklab.com

If you try the template, I would genuinely like to know which slot made the biggest difference — for me it was the dialect line.

DEV Community: Motaz Hefny