مسؤول Codex: «الجميع هو باني» فكرة سيئة للغاية

أندرو أمبروسينو هو قائد فريق OpenAI Codex. خلفيته كمصمم، وعمل كمهندس ومنتج، وأسس شركات ناشئة. الآن يدير Codex الذي يتجاوز عدد مستخدميه النشطين أسبوعيًا 5 ملايين. ربما هو الشخص الأنسب للإجابة على سؤال "كيف يجب صنع المنتجات في عصر الذكاء الاصطناعي".

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

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

بعض الأفكار الأساسية:

عندما يستطيع 90 شخصًا صنع 90 نموذجًا أوليًا يبدو قابلاً للإطلاق، فإن أثمن شيء هو الذوق (taste).

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

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

ما إذا كانت الميزة جيدة بما فيه الكفاية في النهاية، غالبًا لا يعتمد على شكل الميزة نفسها، بل على مدى ذكاء النموذج.

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

فيما يلي جوهر المحادثة.

عندما تنخفض تكلفة التنفيذ، يصبح الذوق أكثر أهمية

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

أندرو أمبروسينو: الآن، كقائد فريق، أصعب شيء هو انعكاس العملية.

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

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

عندما تعطي الناس رموزًا غير محدودة، كل شخص في OpenAI استباقي ولديه أفكار جيدة. لذلك، كل شخص يصنع أشياء مختلفة. الآن هناك ميزة نحتاجها بشدة في الشركة، وأنا متأكد من أن هناك 90 فريقًا صغيرًا غير منسق يعملون على تنفيذها ومحاولتها بشكل منفصل. من بين هذه المحاولات الـ 90، أيها جيدة؟ أي أجزاء يجب دمجها في جوانب أخرى؟ كيف يجب تعريفها؟ هل يجب أن تكون جزءًا من ميزة أخرى؟ كم عدد الخيارات في المفتاح؟ هذه هي الأمور.

لذا، الإجابة المختصرة هي: انعكس الأمر. ليس أن الناس يقومون بأدوار مختلفة تمامًا، ولا أن المهارات اختفت أو أن الأدوار لم تعد موجودة. لم يعد التنفيذ هو الجزء الأغلى، وسأجرؤ على القول إن الأغلى هو الذوق (taste).

ليني: إذن، في السابق كان الناس يكتبون PRD ووثائق إستراتيجية، والآن يصنعون نماذج أولية مباشرة. هناك الكثير من الأشخاص في الشركة لديهم أفكار مماثلة، فتظهر 90 شيئًا مختلفًا، ثم تختار الاتجاه من بينها؟

أندرو أمبروسينو: نعم، هذا يحدث كثيرًا. ليس فقط في OpenAI، لقد رأيت بالفعل العديد من قادة المنتجات يقولون "PRD مات، النماذج الأولية هي السائدة"، لكنني في الواقع لا أوافق على ذلك تمامًا.

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

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

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

ليني: هناك مفهوم يسمى "العلامة البدائية" (primal mark)، أول ضربة فرشاة يضعها الرسام على القماش، وكل شيء بعده يمتد من تلك الضربة. هل تعني أن النموذج الأولي أحيانًا يكون الضربة الأولى الخاطئة؟ لأن الناس سيتمسكون به، بدلاً من التفكير في الحل الأكبر؟

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

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

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

ليني: كلمة "ذوق" أصبحت شائعة الآن. على وجه التحديد، ما هو "الذوق الجيد" الذي تعنيه؟

أندرو أمبروسينو: يجب تفكيك الذوق.

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

هذه الأمور مهمة جدًا بالفعل، لكن مشكلة الذوق الحقيقية هي: إذا كان بإمكاننا فعل أي شيء، ما هو الهدف؟ كيف نصل إلى هناك؟

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

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

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

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

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

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

ليني: جيني وين (رئيسة تصميم Claude Code من Anthropic) قالت إن عملية التصميم ماتت، فقط قم بالبناء مباشرة. ما رأيك؟

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

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

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

لاحقًا، ظهر Figma و Origami، وأدخلنا النماذج التفاعلية في العملية. المشكلة الآن هي أنه يمكنك سحب التنفيذ الكامل إلى بداية العملية. نموذج أولي متقن تمامًا، يبدو أنه يمكن إطلاقه مباشرة. يكفي أن يراه عدد كافٍ من الناس في الشركة فيسألون: "هل يمكننا إطلاقه الآن؟" لكن في الواقع، أنتم لا تزالون في مرحلة التصميم الاستكشافية المبكرة، لكن لا أحد يقول ذلك صراحة.

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

