OpenAI تعرض كيف حلّل «dot» الخاص بمهندس حادثة ليلية وأطلق Codex

في الساعة 3 فجرًا انطلق تنبيه حادثة on-call لدى مهندس OpenAI المدعو علي. لم يفتح حاسوبه المحمول. تولّى الـ dot الخاص به التحليل: درس المشكلة وفتح بنفسه thread في Codex، بينما أدار علي العمل من هاتفه عبر تطبيق ChatGPT. هذه هي قصة المقطع «Put your dot on call» الذي نشرته OpenAI على قناتها في YouTube بتاريخ 16 أكتوبر 2026.

ما المعروف من الوصف

نص الوصف المرافق للفيديو قصير، والحقائق فيه قليلة. فيه بطل هو المهندس علي. وفيه توقيت هو الثالثة فجرًا، حين يكون المناوب أقل استعدادًا لاتخاذ قرارات معقدة. وفيه مهمة هي فرز الحادثة (triage)، أي التقييم السريع لما تعطّل ومدى خطورته وما ينبغي فعله أولًا. وفيه سلسلة أدوات: dot، ثم thread في Codex، ثم واجهة ChatGPT على الهاتف.

لا يشرح الوصف ما هو الـ dot. كل ما يمكن استنتاجه من صيغة «his dot» أنه كيان شخصي مرتبط بشخص محدد، وقادر على دراسة المشكلة وإطلاق المهام بنفسه. لم يذكر النص شكله، ولا النموذج الذي يعمل خلفه، ولا مستوى وصوله إلى البنية التحتية. ولن نخمّن.

كيف بُني السيناريو

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

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

أبرز المعطيات الواردة في المادة:

• البطل: علي، مهندس في OpenAI.
• المهمة: فرز حادثة on-call.
• التوقيت: الساعة 3 فجرًا.
• خط الدفاع الأول: dot، الذي يحقق في المشكلة بنفسه.
• بيئة العمل على الشيفرة: thread في Codex.
• واجهة الإدارة: تطبيق ChatGPT على الهاتف.
• لم يُكشف عنه: طبيعة dot، ونوع الحادثة، والزمن حتى الحل، وصلاحيات الوصول، ووجود تأكيد قبل إجراء التغييرات.

ما الذي ينقص المقطع

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

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

ما الذي ينبغي أن تتحقق منه الفرق التي تعتمد المناوبات

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

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