لا تزال معظم البرامج الإبداعية تتطلب وجود إنسان ليكون حلقة الوصل بين الفكرة والملف النهائي. قد تصف عملية تحرير فيديو لذكاء اصطناعي، لكن العمل الفعلي المتمثل في قص المقاطع، وضبط الطبقات، وتصدير الإطارات يقع عادةً على عاتقك. توجد هذه الفجوة لأن تحرير الوسائط ليس مجرد مهمة تعتمد على "أمر واستجابة" واحدة، بل هو سلسلة طويلة من القرارات المترابطة، حيث لا تصبح الخطوة الثالثة منطقية إلا إذا أدت الخطوة الثانية بالفعل إلى تغيير الجدول الزمني. يعالج مشروع تمت مشاركته مؤخرًا هذا الاحتكاك تحديدًا من خلال ربط Claude Code بمسار عمل لتحرير الفيديو يعتمد على الحالة (stateful)، ومدعوم بواسطة Gemini Interactions API. والنتيجة هي عرض توضيحي عملي لكيفية جعل وكيل الذكاء الاصطناعي يوجه سير العمل الإبداعي حقًا بدلاً من مجرد اقتراح واحد.

مخرج ومحرر

تم تقسيم البنية المعمارية عن قصد. يعمل Claude Code كمخرج، حيث يتولى التخطيط رفيع المستوى، وتفسير الموجزات الإبداعية الغامضة، واتخاذ القرار بشأن ما يجب القيام به بعد ذلك. يقوم بتقسيم طلب مثل "قص الصمت وأضف بطاقة عنوان" إلى مهام منفصلة، ثم يراقب نجاح كل مهمة قبل الانتقال إلى المهمة التالية.

يتولى Gemini Interactions API منطق التحرير المتخصص. بدلاً من إجبار نموذج عام على محاكاة محرر فيديو، يستخدم هذا الإعداد واجهة برمجة تطبيقات Google كعامل تشغيل ميداني ينفذ عمليات القص، ويقيم حالة الجدول الزمني، ويقدم تقارير بنتائج ملموسة. لا يدمج النظام كلا الوظيفتين في نموذج واحد، بل يحافظ على فصل طبقة الاستنتاج عن طبقة استخدام الأدوات، مما يعني أن كل جزء يمكنه التركيز على ما يتقنه.

يعكس هذا التقسيم كيفية عمل فرق ما بعد الإنتاج الفعلية؛ فالمخرج يعرف القصة ويتخذ القرار، بينما يعرف المحرر البرنامج ويتعامل مع البكسلات. عندما يحاول الوكيل القيام بكليهما داخل نافذة سياق واحدة، فإنه غالبًا ما يتعثر في القواعد أو ينسى أي مقطع موجود في أي مسار. تقسيم الحمل يحل هذه المشكلة.

لماذا يغير "التذكر" كل شيء

تحرير الفيديو بطبيعته يعتمد على الحالة (stateful). إذا قمت بتقصير مقطع بمقدار أربع ثوانٍ، فيجب أن يتغير كل انتقال لاحق، وكل إشارة صوتية، وكل موضع للترجمة ليتناسب مع ذلك. تعاني معظم وكلاء الذكاء الاصطناعي هنا لأنهم يعاملون كل خطوة كاستعلام معزول؛ فقد يوصون بعملية قص في استجابة ما، ثم يهلوسون بجدول زمني مختلف في الاستجابة التالية، أو يقترحون تأثيراً لمقطع لم يعد موجوداً.

تم بناء Gemini Interactions API للحفاظ على الحالة عبر هذه العمليات، فهو يتتبع الحالة الفعلية للمشروع أثناء عمل الوكيل. وهذا يعني أن النظام يعرف ما إذا كان التصدير قد فشل، أو ما إذا كان قد تمت معالجة مقطع ما بالفعل، أو ما إذا تم تطبيق تصحيح لوني. عندما يصدر Claude التعليمات التالية، فإنه يعمل بناءً على الحالة الحالية الحقيقية للجدول الزمني، وليس بناءً على تخمين.

بالنسبة لأي شخص شاهد ذكاءً اصطناعيًا يقترح بثقة حلاً "بسيطًا" من خمس خطوات يتجاهل تمامًا الخطوات الأربع السابقة، فإن قيمة الحالة المستمرة واضحة تمامًا. تتدهور المهام الإبداعية بسرعة بدون ذاكرة، وتحول الخلفية البرمجية التي تعتمد على الحالة (stateful backend) روبوت الدردشة إلى مشارك يمكنه إنهاء المهمة بالفعل.

كيف يبدو سير العمل

تخيل تسلسلاً عمليًا: تقوم بتزويد النظام بعدة مقاطع خام وتطلب نسخة نهائية مخصصة لوسائل التواصل الاجتماعي. يقوم Claude Code أولاً بتقييم الطلب؛ فقد يقرر أن اللقطات تحتاج إلى تثبيت، ثم استخراج التعليق الصوتي، ثم الترجمة، ثم قص رأسي. يقوم بهيكلة هذه المهام كخطة ويبدأ في استدعاء Gemini Interactions API لتنفيذ كل عنصر بالترتيب.

يقوم Gemini بعمليات الوسائط ويعيد ملاحظات منظمة. ربما نجح التثبيت ولكن فصل الصوت وجد حوارًا متداخلًا يجعل الترجمة غير موثوقة. يتلقى Claude هذا التحديث، ويراجع الخطة، ويطلب من Gemini تجربة نهج مختلف، مثل

The project also illustrates a broader design pattern in AI engineering: stop trying to make one model do it all. Claude Code excels at reasoning through ambiguous instructions, managing branching logic, and maintaining conversational context over a long session. The Gemini Interactions API, particularly in its interaction with rich media and tool use, brings deep multimodal capabilities and stateful execution. By wiring them together, you route around the limits of each.

A reasoning model that has never touched a nonlinear editor can still direct a great cut if it has access to an execution layer that understands codecs, keyframes, and track hierarchies. Conversely, a media-savvy API does not need to parse abstract creative notes if a planner model has already translated them into concrete steps. The strengths of one fix the weaknesses of the other.

This is not theoretical. The setup explicitly demonstrates how different AI models work together to handle a category of work, creative video editing, that single-model agents often fail to finish. For developers building agentic systems, the lesson is hard to ignore. Stop asking your orchestration layer to be your specialist, and stop asking your specialist to be your strategist.

What Builders Should Take Away

You do not need to be running a video studio to find this pattern useful. Any domain that requires multi-step work over a changing environment, CAD workflows, audio engineering, data visualization, or scientific computing, can borrow the same structure. One model acts as the persistent project manager. A specialized API or tool handles the stateful operations inside the domain-specific software.

The developer’s job shifts from writing giant prompts that pray the model remembers everything, to designing clean handoffs between reasoning and execution. State management becomes the critical piece. If your agent cannot see what changed after its last action, it cannot reliably act again.

You can read the full breakdown of how the integration works, including the specific API interactions and project structure, in the detailed post on dev.to.

The Real Takeaway

Solving complex creative work with AI does not require waiting for a single, perfect model that can plan, remember, and execute everything at once. It requires giving the agent a memory that survives between steps and a specialist it can actually delegate to. Let the thinker think. Let the editor edit.