نجحت في تحويل الكلام إلى كود: كيف بنيت Voice Agent يتحكم في Codex

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

النتيجة النهائية كانت واضحة ومقنعة: Voice Agent يتكلم معي، يفهم الطلب، ثم يمرره إلى Codex في الخلفية حتى ينشئ ملفاً داخل المشروع فعلياً. هذا لم يحدث من أول محاولة، وهذا بالضبط ما يجعل التجربة مفيدة.

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

الفكرة التي تستحق البناء فعلاً

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

هذه النقطة مهمة لأن القيمة ليست في "voice to voice" فقط، بل في "voice to action". أي أن الكلام لا ينتهي برد صوتي لطيف، بل يتحول إلى تنفيذ فعلي داخل مشروع حقيقي.

الشيء المشجع هنا أن Realtime 2 أعطى انطباعاً أنه قادر على هذا النوع من الاستخدام، خصوصاً مع وجود أدوات مساندة مثل OpenAI Documentation MCP وملحق OpenAI Developers. هذا لم يضمن النجاح، لكنه رفع احتمال التنفيذ بشكل واضح.

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

ما الذي بُني فعلياً في التطبيق

التطبيق لم يكن مجرد نافذة دردشة. كان فيه واجهة تسمح باختيار مسار المشروع على الجهاز، وتحديد مزود التنفيذ بين Codex وClaude Code، واختيار لغة الـ prompting، وحتى تحديد نوع المهمة إن كانت coding أو docs/content.

كان فيه أيضاً Pre-Flight checks قبل البدء، ومكان للموافقات approvals، وتتبع زمني لما يحصل، وإدارة للجلسة الصوتية نفسها. هذا تفصيل مهم لأن أغلب الأفكار تسقط عندما تبقى في مستوى "خليني أحكي مع النموذج" من دون نظام تشغيل واضح حولها.

ومن الناحية العملية، استخدام OpenAI API key كان أساسياً للجزء الصوتي المرتبط بـ Realtime 2. أما Codex وClaude Code فالفكرة كانت أن التطبيق يتواصل معهما عبر CLI، وإذا كان المستخدم مسجلاً الدخول مسبقاً على جهازه فليس بالضرورة أن يحتاج API keys إضافية لكل شيء.

هذا التصميم أعطى المشروع شكل مساعد فعلي، لا مجرد تجربة صوتية. والدلالة هنا مهمة: نجاح أدوات الذكاء الاصطناعي في العمل اليومي يتطلب UI واضحة، حالات تشغيل مفهومة، وممرات تنفيذ قابلة للفحص.

لماذا لم أبدأ بالتنفيذ مباشرة

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

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

هذه ليست مجرد راحة نفسية. هذا أسلوب تنفيذ. كل مرحلة كانت قابلة للفحص، والحفظ، والتراجع عند الحاجة. ومع كل خطوة كان الكود يُحفظ في Git ثم يُربط مع GitHub حتى لا تضيع النسخ العاملة.

التطبيق العملي هنا واضح لأي شخص يبني مع AI: لا تطلب من النظام "ابنِ كل شيء". اطلب منه أن يحول الفكرة إلى milestones قصيرة ذات احتمال تنفيذ أعلى، ثم تحرك واحدة وراء الأخرى.

الأدوات المساندة لم تكن تفصيلاً جانبياً

جزء كبير من سبب تقدّم التجربة كان استخدام OpenAI Documentation MCP وملحق OpenAI Developers داخل Codex. هذا أعطى النظام وصولاً أفضل إلى أفضل الممارسات، والـ Agents SDK، ومراجع الـ API، وحتى مسارات troubleshooting.

في مشروع يعتمد على Realtime 2 والصوت والأدوات والـ CLI، الوصول الجيد إلى التوثيق ليس رفاهية. هو فرق بين نظام يتخبط في التخمين ونظام يبني على معلومات أقرب للصواب.

حتى عندما ظهرت المشاكل، لم تكن العودة إلى "جرّب أي شيء" هي الحل. الحل كان الرجوع إلى التوثيق، وقراءة الـ logs، ومراجعة ما إذا كانت الأدوات فعلاً معرّفة داخل التطبيق بالطريقة التي تسمح للوكيل الصوتي أن يراها ويستخدمها.

المغزى هنا بسيط: إذا كنت تستخدم coding agent في شيء غير تقليدي، فالمهارة ليست في كتابة برومبت قوي فقط، بل في تجهيز بيئة مرجعية قوية للنظام نفسه.

المشكلة لم تكن في الصوت... بل في ربط الأدوات

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

في أول مرحلة، كانت المحادثة الصوتية تعمل لكن الوكيل يقول بوضوح إنه لا يستطيع استخدام Codex CLI من داخل الجلسة. لاحقاً تحسن الوضع جزئياً، وصار يرى أن هناك أدوات، لكن عندما أسأله عن Codex تحديداً لا يتصرف كما يجب.

ثم بدأت سلسلة من المشاكل الأدق: صلاحيات تشغيل غير صحيحة، نقص في تفاصيل الاستجابة، مشاكل مرتبطة بالـ thread أو بالـ task start، وحالات تنفيذ تبدأ ثم لا تعود بالمعرف المطلوب لإكمال المهمة.

هذه تفاصيل مزعجة أثناء التصوير، لكنها في الحقيقة أفضل جزء في التجربة. لأنها أوضحت أن التحدي في هذا النوع من التطبيقات ليس جعل النموذج يتكلم، بل جعل منظومة الأدوات كاملة تتصرف كمنتج واحد متماسك.