ربط عملية التصميم بوسيط معين، هذا هو المكان الخطير. المصممون لديهم الآن أدوات أكثر، يمكنك وضع الأشياء مباشرة في المنتج الحالي، ويمكنك إجراء اختبار A/B. العديد من الشركات لديها نسخ مصغرة من المنتج، مثل baby Cursor، baby Codex، قاعدة كود مبسطة بشكل كبير تحاكي جميع تفاعلات المنتج الرسمي. يمكنك استخدامها للبرمجة بالأجواء (vibe coding)، مثل "ماذا لو كان الشريط الجانبي هكذا؟ ماذا لو ظهرت لوحة منبثقة؟" هذه أدوات جديدة للمصممين، لكنها تحتاج إلى الوعي القديم: أين أنت الآن في العملية.

الأدوار والمناصب تندمج، لكن مدير المنتج لن يختفي

ليني: العديد من الشركات تتحدث عن "موت الأدوار". هل تعتقد أن تقسيم الأدوار بين مدير المنتج والمهندس والمصمم سيختفي تمامًا؟

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

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

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

وكل تخصص له مكون مهاراتي. العديد من المهندسين لا يعترفون بذلك، ويعتقدون أن الهندسة مهارة، بينما الأدوار الأخرى هي مجرد "أجواء". ليس الأمر كذلك، كونك تجيد استخدام Excel لا يعني أنه يمكنك العمل في الفريق المالي.

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

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

ليني: في فريق Codex الخاص بكم، هناك بالفعل اندماج أكبر للأدوار. كيف يبدو ذلك تحديدًا؟

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

داخل الفريق، لدينا طريقة لوصف التعاون: التداخل بين الأدوار الآن أكبر مما كان عليه في الماضي. تعريف الشخص لم يعد يعتمد على حدود المسؤوليات مثل "أين ينتهي التصميم وأين تبدأ الهندسة"، بل على التوزيع المتوسط لجميع أعماله.

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

ليني: ذكرت أن عمل مدير المنتج يشبه "الدفاع عن المنطقة" (zone defense). ماذا تعني تحديدًا؟

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

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

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

ليني: إذن، الشخص الأكثر قيمة الآن هو من يستطيع دفع الأمور من الفكرة إلى الإنجاز الكامل، ولديه الذوق ليعرف "هذا رائع"؟

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

إذا كنت IC، فأنت لم تعد تكتب الكود حرفًا بحرف. أنت في الواقع تدير بعض الأشياء، تدير الوكلاء (agents)، تدير العمل المنظم لإنجاز المهام. إذا كنت مدير فريق، فأنت تفعل نفس الشيء بشكل أساسي، لكن بحبيبات مختلفة.

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

في كل مرة يسألني أحد عن عدد أعضاء فريق Codex، أجيب: "بين 10 وبضعة آلاف شخص." قد يبدو الأمر مزحة، لكن في الواقع، أعمال الجميع تتلاقى في هذا المنتج: أبحاث النماذج، استخدام المتصفح، شخصية النموذج، البنية التحتية للواجهة الأمامية، تجربة المستخدم، كلها تشكل جزءًا من المنتج.

ولكن في نفس الوقت، لا نتلقى كل يوم مئات طلبات السحب (PRs) من آلاف الأشخاص. الفريق يضم عشرات المهندسين، عدد المصممين حوالي نصف عدد المهندسين، بالإضافة إلى عدد قليل من مديري المنتجات، الغالبية العظمى هم مساهمون فرديون (ICs). نطاق تأثير الفريق كبير، لكن طبقات الإدارة ليست سميكة. هناك الكثير من الأشخاص الذين أسسوا شركات من قبل، والكثير ممن يعملون بـ "عقلية المؤسس" في الشركات الكبيرة، والكثير من ذوي الذوق الرفيع.

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

إذا تم إطلاق Codex قبل ثلاثة أشهر، لكان فشلًا، والفرق الوحيد كان تقدم النموذج

ليني: في هذا الإيقاع السريع للتغيير، كيف تخططون؟ إلى أي مدى تنظرون؟

