العقود الآجلة
وصول إلى مئات العقود الدائمة
TradFi
الذهب
منصّة واحدة للأصول التقليدية العالمية
الخیارات المتاحة
Hot
تداول خيارات الفانيلا على الطريقة الأوروبية
الحساب الموحد
زيادة كفاءة رأس المال إلى أقصى حد
التداول التجريبي
مقدمة حول تداول العقود الآجلة
استعد لتداول العقود الآجلة
أحداث مستقبلية
"انضم إلى الفعاليات لكسب المكافآت "
التداول التجريبي
استخدم الأموال الافتراضية لتجربة التداول بدون مخاطر
إطلاق
CandyDrop
اجمع الحلوى لتحصل على توزيعات مجانية.
منصة الإطلاق
-التخزين السريع، واربح رموزًا مميزة جديدة محتملة!
HODLer Airdrop
احتفظ بـ GT واحصل على توزيعات مجانية ضخمة مجانًا
منصة الإطلاق
كن من الأوائل في الانضمام إلى مشروع التوكن الكبير القادم
نقاط Alpha
تداول الأصول على السلسلة واكسب التوزيعات المجانية
نقاط العقود الآجلة
اكسب نقاط العقود الآجلة وطالب بمكافآت التوزيع المجاني
المزيد
رئيس منتج OpenAI Codex يروي: كيف نطور المنتج بدون معايير وخريطة طريق؟
“الحماس والاستقلالية هما أكثر صفات البشر جوهرية وأهمية في عصر AGI.”
ترتيب وتجميع: Deep Tide TechFlow
الضيوف: Alex، مدير منتجات Codex؛ Romain، مطوّر تجربة المستخدم (DevX) في Codex
المقدّم: Peter Yang
مصدر البودكاست: Peter Yang
العنوان الأصلي: How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain
تاريخ البث: 5 أبريل 2026
ملخص النقاط الرئيسية
Alex هو مدير منتجات Codex، وRomain يتولّى تجربة المطوّرين. لقد جعلوني—للأسف النادر—أفهم بشكل عميق طريقة عمل فريق Codex، بما في ذلك كيف يستخدمون Codex لبناء منتجات، وكيف يطلقون المنتجات دون معايير منتجات تقليدية وخطط طريق. شارك Alex أيضًا بعض الرؤى الفريدة حول التطور المستقبلي لمدير المنتج (PM)، وما الذي يهم فعلًا في عملية التوظيف.
ملخص أبرز الأفكار
البناء الفوري و“سرعة التفكير” في Codex Spark
حول وثائق المواصفات ومسار اتخاذ القرار
حدود المهنة تتلاشى وتطوّر المصممين
فلسفة تصميم المنتج: اجعل النموذج “غير مرئي”
فلسفة التخطيط: رفض “الإحراج في منتصف الطريق”
تحوّل الواجهة الناتج عن “تفويض الوكلاء الذكيين”
اختفاء السلم الوظيفي و“انهيار كومة المواهب”
معايير التوظيف: الأعمال تتفوّق على السيرة الذاتية
عرض مباشر في الموقع: بناء لعبة في بضع ثوانٍ باستخدام Codex Spark
المقدّم Peter: أنا متحمس جدًا لإدارة حلقة Alex وRomain اليوم، وهما من فريق Codex في OpenAI. سيعرضان كيفية بناء وظيفة جديدة في Codex، وما هي قدراته، وكيف يقوم فريق Codex بإطلاق المنتجات باستمرار. هل تريدان أن تعرضا بسرعة ما الذي يمكن بناؤه فعليًا باستخدام prompt لمرة واحدة (one-shot)؟
Romain：
بالطبع، سأشارك شاشتي. في الواقع يمكنني عرض الكثير من الأشياء، لكن ربما يلزمك مجرد نظرة سريعة—مثلًا، هذه تطبيق iOS كنت أعمل عليه باستمرار. إذا أردت إضافة ميزة جديدة إلى هذا التطبيق، يمكنني ببساطة أن أقول شفهيًا: “مرحبًا، هل يمكنك إضافة شاشة جديدة إلى مهمة العودة من القمر الخاصة بـ NASA؟” ثم أرسل هذا الـ prompt باستخدام GPT-5.4، وسيقوم النموذج بإنشاء شاشة جديدة لهذا التطبيق تحديدًا.
لكن لدينا أيضًا نموذج Codex Spark، ويمكنه مساعدتك في صياغة أي شيء والتكرار عليه خلال ثوانٍ معدودة. دعني أعرض لك اختلاف الاستجابة السريعة في نموذج Spark. على اليسار GPT-5.4 وعلى اليمين Codex Spark. ثم بالمعدل تحصل على حوالي 1200 token في كل ثانية. السرعة مجنونة جدًا. لذا عندما تريد بناء شيء ما—مثلاً لعبة—وقبل أن نبدأ هذه المحادثة، قمت فعليًا بفتح تطبيق Codex وبتقديم prompt سريع أنشأت لعبة صغيرة ثنائية الأبعاد تشبه Animal Crossing.
عندما تكون أفكاري واضحة، أحب جدًا ميزة أخرى في Codex: افتح Codex واجعل المحادثة عائمة في أعلى الشاشة، بحيث إذا كنت فعلًا تعمل على هذه اللعبة، يمكنك الاستمرار في التكرار وتوليد المزيد من الأفكار. هل لديك أفكار يا Peter حول ما تريد تغييره في هذه اللعبة؟
Peter：ربما إضافة المزيد من الزخارف، مثل المنازل والأشجار، لتصبح أكثر حيوية؟
Romain：
حسنًا، سأرسل هذا الطلب، وبشكل أساسي خلال ثوانٍ معدودة سيقوم Codex Spark بالتحرير. سنشاهد التغييرات لحظيًا، وهذا كل شيء. لقد رأينا ظهور أشجار جديدة.
وهذا هو السبب وراء حماسي الشديد من Codex. يمكنك حقًا الحصول على سرعة تفكير مجنونة لبناء أي شيء: أن يكون لديك نموذج رائد مثل GPT-5.4 ويستطيع القيام بمهام معقدة للغاية، مثل تحليل أو ترحيل ملايين الأسطر من الكود. لكن عندما تنبثق منك الإلهامات وتصبح أفكارك واضحة، يمكنك التحول إلى الوضع السريع وحتى إلى Codex Spark، وستحصل على سرعة التفكير هذه لبناء أي شيء.
بالنسبة لمواصفات المنتج، نحن لا نكتب إلا حوالي 10 نقاط رئيسية، وهذا كل شيء
المقدّم Peter：أنا حقًا فضولي لمعرفة كيف يبنون المنتجات باستخدام Codex داخل فريقكم فعليًا. Alex، هل تكتبون مواصفات حتى الآن؟ أم تقومون بجعل GPT يكتب مواصفات؟ وما النموذج الذي تستخدمونه حتى تعمل هذه الأشياء؟
Alex：
أعتقد أننا نكتب في فريق Codex وثائق مواصفات قليلة جدًا جدًا. في الواقع، أرى أن جزءًا كبيرًا من العمل هو جعل الأشخاص الأقرب إلى الواقع يتخذون أكبر عدد ممكن من القرارات، لذلك نكتب المواصفات فقط عندما يتحول الأمر في النهاية إلى نوع من المشكلات التي يصعب جدًا حشرها داخل عقل شخص واحد. بالمناسبة، يمكن لشخص واحد أن يحشر في ذهنه أشياء كثيرة لأنهم قادرون على القيام بالكثير من الأشياء—فهم يفوضون معظم أعمال الترميز. لذا يمكن لشخص واحد الآن أن يفعل الكثير. لكن إذا تحول الأمر في النهاية إلى شيء يحتاج إلى تنسيق بين عدة أشخاص، أو ربما قرارًا صعبًا للغاية يجب اتخاذه، عندها ربما نكتب مواصفة. ومع ذلك، تكون الوثائق التي نكتبها في هذه الحالات قصيرة جدًا جدًا. ما نقوله فقط هو مثل 10 نقاط رئيسية، ثم يتوقف الأمر.
المقدّم Peter：حسنًا. هل تستطيعان أن تعرضا لي كيف يعمل ذلك؟ مثلًا، أعطي Codex بضعة نقاط، ثم ربما يكتب أولًا الاحتياجات الفعلية؟
Romain：
بالطبع! لكن أريد أولًا أن أريك مثالًا أبسط. لنفترض أننا نطوّر تطبيق iOS، وقد اكتمل الآن بعض المهام. لديك فكرة لميزة جديدة في هذا المشروع، لكنك لست متأكدًا من الاتجاه المحدد. هنا تكمن قوة Codex: إذ يمكنه مساعدتنا في التخطيط للخطوة التالية. على سبيل المثال، يكفيني أن أضغط Shift+Tab للدخول إلى “وضع التخطيط” (Plan Mode)، ثم أكتب “ماذا سنبني؟”. عندها سيقوم Codex تلقائيًا بإنشاء خطة أولية. سيحلل قاعدة الكود الحالية، ويفهم الحالة الحالية للمشروع، ويقترح بعض الأفكار المحتملة. وفي الوقت نفسه، يمكنني أيضًا إدخال أفكاري الخاصة وتوجيه النموذج لتوليد خطة أكثر اكتمالًا.
في هذه العملية سترى أن Codex يقدم اقتراحات بناءً على الكود والملفات الحالية. على سبيل المثال، قد يسأل: “هل يجب علينا الاستمرار في تحسين الوظيفة التي ذكرناها سابقًا؟ أم تحسين لوحة موثوقية (reliability dashboard)؟” إذا قررنا تحسين لوحة موثوقية، فسوف يرشدنا أكثر للتفكير: ما الهدف؟ ومن هم المستخدمون المستهدفون بهذا التحسين؟ تشعر وكأنك تعمل مع شريك في جلسة عصف ذهني.
أنا أستخدم هذا النوع من الطريقة كثيرًا لتوليد الأفكار. على سبيل المثال، للتعديلات البسيطة، أدخل prompt مباشرةً ليقوم Codex بتوليد الكود.
Alex：
وبالنسبة للتعديلات المتوسطة التعقيد، قد أجعله يولد خطة محددة، أو يساعدني في استنتاج طريقة التنفيذ. وعندما تكون لدي فكرة غير واضحة، عادةً ما أفتح Codex فقط ليعني بالتفكير في كيفية حل المشكلة. وحتى لو لم تكن لديّ متطلبات واضحة للميزة في ذهني، يمكن لـ Codex مساعدتي على تنظيم أفكاري عبر الأسئلة والاستكشاف.
لكن بصراحة، في بعض الأحيان لا أستخدم مباشرةً الحل الذي يقدمه Codex، خصوصًا عندما يكون التعديل معقدًا. عندها أستكشف باستخدام “وضع التخطيط” في Codex، وأكوّن تصورًا واضحًا، ثم أشارك هذه الأفكار مع فريق المهندسين. في النهاية، تكون عملية التفكير هذه أكثر أهمية من الخطة التي يولدها.
وبالمناسبة، مصممونا يكتبون كودًا أكثر من مهندسي قبل ستة أشهر—وهذا كان غير معقول سابقًا. يعود ذلك أساسًا إلى تقدم الأدوات، ما يمكّن المصممين من المشاركة بشكل أعمق في التطوير. ومع ذلك، كثيرًا ما يمازحني فريقنا بأنني قدمت PR (طلب دمج كود) أقل من العام الماضي. صحيح أن الكثير من التعديلات مجرد تعديلات بسيطة، لكنني أرى أنه ينبغي أن أفعل المزيد.
الآن، لم يعد تركيزنا “هل يمكنه توليد الكود”، لأن الوكلاء (Agent) يمكنهم إنجاز معظم مهام الترميز. والأهم حقًا هو: ماذا قررنا أن نبني؟ وكيف نضمن الجودة العالية للمنتج؟ ولهذا السبب، بالنسبة للميزات شديدة التعقيد، أميل أكثر إلى العثور على مسؤول قوي يتولى قيادتها وإدارتها بدلًا من أن نجعل مدير المنتج (PM) مسؤولًا عن التنفيذ والصيانة لهذه الأنظمة.
المصممون يكتبون كودًا أكثر من المهندسين قبل 6 أشهر
**المقدّم Peter：**تطبيق Codex سهل جدًا وبديهي في الاستخدام. مقارنة ببعض المنتجات الاحترافية الأخرى، أشعر أن منحنى تعلّم Codex أقل بكثير. بعض المنتجات المتخصصة الأخرى تكون قوية، لكنك تحتاج إلى وقت كبير لتعلمها. بل إنني أشعر أنه حتى لو لم أكن أتبع هذه المعلومات على Twitter، ربما لا أكون قادرًا على معرفة كيفية استخدامها أصلًا.
لكن الشيء الذي لفت انتباهي في Codex هو أنه ليس فقط سهل الاستخدام، بل يوفر أيضًا العديد من الميزات المتقدمة مثل skills (المهارات) وautomations (الأتمتة). هل تستخدمون هذه الميزات كثيرًا داخل فريقكم؟
Romain：
نعم، نستخدمها كثيرًا جدًا. وأعتقد أن skills هي واحدة من أكثر الميزات إثارة للاهتمام في تطبيق Codex. مثال: الآن إذا كنت تعمل مع مصمم على Figma، كل ما عليك فعله هو فتح skill لـ Figma لتتمكن مباشرةً من استخراج كل التفاصيل مثل مكونات React والvariables من ملف Figma، وسيتولى Codex تلقائيًا إنشاء الكود المقابل. مثال آخر: إذا كنت تطور تطبيقًا وتريد مشاركته أو نشره على Vercel أو Cloudflare أو Render، يكفي أن تعطي عبر skills تعليمات بسيطة، وسيقوم Codex تلقائيًا بإنجاز هذه المهام.
تحدثت مؤخرًا مع صديق، وأخبرني أنه لديه الكثير من الأفكار لتحسين المنتج. فكتب لـ Codex: “اكتب كل هذه المهام على Linear حتى أتمكن من تتبعها.” عندها استخدم skill الخاص بـ Linear. ثم قال لـ Codex: “سأذهب للنوم الآن، أكمل تنفيذ جميع المهام التي ناقشناها للتو، وقم بوضع علامة مكتملة عليها.” وفي اليوم التالي عندما استيقظ، اكتشف أن كل المهام قد اكتملت بالفعل.
Alex：
فيما يخص بساطة التطبيق الذي ذكرته للتو، أعتقد أنه يمكنني مشاركة كيف نفكر في تصميمه. في هذا المجال، يميل المطورون إلى حب بناء أدوات أتمتة لأنفسهم لتبسيط العمل اليومي. نحن نرى أن إحدى السمات الأساسية للمنتج يجب أن تكون قابلة للتكوين بدرجة عالية. وبالنسبة لـ Codex، فهو يشبه صندوق أدوات مفتوح المصدر يمكن للمستخدم أن يغوص فيه ويخصصه حسب احتياجاته.
في كل مرة نطلق فيها ميزة جديدة، يكون هناك دائمًا مستخدمون على Twitter يشتكون من أن هذه الميزة (حتى لو لم تُطرح رسميًا بعد) لديها مشكلات. والسبب عادةً أنهم هم من عدّلوا الكود أو قاموا بتفرعه fork. لكن بالنسبة لي، هذا هو دليل نجاح منتجنا؛ لأن هؤلاء المستخدمين المتقدمين يقفون معنا في استكشاف المستقبل ويؤثرون على تقدم المنتج.
ومع ذلك، نحن ندرك أيضًا أن بناء منتج لهؤلاء المستخدمين المتقدمين فقط لا يكفي، لأن عندها سيصبح المنتج معقدًا وصعب الفهم. علينا أن نجد توازنًا: أن نلبي احتياجات المستخدمين المتقدمين، وفي الوقت نفسه نجعل المنتج بسيطًا وبديهيًا للمستخدمين العاديين. لذلك نحن نصمم بعناية شديدة الوظائف الأساسية، ونضمن ألا تصبح عائقًا بين المستخدم والنموذج، بل نجعل النموذج أكثر ذكاءً فينجز تلقائيًا المزيد من المهام.
Romain：
ثم انطلاقًا من ذلك نفكر في كيفية تغليف المنتج للمستخدمين المتقدمين بطريقة قابلة للتكوين قدر الإمكان، بحيث يستكشفون ويستخدمونه بأنفسهم. على سبيل المثال، هناك مستخدمون قاموا بالفعل بتنفيذ sub-agents (عملاء ذكاء فرعية). وهذه الميزات ليست شيئًا صممناه نحن عمدًا؛ بل اكتشفها المستخدمون وتجربوا بها بأنفسهم. ومن خلال مراقبة كيفية استخدام المستخدمين لهذه الميزات، تعلمنا الكثير.
بعد ذلك سنفكر: كيف نجعل هذه الميزات سهلة للغاية أيضًا لباقي المستخدمين؟ تطبيق Codex هو مثال ممتاز. حوالي وقت إصدار GPT-5.2 Codex في ديسمبر من العام الماضي، بدأت القدرات بالتثبيت تدريجيًا—لكنها أيضًا تجاوزت نقطة حرجة. يمكن للمستخدمين الآن تفويض مهام أطول وأكثر تعقيدًا للنموذج، ويمكن للنموذج إنجاز هذه المهام مرة واحدة.
بدأنا نلاحظ أن بعض المستخدمين يستخدمون tmuxing (تشغيل مهام متعددة بالتوازي في الطرفية)، وهي طريقة لتقسيم النوافذ في الطرفية لتشغيل مهام متعددة في نفس الوقت. رأينا على وسائل التواصل الاجتماعي أمثلة مثيرة جدًا للاهتمام. على سبيل المثال، صورة لـ Peter Steinberger يظهر فيها على شاشته 18 نافذة طرفية تمتد على ثلاثة شاشات، وكأنها نوع من “مخلب إبداعي مفتوح”. عندما رأينا المستخدمين يستخدمون Codex بهذه الطريقة المتقدمة للغاية، شعرنا بحماس كبير.
وفي الوقت نفسه، واصلنا تحسين ميزات تفويض المهام في المنتج الأساسي مثل CLI، لضمان أنها تعمل بشكل جيد. لكننا أدركنا أن ربما 1% فقط من أفضل المهندسين هم من سيعملون بهذه الطريقة. لذلك فكرنا: كيف نجعل هذه الميزات تبدو أكثر بديهية؟ لهذا السبب طورنا Codex app.
عندما تفتح Codex app لأول مرة، يبدو كنافذة دردشة بسيطة. يمكنك البدء في استخدامه مباشرةً وسيعمل بشكل طبيعي. لكن مع الوقت ستلاحظ المزيد من الميزات: مثل الشريط الجانبي (sidebar)، وإمكانية تشغيل مهام متعددة، وسهولة التنقل بين المهام. ستشعر أنك أصبحت أكثر كفاءة بشكل كبير. ثم قد تلاحظ علامة “skills”؛ تدخل إليها لاستكشاف المزيد من الإمكانيات. نريد أن يشعر المستخدم عند استخدام Codex app وكأنه يلعب لعبة: تكتشف باستمرار إمكانيات جديدة.
Romain：
أتفق تمامًا. والأهم هو أن هذا بالضبط كان جزءًا من رؤيتنا منذ البداية: سيحدث الترميز بطريقة “تفويض وكيل ذكي” (agentic delegation). وحتى قبل ما يقرب من سنة من بدء تطوير Codex، كنا نفكر دائمًا في هذا المستقبل. نحن نؤمن بأن المهندسين سيتمكنون من التعامل مع عدة مهام في نفس الوقت، وسيقوم النموذج بتنفيذ التفاصيل المعقدة.
لكن بصراحة، في ذلك الوقت لم تكن قدرات النموذج قد وصلت إلى هذا المستوى. كنا بحاجة إلى انتظار إصدار GPT-5.2 Codex، وبعد تلك النقطة الحرجة، لنرى أن النموذج يمكنه العمل بشكل شامل وموثوق لساعات وربما لأيام. عندها فقط أدركنا فجأة أن واجهة الطرفية التقليدية لم تعد مناسبة لهذا النوع من العمل. ستشعر بأن فتح تبويبات متعددة في الطرفية وإبقاؤها تعمل لعدة ساعات هو شكل تفاعل غريب جدًا. لذلك احتجنا واجهة جديدة تمامًا، وكان التوقيت مناسبًا.
Alex：
عند مراجعة مسار تطور Codex، مررنا بتحولَين مهمين من نوع “vibe shift” (نقطة انعطاف في الاتجاه). الأول كان في أغسطس من العام الماضي، حيث قدمنا منتج Codex Cloud. كانت فكرة رائعة جدًا وكان المستخدمون حينها متحمسين للغاية، لكن ربما كانت مبكرة قليلًا. لذلك أطلقنا في أغسطس نموذج الترميز التفاعلي الرائع GPT-5، وقررنا التركيز على حل المشكلات التي كان النموذج قادرًا على التعامل معها آنذاك. ومن ثم أطلقنا Codex CLI وإضافات IDE، ونمت قاعدة المستخدمين بسرعة مذهلة—20 إلى 30 ضعفًا خلال بضعة أشهر. كان ذلك رائعًا جدًا.
أما التحول الثاني فكان بين ديسمبر من العام الماضي ويناير من هذا العام. في ذلك الوقت، حققنا أخيرًا الرؤية الأولية—تفويض المهام إلى النموذج. وصلت قدراته إلى مستوى جديد، حيث أصبح قادرًا على إنجاز مهام أكثر تعقيدًا بشكل مستقل. وهذا يمثل دخولنا إلى مرحلة جديدة تمامًا.
يتوزع تخطيطنا إلى قصير المدى وطويل المدى، ولا نفعل التخطيط في منتصف المدى
المقدّم Peter：أنا أتساءل كيف تم تطوير Codex app. هل وضعتم منذ سنة خطة طريق سنوية مثل “نخطط لإطلاق Codex app في وقت ما”؟ أم أنكم اعتمدتم أكثر على مراقبة احتياج السوق وتطوير نماذج أولية بسرعة لأفكار معينة؟
Alex：
في الحقيقة، لا شيء من ذلك. سمعت من الباحث Andre نصيحة رائعة جدًا: في OpenAI، إما نخطط للأهداف قصيرة المدى أو الأهداف طويلة المدى، لكننا لا نفعل التخطيط في منتصف المدى لأن التخطيط في منتصف المدى معقد جدًا.
التخطيط قصير المدى يعني عادةً أهدافًا ضمن مدة لا تزيد عن ثمانية أسابيع من الآن، وهي أطول نطاق زمني يمكننا تحديده. ضمن إطار الوقت هذا، نحدد هدفًا محددًا، ونحشد الفريق كله لإنجازه. هذه إحدى نقاط قوة OpenAI—فنحن بارعون جدًا في تنظيم الفريق حول هدف واضح.
ومن ناحية أخرى، سنضع أيضًا رؤية طويلة المدى. مثلًا، قد نتطلع إلى مستقبل بعد عام، ونتخيل أن النموذج سيكون أكثر ذكاءً. مثلًا، قد نتوقع أن يستطيع النموذج العمل بشكل مستقل دون الحاجة لاستعارة موارد جهاز الكمبيوتر الخاص بنا، وألا يكون مقيدًا بمهمة واحدة فقط في كل مرة. نحن نريد أن يكون لدينا عدد غير محدود من النماذج، يمكن لكل منها إنجاز المهام بشكل مستقل، والتحقق من نفسه من خلال التحقق، وحتى القيام بالنشر والمراقبة تلقائيًا، دون حاجتنا إلى التوجيه اليدوي لها.
لكن التخطيط في منتصف المدى يبدو محرجًا. غالبًا ما يتجلى على هيئة مخطط طريق تفصيلي للمنتج، لكننا بشكل أساسي لا نملك شيئًا كهذا. نحن نعتمد أكثر على دمج الرؤية طويلة المدى والتركيز على مهام محددة تساعدنا على تحقيق أهدافنا.
خذ مثال Codex app. كان أحد أهدافنا الاستراتيجية وقتها هو تحرير المستخدمين من مساحة عمل محددة (workspace). عادةً تكون أدوات التطوير التقليدية (مثل VS Code) مقيدة بمساحة عمل معينة، مثل نقطة تحقق محددة في مستودع كود أو مجلد محدد. حتى مع git worktree، لا يمكن فتح أكثر من دليل عمل واحد في كل مرة، وCLI له قيود مماثلة.
لكن رؤيتنا كانت: أن يستطيع المستخدمون التعاون مع وكلاء ذكيين في السحابة (agent)، ويمكن لهؤلاء الـ agent العمل بشكل مستقل. نريد أن يتفاعل المستخدم مع عدة agent في وقت واحد، وحتى أن يقوم agent واحد بالتنسيق نيابةً عن المستخدم لمهام عدة agent أخرى. وينبغي أن تكون تجربة المستخدم هذه طبيعية وبديهية.
وفي الوقت نفسه، أدركنا أنه إذا اعتمدنا بالكامل على السحابة من البداية، فقد يجد المطورون ذلك غير مريح، لأنهم سيحتاجون إلى إعداد بيئات، وعندما ينفّذ النموذج مهامًا، فإن الحاجة إلى تدخل يدوي أو تعديل قد يجعل الأمور أكثر تعقيدًا.لذلك قررنا تطوير تجربة محلية (local) تمكن من التعاون بسلاسة مع المجلدات المحلية، وفي الوقت نفسه الحفاظ على اتصالها مع الوكلاء الذكيين في السحابة.
عندما بدأنا تطوير هذا التطبيق، كانت لدينا مجموعة من “أفكار الرؤية” هذه—وهي أفكار مجردة نسبيًا. وفي الوقت ذاته، كان مهندسونا يقومون بتجارب ونماذج أولية. كانوا يقولون: “أتمنى أن يكون لدينا تطبيق.” وهكذا بدأوا في محاولة تطوير نسخ مختلفة. في الواقع، نظمنا “أسبوع هاكاثون” (hack week)؛ حيث قام عدة مهندسين بتطوير نسخ مختلفة من التطبيق بشكل مستقل. قد تكون شاركت، لكن لا أتذكر.
عندما بدأ المشروع رسميًا، كان الشيء الوحيد الذي كان علينا تدوينه بوضوح هو: لماذا نعتقد أن تطوير تطبيق فكرة جيدة. لم نضع لهذا التطبيق مواصفات منتج محددة؛ بل اكتشفنا اتجاه المنتج تدريجيًا من خلال عمل التطوير الفعلي.
لكن في ذلك الوقت كان المشروع مثيرًا للجدل بعض الشيء—هل نحتاج فعلًا لتطوير تطبيق؟ كان لدينا إضافة IDE تحظى بشعبية كبيرة، فهل يجب أن نركز على تحسين جودة الإضافة؟ وCLI لديه إمكانات. إذًا، إذا كنا سنطوّر تطبيقًا، فما معنى ذلك؟ وأي اتجاه ينبغي أن ن努力 فيه؟ هذه كانت بعض الأسئلة التي واجهناها عند بدء المشروع.
Romain：
نعم، لحسن الحظ، كان لدينا بالفعل حل إضافة IDE ناضج جدًا، وقمنا بتحسينه بعمق. يمكن للمستخدمين استخدام هذه الإضافات في VS Code وCursor وWindsurf وغيرها من بيئات التطوير. لقد جمعنا الكثير من الخبرة من قاعدة كود إضافات IDE، وهذا وفر نقطة انطلاق قوية جدًا لتطوير Codex app.
Alex：
صحيح. في الواقع، Codex app وإضافة IDE يشتركان في كمية كبيرة من الكود في الطبقات الأساسية. كلاهما يتصل بـ نفس “core Codex harness”، وهو إطار عمل مفتوح المصدر مكتوب بلغة Rust، وCLI يستخدمه أيضًا. كان ذلك قرارًا مقصودًا لتبنّي تصميم طبقي، من أجل مشاركة الكود بين أدوات مختلفة وتوسيع الوظائف.
المقدّم Peter：بالنسبة لعملية اتخاذ قرار تطوير Codex app… إذا نظرنا إلى الأمر الآن، يبدو قرارًا بديهيًا، لأن استخدام Codex app أكثر وضوحًا بكثير من فتح كومة من نوافذ الطرفية. لكن السبب الذي جعلنا نتخذ ذلك القرار وقتها كان أساسًا: Codex app أكثر ودية للمبتدئين، كما أنه أفضل واجهة لإدارة تنسيق عدة وكلاء أذكياء يعملون معًا.
Alex：
أعتقد أن طريقة تفكير فريقنا متأثرة بشدة برؤية AGI (الذكاء الاصطناعي العام). كنا نفكر دائمًا: كيف ستكون طريقة العمل في المستقبل؟
لكن إن قلتها من زاوية أخرى، نحن نعرف أننا نحتاج واجهة، تمكّن المستخدمين من تفويض المهام بشكل طبيعي إلى عدة وكلاء أذكياء. نعلم أن النماذج المستقبلية ستمتلك هذه القدرة—في الواقع، رأينا المستخدمين بالفعل يحاولون تفويض المهام بين الوكلاء الأذكياء. نحتاج واجهة تجعل هذا النوع من التعاون يبدو منطقيًا، ويمكنها أيضًا التوسع بسلاسة إلى السحابة.
نريد لهذه الواجهة أن تتماشى مع تصميم مريح (ergonomic)، بحيث يشعر المستخدم أن التعاون مع عدة وكلاء ذكيين تجربة بديهية وطبيعية، وليست شيئًا يتطلب عمليات معقدة أو حيلًا.
Romain：
نعم، وأيضًا فإن جمهور هذا التطبيق ليس المبتدئين فقط. في الواقع، حتى كبار المهندسين الأكثر خبرة ودراية—بما في ذلك أفضل مهندسين داخل OpenAI، مثل Peter وOpenClaw وGreg Brockman—بدأوا باستخدام Codex app كأداة تطوير رئيسية. هذا يوضح أن** رؤيتنا لتفويض الوكلاء الذكيين (agentic delegation) تتحقق تدريجيًا.**
Alex：
نعم. نحن ذكرنا Peter لأنه انضم للتو إلى OpenAI، وكنا متحمسين جدًا لذلك. في أكتوبر من العام الماضي، أثناء نزهة مشيًا معًا في Fort Mason في سان فرانسيسكو، تحدثنا عن فكرة تطوير واجهة جديدة. قلت إننا نريد واجهة تجعل التفويض (delegation) أكثر طبيعية، وخبرني حينها أنه لن يستخدم شيئًا كهذا أبدًا.
لكن في عطلة نهاية الأسبوع الماضية، نشر تغريدة قال فيها: “بصراحة، هذا التطبيق جيد جدًا. لقد بدأت أحبّه الآن.”
محتوى العمل اليومي لـ Alex كمدير منتجات (PM) في Codex
المقدّم Peter：Alex، لقد عملت لفترة في فريق Codex كمدير منتجات (PM) الوحيد، صحيح؟ الآن كم عدد الأشخاص في فريق Codex؟ هل هو تقريبًا بين 50 و100؟
Alex：
حوالي ذلك، ضمن هذا النطاق. في شهر مايو كنا حوالي 8 أشخاص فقط، ولا أتذكر الرقم بدقة. لكن منذ ذلك الحين نما فريقنا بسرعة كبيرة، والآن نحن تقريبًا بين 50 و100 شخص.
المقدّم Peter：فكيف توزع وقتك عادةً؟ كيف يبدو عملك اليومي؟ أم أنك لا تملك يوم عمل نمطي أصلًا؟
Alex：
كنت أفكر في هذا السؤال أيضًا مؤخرًا، لأنني وجدت صعوبة في الإجابة. أدركت أن** نمط عملي عبارة عن مراحل،** وهذه طريقة خاصة بي وقد لا تناسب الجميع.
على سبيل المثال، عندما أطلقنا Codex app، كنت تمامًا في وضع التنفيذ (execution mode). في ذلك الوقت كانت كل طاقتي موجّهة إلى جودة المنتج، وأتأكد أننا لم نترك أي تفاصيل دون معالجة، وأن كل شيء صغير تم إنجازه بدقة. في وضع كهذا، أقضي وقتًا طويلًا في استخدام أدوات Codex.
سنستخدم Codex للحصول على تعليقات، مثل فهم النقاشات على Slack وردود المستخدمين. أجعل Codex يلخص هذه المعلومات ثم أسجلها في Linear. بالإضافة إلى ذلك، أستخدم Codex لتحليل جودة الكود وأجري تعديلات صغيرة مباشرةً باستخدامه. لأن بعض الأحيان، معالجة مشكلات صغيرة مباشرةً باستخدام Codex أسرع من تنسيق العمل مع الآخرين وجعلهم يحددون الأولوية، خصوصًا عندما يكون هدفنا إطلاق التطبيق خلال أسبوعين.
وبطبيعة الحال، هناك أعمال بشرية تتخلل ذلك أيضًا، مثل التشجيع والتحفيز وتبني موقف نقدي تجاه المنتج الذي نطوّره. اكتشفت أيضًا أن قدرتي على تحديد ما إذا كنت في وضع التنفيذ يمكن استنتاجها من مدى استخدامي لـ Twitter بشكل متكرر. لا أعرف لماذا، لكن عندما أحتاج للتواصل مع الناس، أستخدم Twitter أكثر.
وهناك وضع آخر أيضًا. على سبيل المثال، الآن في ذهني واضح جدًا: لقد وصلنا إلى مرحلة جديدة. لدينا نماذج قوية جدًا مثل GPT-5.4 التي تؤدي بشكل رائع. وتجربة التطبيق لدينا تجاوزت التوقعات—وقد غطت كل المنصات بما في ذلك Windows. لذا أشعر أنه حان الوقت للعودة بجدية إلى السحابة (cloud) والاستثمار فيها أكثر.
عندما ندخل هذه المرحلة، أقضي وقتًا أطول في التفكير بما الذي يجب فعله بعد ذلك وفهم الوضع الحالي—وهذا يُعد وضع تنسيق. في هذا النمط، يكون وقتي على Codex أقل، ويكون استخدامي لـ Codex أكثر للتواصل بدلًا من كتابة الكود. لذلك أعتقد أن لدي على الأقل نمطين من العمل، ومن الممكن أن يكون هناك المزيد.
المقدّم Peter：كم قدر العمل المطلوب للتوافق عبر التخصصات (cross-functional alignment)؟
Alex：
لا نحتاج تقريبًا إلى الكثير من التوافق عبر التخصصات داخل الفريق. لقد جعلنا أنفسنا بشكل مقصود أشبه بفريق مثل “سفينة القراصنة” (sea pirates). حتى داخل فريق Codex نفسه، لا يوجد سوى أنا ومديرا منتجين جديدين انضما حديثًا. لدينا بعض المسؤولين، صحيح أنه حتى الآن كان الجميع تقريبًا يقدمون تقارير مباشرةً لي، لكننا نُحرّك المشروع معًا بطريقة “غير محددة” قليلًا، لذا لا يوجد الكثير من أعمال التوافق داخل الفريق.
لكن أصبح واضحًا أكثر فأكثر أن جزءًا مهمًا من بناء Codex يتمثل في تطوير coding agent. والأمر صار واضحًا أيضًا أن coding agent لا يمكنه فقط كتابة الكود، بل مفيد جدًا أيضًا في مهام أخرى.
على سبيل المثال، اكتشفنا أن المستخدمين لا يستخدمون Codex app فقط لكتابة الكود. بل يستخدمونه لإنجاز مهام مختلفة عبر دورة تطوير البرمجيات بالكامل. والآن معظم موظفي OpenAI يستخدمون Codex app، حتى لو كانوا غير تقنيين؛ وغالبًا ما أرى أن هؤلاء الأشخاص يستخدمون التطبيق أيضًا.
هذه المعرفة تجعلنا ندرك أننا بحاجة إلى التفكير في كيفية جعل Codex مفيدًا ليس للمطورين فقط. وهذا يعني المزيد من التوافق عبر التخصصات، لأننا في OpenAI لدينا ChatGPT، وكثير من المستخدمين يستخدمونه أيضًا. لذا نحتاج إلى إيلاء اهتمام شديد لكيفية دمج هذه المنتجات بشكل أفضل.
Romain：
من وجهة نظري، فريق تجربة المطورين (DevX) أصبح يشبه نوعًا ما امتدادًا لفريق Codex. معظم وقتنا وجهدنا يذهب إلى Codex، ولأسباب عدة.
أولًا، إنه منتج مثير جدًا. ويحب المطورون استخدام Codex. نريد أن نجعله أفضل. كما قال Alex، أسلوب عملنا أيضًا على شكل مراحل. فنحن نستعد مع فريق Codex لإطلاق المنتج، مثل تجهيز المواد المطلوبة للإطلاق وتدريب المطورين على كيفية تعظيم الاستفادة من Codex. بعد الإطلاق، نوجه المطورين لاستكشاف تطبيق Codex في سيناريوهات مختلفة.
والشيء الآخر الذي يجعلنا متحمسين جدًا هو أنه إذا نظرت إلى منصة OpenAI بأكملها، فاليوم هناك ملايين المطورين يستخدمون API الخاص بنا، لبناء تطبيقات متعددة الوسائط (modalities) مثل من الصور إلى الصوت وغير ذلك.
أفضل طريقة للتطوير الآن أصبحت هي استخدام Codex كمدخل (entry point). قبل سنة تقريبًا، أو حتى عندما أطلقنا GPT-5 في صيف العام الماضي، كنا نحتاج لكتابة الكثير من الأدلة لإرشاد الناس حول كيفية صياغة prompts لـ GPT-5. GPT-5 نموذج يتمتع بقوة استدلالية كبيرة، ومختلف جدًا عن GPT-4. والآن نحاول جعل المطورين قادرين على إنجاز المهام حتى في هذه الاستخدامات عبر Codex وskills.
على سبيل المثال، إذا كنت بحاجة إلى تحديث نظام تكامل (integration)، فسنقترح عليك استخدام Codex وميزة skills الخاصة به. ونتيجة لذلك، يمكن لـ Codex أن يساعدك في إنجاز المهمة تقريبًا بالكامل. لذلك أيضًا يولى فريقنا اهتمامًا كبيرًا للتعاون عبر التخصصات، ويعتبر Codex حجر الأساس لمنصة تطوير المطورين في OpenAI.
Alex：
أعتقد أن هناك سمة مميزة جدًا في طريقة عمل فريق Codex—بالنسبة لي، أفضل جزء هو** التفاعل مع المجتمع (community).** سواء عبر الإنترنت أو في فعاليات داخل العالم الحقيقي، نحن نركز كثيرًا على الارتباط بالمجتمع.
عند إطلاق المنتج، نحن نعمل بطريقة** موجهة نحو الإطلاق**—أي نحدد بوضوح متى سنطلق وما سنطلقه؛ وفي الوقت نفسه نحن** موجهون نحو الملاحظات**—نستجيب بسرعة عندما يقدم المجتمع تعليقات، فنصلح المشكلات ونتواصل معهم. لذا كان فريقنا دائمًا “نشطًا” على الإنترنت، وأعتقد أن هذا مهم جدًا.
على سبيل المثال، عندما أطلقنا Codex app، تعاونّا عن قرب مع Dom وفريقه. ساعدونا في تنظيم اختبار alpha واسع النطاق ودعوة عدد كبير من المستخدمين للمشاركة وتطوير المنتج سويًا. وبفضل تعليقاتهم، لم نُحسن التطبيق فقط، بل صقلنا أيضًا الموارد ذات الصلة مثل skills والوثائق.
أعتقد أن هذه هي ميزة فريق Codex الفريدة: لأننا open-source، فنحن نحافظ على شفافية عالية تجاه كل ما نقوم به، والمجتمع يمنحنا دعمًا واسعًا وردود فعل كبيرة على هذا النهج.
المقدّم Peter：لنحَدث عن Peter (مؤسس OpenClaw). أنا من المستخدمين الأوائل لـ OpenClaw. كيف دمجتم Peter في الفريق؟ هل رؤية هذا الـ personal agent مرتبطة بما يفعله حاليًا؟ وكيف خططتم لذلك؟
Alex：
هناك جانبين يمكن الحديث عنهما. أولًا، Peter هو مستخدم شديد الاستمرار جدًا لـ Codex. في الواقع، تم بناء OpenClaw إلى حد كبير باستخدام Codex. من خلال خبرته الشخصية في الاستخدام، قدم كميات كبيرة من الملاحظات للفريق، وقد ساعدت هذه الملاحظات بشكل كبير في تحسين Codex. ومع أنه مجرد “兼职” من حيث الوقت، لكنه كان ملتزمًا للغاية، وهذا جعلنا متحمسين جدًا.
ثانيًا، لا يمكنني الكشف عن تفاصيل كثيرة الآن، لكن يمكن القول إن هو يساعدنا في بناء الجيل القادم من personal agent (الوكيل الشخصي) ودمجه مباشرة في ChatGPT.
Romain：
أكثر ما يثير دهشتي في عمل Peter هو أنه عندما يستخدم الناس OpenClaw، قد تكون لديهم نظرة ولو جزئية للمستقبل، لكن الذي صدمني هو أن Peter رأى هذه الرؤية منذ وقت مبكر جدًا.
إذا نظرت إلى مجمل 2025، فخلال العام الماضي طوّر أكثر من 40 مشروعًا مفتوح المصدر، وكلها كانت تتمحور حول رؤية أساسية: الوصول إلى أدواته الشخصية مثل التقويم والتغريدات وGmail عبر واجهة سطر الأوامر (CLI). ومن خلال هذه المشاريع، حول فعليًا رؤية skills وأدوات CLI إلى واقع. والـ coding agent الذي نستخدمه اليوم مبني على هذه الرؤية.
في المستقبل، لن يكون هذا agent مجرد أداة برمجة؛ بل سيصبح أي نوع من personal agent (وكيل شخصي). لذلك قدم Peter لنا ردود فعل قيمة جدًا في هذه العملية، لأنه طوّر بالفعل العديد من الأدوات التي أصبحت الآن جزءًا محوريًا من النظام البيئي مفتوح المصدر.
المقدّم Peter：
أعتقد أن أشخاصًا مثل Peter، الذين يستطيعون بناء مجتمع open-source بهذه الجودة العالية، أمر يستحق الإعجاب. أدواته مفيدة لدرجة أنني لا أريد فتح أي تطبيق آخر—أريد فقط الدردشة مع روبوتي الصغير.
Alex：
ماذا ربطته بنظام ما؟ هل ربطته بكل شيء؟
المقدّم Peter：
نعم، ربطته بعدد كبير من الخدمات. مثلًا يمكنه الوصول إلى معلوماتي البنكية وحساب YouTube ومساعد الصوت والتقويم وخدمات Google. عندما أكون مستلقيًا في السرير، تسألني زوجتي: “مع من تتحدث؟” فأجيب: “أنا أتحدث مع روبوت OpenClaw الخاص بي.”
لكن الآن، توجد الكثير من “المحتالين” يتقاضون ما يصل إلى 5000 دولار لمساعدة الآخرين على إعداد OpenClaw. لذلك إذا استطعتم جعله أكثر انتشارًا وأسهل في البداية، فهذا سيكون إنجازًا كبيرًا. أنتم بالفعل تتحركون في الاتجاه الصحيح.
لم تعد السلم الوظيفي التقليدي مناسبًا
المقدّم Peter：أتذكر أنك قلتوا شيئًا قريبًا من: “الآن لم تعد أغلب الفرق بحاجة إلى الكثير من PM”؟
Romain：
أعتقد أن أكثر شيء يدهشني حول هذه الأدوات هو أنها ليست مجرد مسألة PM أو هل نحتاج PM أم لا. إنها تجعل تقريبًا كل درجات السلم الوظيفي التقليدي تبدأ بالاندماج والاضمحلال. كان لدينا سابقًا تقسيم واضح للأدوار: المصمم مسؤول عن التصميم، والمهندس مسؤول عن التطوير، وPM مسؤول عن الإدارة، وربما توجد نسبة محددة نوعًا ما، مثل “النسبة الذهبية”.
لكن الآن، إذا كنت مهندسًا، فإن إنتاجيتك ترتفع بشكل ملحوظ. وإذا كنت مصممًا، يمكنك الحصول على “قوى خارقة” عبر هذه الأدوات، مما يجعلك أكثر تقنية. وإذا كنت مدير منتج (PM)، فبدلًا من أن يكون عملك مجرد كتابة وثائق استراتيجية، يمكنك الآن عمل نماذج أولية مباشرةً. هذا لا يعني أنك تحتاج لتحمل مسؤولية عن ميزة لمئات الملايين من المستخدمين، لكنك بالتأكيد تستطيع استخدام هذه الأدوات لتبني أشياء حقيقية، وتعرض رؤيتك للفريق.
لذلك، أكثر شيء يدهشني هو: أن الحدود بين جميع السلالم الوظيفية أصبحت تلْتبس. فنحن كلنا في الحقيقة ‘مُنشئون’ (builders)، ويعمل الجميع معًا لبناء الأمور.
Alex：
أتذكر أنني قلت في مكان ما على الإنترنت إنه إذا كان لدى شركة ناشئة PM وكان عدد المهندسين أقل من حوالي 20، فقد يكون ذلك إشارة خطر. ربما قلت فعلًا شيئًا مثل ذلك.
وأعتقد مثلما قلت أنت، كل هذه الأدوار تتداخل تدريجيًا. المصمم يمكنه القيام بمزيد من الأعمال الهندسية، والمهندس يمكنه دخول مجال التصميم، وPM يمكنه المشاركة في البناء. لكن المهندس عادةً ما يحتاج أن يركز على كتابة الكود، لذلك كان من غير المعتاد أن يتعامل مع فرز المهام أو غيره من أعمال إدارة المشاريع التي يقوم بها PM.
لكن الآن هذه الأمور أصبحت سهلة جدًا. يمكنك أن تفوّض agent، مثل Codex، لتحليل التعليقات والأولويات، وبذلك ستحرر المهندسين من وقت كي يركزوا على أعمالهم. وأنا أعتقد أن الجميع الآن يمكنهم أداء عمل الآخرين.
طرح Scott Belsky فكرة اسمها “collapse the talent stack” (انهيار كومة المواهب). أحب هذا الطرح، وأشعر أنه بالفعل يحدث. كلما احتجنا إلى أشخاص أقل في الغرفة، كلما أصبحت الأمور أسهل في التقدم، وكل قرار يصبح أوضح.
لذا تصبح القضية: ماذا يستطيع PM أن يفعل بعد ذلك؟ أعتقد أن هناك الكثير من PM ينبغي عليهم التفكير في التحول إلى دور آخر. مثلًا، إذا كنت PM وتملك رغبة دائمة أن تصبح مهندسًا، لكنك أفضل في إدارة الناس ولا تتمتع بقدرة هندسية قوية، فقد تكون الآن فرصة أن تصبح engineering manager (مدير هندسي). مع الوكلاء الذكيين، قد يصبح هذا دورًا أكثر وضوحًا لك. وبالمثل، بعض الـ PM قد يميلون أكثر لأن يصبحوا مصممين—أي أن يكونوا أقرب إلى العمل الفعلي في البناء.
وأعتقد أن ذلك يعتمد في النهاية على اهتمام الشخص. بالنسبة إلي، الحماس والاستقلالية هما أكثر صفات البشر جوهرية وأهمية في عصر AGI. لذلك، إذا كان اهتمامك هو كتابة الكود، وكان دخولك لهذا الدور سابقًا سببه أن أحدًا ما كان يجب أن يقوم بعمل PM، فيمكنك الآن أن تتحول تمامًا إلى مهندس وتتابع إنجاز نفس الأشياء من زاوية هندسية. مجال التصميم مشابه كذلك.
لكن إذا كان اهتمامك الحقيقي هو التفاعل مع المستخدمين، حتى لو أدى ذلك إلى إبعادك عن العمل الفعلي في البناء—كأن تحاول فهم احتياجات المستخدمين واستشراف اتجاهات السوق—فعند وجود فريق كبير بما يكفي، لا يزال لدى PM مساحة للعب دور مفيد.
Romain：
سأضيف نقطة أخيرة: أنا ما زلت أعتقد أن كل مجال من المجالات يحتاج إلى شخص بشري مسؤول عنه، لكن لا أعتقد أن هذا الشخص بالضرورة يجب أن يكون PM. يعتمد ذلك بدرجة كبيرة على طبيعة المنتج.
نحن محظوظون هنا لأننا نعمل على Codex، وهي أداة موجهة للمطورين. نحن أنفسنا المستخدمون الأفضل. وبما أنها open-source، نستطيع التواصل مباشرةً مع المجتمع والقيام بتطوير مشترك.
لكن لو عدنا إلى عشر سنوات مضت مثلًا—عندما كنت أعمل في Stripe—كان لدى الشركة 250 شخصًا، ومع ذلك لم يكن لدينا أي PM، ولا حتى أي أدوات AI. لماذا؟ لأن Stripe منتج API، وكان كل شخص تقريبًا مهندسًا، ولديه فهم حدسي جدًا لما يجعل API جيدًا. كنا نبني بالضبط API الذي نطمح إليه: حل أنيق يمكن تحقيقه عبر بضعة أسطر فقط من الكود.
لكن إذا كنت في مجال مختلف، مثل أن حدس المهندسين لاحتياجات المستخدمين ليس كافيًا، فحينها قد تحتاج إلى المزيد من PM للتواصل مع العملاء وفهم احتياجاتهم. وخاصة عندما لا تتطابق طبيعة الصناعة أو المجال الذي تخدمه مع حدس المهندسين بشكل كامل، تصبح وظيفة PM أكثر أهمية. ومع ذلك، نحن محظوظون جدًا داخل فريق Codex لأننا نبني أداة نريد نحن أنفسنا استخدامها.
Alex：
في هذا النوع من البيئة، قد يكون دور PM مجرد بطاقة تُشير إلى الشخص الأكثر اهتمامًا بالمستخدم واحتياجاته، وهذا الشخص قد يكون في الواقع مهندسًا قريبًا جدًا من المستخدم. لذا أعتقد أن بطاقات المهنة هذه تفقد تدريجيًا معناها التقليدي، وحتى لو كان الأمر يبدو قليلًا من الفوضى، فليس هذا أمرًا سيئًا.
المقدّم Peter：
وجدت شيئًا مشابهًا داخل فريقي. أفضل المهندسين لا يسألونني “ما الذي ينبغي أن نبنيه بعد ذلك؟”. هم يذهبون بأنفسهم للتحدث مع المستخدمين، يفهمون ما يجب تطويره، ثم يناقشون ذلك معي. بهذه الطريقة تتوافق الأهداف بشكل كبير.
Romain：
هذا هو بالضبط أسلوب عمل فريق Codex. العديد من الميزات التي تستخدمها اليوم داخل Codex app هي في الواقع أفكار عبقرية اقترحها مهندسون من الأسفل إلى الأعلى (bottom-up)، لأنهم أنفسهم يحتاجون لهذه الميزات.
Alex：
لكنني أريد أن أقول إن هناك نوعًا من المهندسين أحب التعاون معه. إنهم يحبون التحدث مع المستخدمين والتفكير فيما ينبغي بناؤه من ميزات. هؤلاء الأشخاص عادةً يكونون ممتازين أيضًا في بناء الأنظمة: سرعة وقدرة عاليين، وفكر واضح. لكن هناك أيضًا مهندسون ليس لديهم أي اهتمام بالتفاعل مع المستخدمين—فقط يريدون التركيز على بناء الأنظمة. وأعتقد أن هؤلاء لديهم أيضًا مساحة كبيرة للنمو.
مرة أخرى، هذا هو رأيي في عصر الذكاء الاصطناعي: يمكن للجميع أن يصبحوا “على طبيعتهم” أكثر. سيساعدك الذكاء الاصطناعي والفريق في القيام بالأشياء التي لا تريد القيام بها، حتى تركز على اهتماماتك ومزاياك.
المقدّم Peter：
أعتقد فعلًا أن تسمية “builder” (مُنشئ) مهمة جدًا. أعتقد أن كثيرًا من PM يريدون أن يصبحوا قادة، لكن السلم الوظيفي التقليدي هو أنه عندما تصبح VP أو ما شابه، لن يكون لديك وقت للبناء. تقضي يومك كله في مراجعات المنتج، وتقدم فقط بعض الملاحظات دون وقت لتطوير شيء فعليًا. أعتقد أن كثيرًا من PM لا يريدون أن يكونوا في هذا الوضع. أريد أن أبقى قريبًا من المستخدمين، وأن أطلق المنتجات فعليًا.
Alex：
أتفق تمامًا. وأنا فعلًا لا أرى PM كدور قيادي. أميل أكثر إلى اعتباره دورًا لـ “سد الفجوة” (filling the gap). أحيانًا قد يحتاج هذا الدور لتحمل مسؤوليات قيادية معينة، لكن حتى حينها، فغالبًا ما تكون القيادة لمساعدة الفريق على الوصول إلى اتفاق، وليس مجرد الاعتماد على شخص واحد ليقترح حلًا عبقريًا.
هناك شيء واحد يمكنني التأكد منه: في OpenAI، أفضل PM هم من يغوصون في تفاصيل التنفيذ بعمق. وأعتقد أن الانضمام إلى OpenAI عبر منصب قيادة رفيع يعد تحديًا كبيرًا جدًا، لأن الثقافة هنا ما زالت تؤكد على الاهتمام بالتفاصيل. لذلك، أفضل طريقة هي أن تغوص في التفاصيل منذ البداية.
ما الذي يوليها فريق Codex أهمية عند التوظيف؟ (والإجابة ليست سيرتك الذاتية)
المقدّم Peter：عندما تقومون بالتوظيف لفريق Codex، بالإضافة إلى شرط أن يكون المرشح مستخدمًا شديدًا لـ Codex، ما الصفات الأخرى التي تركزون عليها؟
Alex：
لقد ذكرت سابقًا أنني أولي اهتمامًا كبيرًا بـ** استقلالية المرشح (agency).** نريد أشخاصًا يبادرون ويتخذون الخطوة بأنفسهم—وهذه من أهم الصفات.
في OpenAI، خصوصًا في فريق Codex، ثقافتنا ليست من النوع الذي يقول: “مرحبًا بك! بعد دخولك، سنعطيك 12 مهمة مرتبة تزداد صعوبتها تدريجيًا”. أسلوبنا أقرب إلى: “مرحبًا بك! والآن ابدأ الاستكشاف.”
لذلك نميل إلى البحث عن الأشخاص** ذاتيين التحفيز**—لديهم دافع للفعل، ولديهم أفكارهم الخاصة، ويعرفون ماذا يريدون أن يفعلوا، ولا يخافون من تحدي الأفكار القائمة. لأن بصراحة، بعض الأفكار الحالية قد تكون خاطئة في حد ذاتها، أو قد تكون مجرد قرار عابر اتخذناه من قبل.
شريكي المثالي في الفريق هو من يكون مستعدًا لتحمل مسؤوليات إضافية، وحتى مسؤولية مجال غير معروف. هذه الصفات تحديدًا هي ما نوليه اهتمامًا كبيرًا. أما المهارات المحددة، فنحن نميل عادةً لتفضيل المرشحين ذوي القدرات التقنية القوية، المرتبطة بالهندسة.
Romain：
أتفق تمامًا. في فريق تجربة المطورين (DevX)، غالبًا ما أبحث عن أشخاص لديهم استقلالية عالية. يجب أن يكونوا أقوياء جدًا من الناحية التقنية، وأن يبرعوا خصوصًا في استخدام أدوات مثل Codex. لكن بالإضافة إلى ذلك، أبحث أيضًا بشكل خاص عن الأشخاص الذين لديهم شغف للعمل مع المطورين والمُنشئين (builders) ومشاركة المعرفة.
مثلًا، هذه الأسبوع قمنا بالإعلان أن Thomas سيُنضم إلى فريقي. وهو الشخص الذي طور open-source Codex monitor. ليس مبدعًا فقط، بل هو أيضًا مستخدم شديد لـ Codex ومتحمس لمشاركة كيف يستفيد من Codex لبناء أدوات.
نحن نحتاج هذا النوع من المواهب لأننا نحاول قيادة ملايين المطورين إلى المستقبل المشرق الذي يمثله Codex. أنا أؤمن أن agentic coding (البرمجة عبر الوكلاء الذكيين) يغير جذريًا الطريقة التقليدية التي نفكر بها في تطوير البرمجيات وبناء التطبيقات والمنتجات. هدفنا هو إظهار هذا الاحتمال للعالم كله، ومساعدة المطورين على تعلم كيفية استخدام هذه الأدوات لتحقيق إبداعاتهم الخاصة. وهذه هي الصفات التي نبحث عنها.
Alex：
سأضيف شيئًا: من وجهة نظري، يمكن وصف المرشح المثالي لفريق DevX ب