والنتيجة العملية هنا مهمة جداً: إذا كنت تبني agent متعدد الطبقات، فاختبر طبقة الصوت وحدها، ثم طبقة الأدوات وحدها، ثم orchestration بينهما. لا تفترض أن نجاح واحدة يعني نجاح البقية.

التحول الحقيقي بدأ عندما صار Logging أفضل

في كل مرة كانت التجربة تفشل، كان الحل الأهم ليس برومتاً جديداً فقط، بل تحسين الـ Logging. كلما صار النظام يجمع تفاصيل أدق عمّا يجري داخل التطبيق، صرنا نعرف أين يتعطل المسار فعلاً.

هذا ظهر بوضوح عندما طلبت من Codex أن يراجع الـ logs، ويضيف معلومات أكثر، ثم يعيد دراسة المشكلة. عندها بدأت التعديلات تصبح أذكى: ليس ترقيعاً عشوائياً، بل إصلاحاً أقرب إلى السبب الحقيقي.

في المشاريع الصوتية تحديداً، هذا فارق ضخم. لأنك تتعامل مع جلسة صوتية، تحويل أوامر، مزود تنفيذ، أدوات خارجية، وواجهات متعددة. إذا لم ترَ ما يحصل في كل طبقة، فأنت لا تصلح النظام، أنت فقط تعيد المحاولة.

الدرس العملي: observability ليست مرحلة متقدمة تأتي لاحقاً. في مشاريع الـ agents، هي من أول المتطلبات، لا من الكماليات.

اللحظة التي أثبتت أن الفكرة تستحق الاستمرار

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

هذا لم يكن تطبيقاً كاملاً ولا نهاية العمل. لكنه كان البرهان الذي نحتاجه: الكلام دخل إلى الوكيل الصوتي، والوكيل مرر الطلب إلى Codex، وCodex نفّذ داخل المشروع الحقيقي على الجهاز.

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

إذا كنت تبني منتجاً أو workflow جديداً، فابحث دائماً عن هذا النوع من الانتصارات الصغيرة الواضحة. ملف واحد يُنشأ فعلياً قد يكون أهم من عشرات الواجهات الجميلة التي لا تنفذ شيئاً.

ما الذي تعلّمته عن البناء مع Codex وClaude Code

1) البرومبتات القصيرة تتفوق على البرومبتات الكبيرة

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

2) افهم الكود ولو على مستوى معماري

حتى لو لم تكن تراجع كل سطر، من المهم أن تفتح الملفات وترى كيف تتشكل، وما الذي يفعله كل جزء رئيسي. ويمكن دائماً أن تطلب من Codex أن يشرح لك الملفات المهمة جزءاً جزءاً.

3) ابدأ بمستودع خاص ثم افتحه لاحقاً

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

4) افصل مفاتيح الـ API حسب المشروع

تم إنشاء OpenAI API key داخل مشروع منفصل على الـ dashboard. هذا يحافظ على التنظيم ويمنع اختلاط الاستخدامات عندما تكبر التجارب.

5) لا تعتمد على الإحساس، اعتمد على Pre-Flight checks

وجود فحص قبل التشغيل كان مفيداً جداً للتأكد من أن الجلسة والبيئة الأساسية جاهزة. في المشاريع متعددة الأجزاء، الفحص المسبق يوفر وقتاً طويلاً من التخمين.

هذه ليست نصائح عامة جميلة. كلها خرجت من احتكاك حقيقي مع تطبيق لم يعمل من أول مرة، ثم بدأ يتحسن خطوة خطوة.

لماذا هذا الاتجاه مهم من الآن

الفكرة هنا أكبر من إنشاء ملف HTML بالصوت. إذا صار بينك وبين coding agents طبقة صوتية جيدة، فأنت لا تختصر فقط خطوات الكتابة. أنت تبني طريقة تفاعل جديدة بالكامل مع بيئة العمل.

في هذه التجربة مثلاً، كان ممكناً التحدث بالعربية، مع الحفاظ على خيار توجيه الـ prompting بلغة مختلفة إذا لزم الأمر. هذه المرونة وحدها تفتح باباً لاستخدامات عملية كثيرة، خصوصاً عندما تريد أن يكون التفاعل طبيعياً بالنسبة لك، والتنفيذ منضبطاً بالنسبة للأداة.

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

الخلاصة العملية: المستقبل هنا واعد، لكن الطريق إليه ليس "اضغط زر وتكلم". الطريق الحقيقي هو orchestration جيد، أدوات واضحة، وصبر على الإصلاح.

الخلاصة التي تهم أي شخص يبني مع AI اليوم

أكثر شيء أعجبني في هذه التجربة ليس فقط أن الفكرة اشتغلت، بل أنها أثبتت شيئاً أؤمن به كثيراً: التقدم الحقيقي مع الذكاء الاصطناعي يأتي من التكرار الذكي، لا من وهم الضربة الواحدة.

Voice Agent يتحكم في Codex وClaude Code ليس مجرد فكرة لطيفة بعد الآن. هو اتجاه قابل للبناء فعلاً. لكن الطريق إليه يمر عبر مراحل قصيرة، فحوصات واضحة، Logging دقيق، ومحاولات متكررة تقربك من نظام يمكن الاعتماد عليه.

إذا كنت تبني شيئاً مشابهاً: ابدأ صغيراً، جزّئ المهمة، سجّل كل شيء، واسمح للفشل أن يكشف لك شكل المنتج الصحيح.

ولو كنت تعمل على workflows فيها صوت + agents + أدوات تنفيذ، يهمني جداً أعرف: ما أول طبقة ستبنيها أو تصلحها قبل أي شيء آخر؟