أندرو أمبروسينو: ليس لدينا ممارسة ثورية في التخطيط. المبدأ الأساسي هو: كلما كان الشيء أقرب إلى الحاضر، كان التخطيط يحتاج إلى أن يكون أكثر تحديدًا. ليس أننا لا نخطط لتسعة أشهر، لكن تلك الخطة يجب أن تظل غامضة جدًا. لأن أي دقة تضيفها على خطة تسعة أشهر الآن هي دقة زائفة، ستضيع الوقت فقط.

في جانب تطبيق المنتج، ما يمكنك التخطيط له في نوفمبر قد يظل صحيحًا في ديسمبر، لكنه سيكون خاطئًا تمامًا في فبراير.

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

ليني: هل هناك مثال محدد يوضح أهمية التوقيت؟

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

ليني: إذن، ما لا يصلح الآن قد يصلح لاحقًا؟ يجب الحفاظ على طموح أكبر؟

أندرو أمبروسينو: نعم. أنصح الناس بعدم الحكم بسرعة بأن "هذا الشيء لا يعمل الآن، لذا فهو ميزة سيئة"، قد لا يكون وقته قد حان.

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

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

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

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

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

ليني: ما هي رؤية Codex؟ إلى أين تريد أن تأخذه؟

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

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

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

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

لدى دان شيبر فكرة مثيرة للاهتمام، يعتقد أننا في المستقبل سنستخدم أدوات SaaS "من الداخل إلى الخارج" داخل Codex: Notion و Linear و Salesforce، لن نفتحها في المتصفح، بل سيديرها وكيل داخل Codex. ونحن نفعل ذلك بالفعل، متصفح داخلي، إضافة Chrome، استخدام الكمبيوتر (computer use)، كل هذه طرق لتمكين Codex من التفاعل مع الأدوات الخارجية.

أفضل مثال: منتج الفيديو الداخلي لدينا، برنت، استخدم Codex لتحرير فيديو إطلاق Codex. Codex ليس محرر فيديو، ليس لديه واجهة مستخدم لتلك المهمة. لكنه يفهم أن برنت يستخدم Premiere Pro، ويقوم ببعض التعديلات عن طريق تحرير الملفات وراء Premiere Pro. عندما وجد أنه لا يستطيع فعل كل شيء، قام بكتابة إضافة خاصة به لـ Premiere Pro، وقام بتثبيتها في Premiere Pro، ثم تحدث مع Premiere Pro من خلالها. عندما رأينا ذلك، كنا مندهشين.

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

كتابة الكود لم تعد مهمة، المهم حذف الكود

ليني: من كتابة الكود يدويًا إلى كتابة الذكاء الاصطناعي 100٪ من الكود، وصولاً إلى الوكلاء والحلقات. كيف تعمل الفرق الأكثر تقدمًا الآن؟

أندرو أمبروسينو: الحلقات (Loops)؟ كان ذلك الأسبوع الماضي.

نحن نناقش باستمرار سؤال "ما هي نسبة الكود الذي يكتبه الذكاء الاصطناعي في المنتج؟". بمعايير العام الماضي، لدينا الآن 100٪ من الكود يكتبه الذكاء الاصطناعي. لذا، لم يعد السؤال هو "كم يكتبه الذكاء الاصطناعي؟"، بل "هل الكتب تحت إشراف أم بدون إشراف؟" هذا بُعد مختلف تمامًا. أرحب باستمرار تحديث هذه المعايير، لأن هذا يعني أننا نحرز تقدمًا في المنتج.

قمنا بالكثير من الاستكشاف في مجال تطوير البرمجيات الذاتي، مثل الكثير من هندسة التسخير (harness engineering)، مثل "ماذا لو قام النموذج تلقائيًا في الليل بتنظيف قاعدة الكود وجمع القمامة؟"

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

طلب الميزات (feature requests) هو نفسه. كيف تعلم النموذج تحديد الميزات الجديرة بالتنفيذ، وأيها يجب تجاهله، وأيها يجب دمجه وإعادة تعريفه؟ وكيف تعلمه بناء التجريدات الصحيحة؟

هذه القدرات تتقدم باستمرار. لكنني لا أعتقد أننا وصلنا إلى مرحلة يمكننا فيها إعداد حلقة (loop) للنموذج لتحسين التطبيق تلقائيًا، والاستماع باستمرار إلى Twitter و Slack والبريد الإلكتروني، وإكمال التكرار بشكل مستقل. على الرغم من أننا نحاول بالفعل تحقيق ذلك.

ليني: هل تعتقد أننا سنصل إلى تلك المرحلة؟ حيث نضع هدفًا: "اربح"؟

أندرو أمبروسينو: "/goal اربح لي مليار دولار." لا أعرف. لن أقول أبدًا لا أو نعم.

ليني: كمسؤول عن المنتج والهندسة، كيف تستخدم الذكاء الاصطناعي في عملك؟

أندرو أمبروسينو: أشعر أن لدي الآن أفضل وظيفة في العالم ربما.

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

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

سلسلة الإصدارات في مايو، المتصفح الداخلي، استخدام الكمبيوتر (computer use)، إنشاء القطع الأثرية (artifact creation)، كانت هذه أول مرة نستخدم فيها "التنسيق بالأجواء" (vibe coordination) لإدارة الإصدار. كان لدي مستند Notion يسجل جميع المهام، ثم استخدمت Codex لجمع التحديثات تلقائيًا من طلبات السحب وقنوات Slack، وتحديث متتبع الحالة. في ذلك الوقت شعرت أن هذه هي أحدث طريقة لإدارة إصدار المنتج.

الآن، كل صباح أستيقظ، أقرأ التقرير اليومي الذي يولده Codex لي، والذي يصف من بين 3000 قناة Slack التي انضممت إليها الأمور التي تحتاج إلى اهتمامي. يمكنني الرد بـ "أعطني خمسة أسئلة، سأجيب عليها." يقوم بضبط نفسه. أقول له "في المرة القادمة، قلل الاهتمام بسير العمل هذا" أو "هذا الشيء حدث لكنه لم يظهر في التقرير اليومي، تأكد من التقاطه في المستقبل"، فيقوم بتحديث طريقة الإشعارات وضبط نقاط التركيز.

ليني: كيف يتم إعداد ذلك؟ ما هو سير العمل؟

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

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

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

أندرو أمبروسينو: إنه مثل: "لا يهمني إذا كان لديك موصل أم لا، يا صديقي، سأبدأ بالنقر مباشرة."

كيفية تقسيم الحدود بين الموصلات والمتصفح الداخلي وإضافة Chrome واستخدام الكمبيوتر، هو أمر مثير للاهتمام للغاية. في كثير من الأحيان، هذه الحدود يتم استكشافها بشكل حدسي.

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

على سبيل المثال، الذاكرة (memory). الكثير من الناس يقومون بإعداد قاعدة معرفية في Obsidian أو مساحة في Notion لبناء قصورهم العقلية. لا يجب أن تضطر إلى فعل ذلك بنفسك، يجب أن تكون هناك وظيفة ذاكرة عامة كافية تفعل ذلك نيابة عنك. نحن نستمر في التصفية: ما الذي ينفع الأفراد ولكن يجب أن يبقى على المستوى الشخصي؟ وما الذي يجب أن يدخل في المنتج ليصبح مكونًا أساسيًا؟

ليني: ما يراه الناس من الخارج هو أنك ناجح. لكن بالتأكيد كانت هناك أشياء لم تنجح؟

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

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

حتى الآن، في مشروع دمج Codex و ChatGPT، هناك عدد لا يحصى من الإخفاقات الصغيرة. نقول "يجب أن يبدو هكذا"، ونضعه في Slack، ثم نحصل على 2000 رسالة تقول كم نحن أغبياء. هذا ما أحبه في OpenAI، الناس يخبرونك مباشرة، دون رحمة، بفشل المنتجات الداخلية، وهذا هو السبب في أن المنتجات الخارجية جيدة. قبل أن أصل إلى هذا المنصب، فشلت لمدة تتراوح بين 10 و 15 عامًا. لذلك ما زلت أشعر بالدهشة كل يوم أن الأمور تسير على ما يرام.

ليني: ما هي نصيحتك الأخيرة للقراء؟

أندرو أمبروسينو: لا تكن "مرتبطًا مدى الحياة" بسير عملك الحالي. ما يجب أن تتمسك به حقًا هو النتائج الفريدة التي يمكنك تقديمها أنت فقط. ثم، استمر في محاولة تغيير سير عملك. إذا كانت المهارة التي تفتخر بها هي "أنا الأفضل في auto layout في Figma"، فماذا تفعل؟ الذكاء الاصطناعي سيصبح أفضل منك أيضًا. ابحث عن شيء يستحق الفعل، ثم ابحث عن طريقة لفعله.