هدفي طويل الأمد في Codex: أربعة أيام وما زال يعمل
في 9 أكتوبر 2026، أظهر هدفي طويل الأمد في Codex 4 أيام و14 ساعة و8 دقائق و22 ثانية. التقطت لقطة شاشة بينما كان Codex لا يزال يعمل على منتج SEO لم أطلقه بعد. ظل الهدف مفتوحًا، مع وجود مهام أخرى لإنجازها.
كنت قد طلبت منه إكمال الخطة بأكملها لمنتج SEO غير المُطلق الذي أبنيه. وبحلول ذلك الوقت، كنت قد طلبت منه أيضًا استخدام مزيد من الوكلاء، وخفض مستوى جهد الاستدلال، والتوقف لتقديم تحديثات، والاستئناف بعد إعادة التشغيل، وقضاء وقت أقل في تكرار الاختبارات.
هذه روايتي عن هدف طويل الأمد في Codex: العمل الذي أنتجه، والعمل الذي أبطأه، والقرارات التي كان لا يزال يتعين عليّ اتخاذها. هذا بناء غير مكتمل، وليس معيارًا للمقارنة أو إعلان إطلاق.
ينتمي المؤقت أعلاه إلى الهدف. وهو لا يثبت أربعة أيام من الحوسبة المتواصلة للنموذج. تتضمن جلستي فترات توقف واستئناف صريحة، وتحديثًا للتطبيق، وإعادة تشغيل للكمبيوتر، وتنفيذًا للأدوات، وفترات انتظار.
ما طلبت من Codex بناءه
بدأت المحادثة في 3 أكتوبر بسؤال أصغر: هل يمتلك المستخدمون بيانات اعتماد تسجيل الدخول الخاصة بهم، وهل يمكنهم تسجيل الدخول باستخدام Google، وهل يمكنهم إنشاء مفاتيح MCP شخصية؟
ثم وسّعت المتطلبات. ينبغي لكل مستخدم أن يرى مشاريعه الخاصة. وينبغي أن يتمكن المستخدمون من دعوة أشخاص إلى مساحة عمل. أردت إعدادات للتفضيلات الشخصية والتزامن في الزاحف. وستصبح المنصة تجارية في نهاية المطاف، مع إطلاق أولي مجاني.
قدمت كتالوجًا أكبر بكثير لمنتج SEO لتوجيه عملية البناء. غطت الخطة الناتجة 15 مجالًا للمنتج، و42 مرجعًا للتطبيق، و19 أداة عامة مجانية، بالإضافة إلى ميزة لترتيب زيارات المواقع. وشملت SEO التقني، وأبحاث الكلمات المفتاحية، والترتيبات، والروابط الخلفية، وظهور AI، والمحتوى، والتحليلات، وSEO المحلي، وميزات المؤسسات لاحقًا.
كنت أريد أيضًا أن يطلب المنتج مقالات من محرك المحتوى الذي يقف وراء موقعي الخاص.
لذلك، فإن التعليمات الخاصة بإكمال الخطة بأكملها كانت تشير إلى خارطة طريق كبيرة للمنتج. لقد ساعدت في إنشاء هذا النطاق. كان مؤقت مدته أربعة أيام لإصلاح خطأ صغير سيحكي قصة مختلفة.
النموذج والإعدادات التي استخدمتها
يحدد سجل الجلسة الرئيسي النموذج باسم GPT-6.1 Sol، وبالمعرّف gpt-6.1-sol. وتتضمن أدواره المسجلة إعدادات استدلال ultra وmedium وعددًا قليلًا من إعدادات high. وهذا يحدد الجلسة الرئيسية؛ لكنه لا يثبت النموذج المستخدم وراء كل مراجع أو أداة خارجية.
في 5 أكتوبر، بدّلت مستوى الجهد صراحةً إلى medium لتوفير الرموز. ثم أوقفت turbo للسبب نفسه. كانت تلك نواياي، وليست وفورات مقاسة: لا أملك مقارنة مدققة للتكلفة بين الإعدادين.
كما طلبت مزيدًا من الوكلاء المتوازيين. استخدمت الجلسة عملًا مفوضًا ومراجعات أقران من Claude لأجزاء من التنفيذ. أتاح ذلك تقدم مهام منفصلة، لكنه أنشأ أيضًا عملًا لمواءمة مخرجاتها والتحقق من النتيجة المجمعة.
تغطي مقارنتي السابقة لـ GPT-6.1 Sol→ بيانات النماذج المنشورة. أما هذا البناء فهو نوع مختلف من الأدلة: مشروع حقيقي واحد بنطاق وإعدادات متغيرة، وليس مقارنة مضبوطة بين النماذج.
إلى متى يمكن لهدف Codex أن يواصل العمل؟
في هذه الحالة، عرضت الواجهة أكثر من أربعة أيام للهدف المستمر نفسه. هذه هي الملاحظة التي يمكنني دعمها. وهي ليست ضمانًا لأقصى مدة تشغيل، ولا يمكنني حساب وقت الاستدلال النشط من لقطة الشاشة.
تصف OpenAI الأهداف في Codex بأنها أهداف تستمر عبر الأدوار. يمكن لـ Codex مواصلة التقدم نحو نتيجة، بينما يستطيع المستخدم إيقافه مؤقتًا أو استئنافه. ويؤثر الإكمال والانقطاعات والميزانيات والعوائق في استمرار العمل.
تتوافق تجربتي مع سير العمل المستمر هذا. كان بإمكاني العودة إلى الهدف نفسه بعد فترات التوقف وتوجيه العمل التالي. كان إبقاء الهدف متاحًا مفيدًا. لكنه لم يجعل الهدف أصغر، ولم يضمن أن كل دور جديد سيقرّب المنتج من الإطلاق.
ماذا كان قد سلّم بحلول 9 أكتوبر؟
سجل التسليم في 9 أكتوبر 30 متطلبًا مكتملًا جزئيًا، و39 متطلبًا لم يُقيّم، وصفر متطلبات مقبولة بالكامل من أصل قائمة تتبع مكونة من 69 نقطة.
يحتاج هذا العدد إلى سياق. تقيس القائمة قبولًا واسعًا للمنتج. ولا يعني وجود صفر متطلبات مقبولة بالكامل عدم وجود أي كود يعمل. كما أن وجود 30 متطلبًا جزئيًا لا يعني أن المنتج مكتمل بنسبة 43 بالمئة.
يسجل السجل اختبار smoke محليًا قابلًا للتخلص منه لخط أساس لحساب مدعوم: إنشاء الحساب الأول، وتسجيل الدخول بكلمة مرور، وقراءة الجلسة ومساحة عمل المالك الخاصة، ثم تسجيل الخروج ورفض الجلسة القديمة. هذا تدفق مستخدم ملموس ذو نتيجة اختبار محددة. لكنه ليس دليلًا على أن أحدث تطبيق كامل جاهز للعملاء.
شمل التقدم الآخر تكامل مصدر محلي لإعادة تعيين كلمة المرور، ومسودات لمراجعة الروابط الخلفية، والعمل على تقارير Search Console المحفوظة، ونقل تقارير GA4 باستخدام رمز العميل، والعمل على مسودات المقالات إلى LinkedIn. ظل تفعيل العديد من هذه الأجزاء معطلًا، أو كان تكاملها غير مكتمل، أو كان التحقق منها مؤجلًا.
أفادت نقاط التحقق المؤرخة صراحةً بعدم وجود commit أو push أو deployment. وظل تسجيل الدخول عبر Google والجاهزية الكاملة للعملاء غير متحقق منهما. كان لدي تنفيذ محلي متنامٍ مع أدلة مفيدة، وليس منصة مُطلقة.
ما الذي أبطأ هدفي طويل الأمد في Codex؟
وسّعت الهدف ليصبح خارطة طريق للمنتج
تبدو إضافة تسجيل الدخول عبر Google كأنها ميزة واحدة. لكن إضافة عملاء خاصين تغيّر من يمكنه الوصول إلى المشاريع والتقارير والمهام الخلفية والتكاملات. كنت أريد أن يظل هذا الحد قائمًا عبر التطبيق بأكمله.
ثم أضفت أبحاث الكلمات المفتاحية، والروابط الخلفية، وإنشاء المحتوى، وكتالوجًا أكبر بكثير. يعكس بعض الوقت المنقضي العمل الضروري على هدف واسع. وقد جعل هدفي الأصلي من السهل الاستمرار في فتح المجال التالي غير المكتمل.
أصبحت عملية التحقق متكررة أكثر من اللازم
طلبت قرارات مدعومة بالمصادر، وتغييرات محدودة، ومراجعات، وأدلة صريحة. ساعدت هذه التعليمات في منع الادعاءات الغامضة بأن شيئًا ما قد اكتمل.
لكن الجلسة راكمت عمليات تحقق متكررة من المصادر، وتحضير المراجعات، والعمل على تجهيزات الاختبار. وحكمي هو أن التوازن انحرف كثيرًا نحو إثبات الأجزاء الفردية قبل إكمال التدفق التالي القابل للاستخدام.
في 9 أكتوبر، طلبت منه التوقف عن قضاء هذا القدر من الوقت في الاختبارات، والعمل نحو الإكمال، وترك اختبار أكبر لوقت لاحق. لم يلغِ ذلك الحاجة إلى التحقق من عزل الحسابات. بل غيّر التسلسل: فحوصات مركزة أثناء التنفيذ، يتبعها تحقق أوسع من التدفق المجمّع.
كانت بعض الإخفاقات مرتبطة بإعداد الاختبار
فشلت إحدى محاولات قاعدة البيانات الخاصة بإعادة تعيين كلمة المرور لأن سجل حساب اصطناعيًا أغفل حقلًا مطلوبًا لاسم العرض. كان إصلاح هذه التجهيزة ضروريًا لتشغيل الاختبار، لكنه لم يكن ميزة جديدة في المنتج.
انتهت محاولة لاحقة طويلة الأمد لقاعدة البيانات عندما أعيد تشغيل محطة العمل. ولم يدّعِ سجل التسليم نجاح تلك المحاولة. وكشف التشخيص اللاحق عن إعادة حساب متكررة لعقود التحقق السابقة، وعن مخرجات تقدم مخزنة مؤقتًا، ما جعل تقييم العملية الجارية أكثر صعوبة.
هذه التفاصيل مهمة لأن الانتظار ملتبس. فقد تكون العملية المباشرة تعمل، أو تعيد حساب المتطلب نفسه، أو تنتج مخرجات لا أستطيع رؤيتها بعد. ولا يمكن للمؤقت وحده أن يخبرني بأي من هذه الحالات يحدث.
أضاف المزيد من الوكلاء تنسيقًا إضافيًا
ساعد العمل المتوازي في المهام القابلة للفصل. ومع ذلك، كان لا يزال يتعين على الجلسة الرئيسية فحص النتائج، وحل التبعيات، ودمج التغييرات في تطبيق واحد. لا يمكنني عزو تسارع العمل إلى إضافة الوكلاء، لأنني لم أنفذ المشروع نفسه معهم ومن دونهم.
أصبح السؤال العملي هو ما إذا كان وكيل آخر سيتمكن من إنهاء جزء مستقل، أم أنه سينشئ عملية تسليم أخرى للجلسة الرئيسية.
ما زلت أفعله بصفتي الإنسان
أختار اتجاه المنتج وأقرر الميزات الأكثر أهمية تاليًا. أتحقق مما إذا كان التقدم المبلغ عنه يصف سلوكًا يعمل، أو كودًا مصدرّيًا محليًا، أو اقتراحًا لم يتم التحقق منه. أوقف العمل مؤقتًا عندما أحتاج إلى تحديث Codex أو إعادة تشغيل الكمبيوتر، ثم أطلب منه المتابعة من حالته المحفوظة.
كما أنني أتحدى وتيرة العمل. خلال هذا البناء، قمت بما يلي:
تمنحني الخطة وسجل التسليم شيئًا يمكنني فحصه يتجاوز رسائل الدردشة. كما أنهما يحتاجان إلى الانضباط: لا تكون نقطة التحقق المؤرخة مفيدة إلا إذا أوضحت ما الذي تغير وما الذي لا يزال غير مثبت.
تواصل التجربة المفاضلة التي وصفتها في اعتقدت أن AI سيمنحني مزيدًا من وقت الفراغ→. يمكنني محاولة بناء أكبر، لكنني ما زلت أقضي وقتًا في تحديد ما يستحق البناء والتحقق من النتيجة.
المزايا والعيوب حتى الآن
في تجربتي مع هذا البناء، تتمثل أكبر ميزة في الاستمرارية. يمكنني إبقاء هدف كبير مفتوحًا واستئنافه بعد الانقطاعات. أنتج Codex تطبيقات محلية، وحقق في الإخفاقات، وحافظ على سجلات مفصلة تساعدني في مراجعة العمل.
كما يمكنه التعامل مع أنواع متعددة من العمل ضمن المشروع نفسه: تغييرات قاعدة البيانات، وسلوك API، وتدفقات الواجهة الأمامية، وعمليات نقل التكامل، والتوثيق. وهذا يجعل بناءً واسعًا ممكنًا بالنسبة لي لتوجيهه.
أما العيب فهو أن النشاط قد يبدو تقدمًا. يمكن أن تتعايش فحوصات ناجحة كثيرة مع منتج غير مكتمل. كما أن جهد الاستدلال العالي والمزيد من الوكلاء يفرضان خيارات تتعلق بالميزانية والتنسيق، من دون ضمان تسليم أسرع.
تجعل عمليات التشغيل الطويلة أيضًا الالتزام بالنطاق أكثر صعوبة. إذ تمنح خارطة الطريق المكتملة جزئيًا الوكيل العديد من الخطوات التالية القابلة للدفاع عنها. وأحتاج إلى تحديد الخطوة التي تقدم النتيجة المفيدة التالية.
سأستخدم هدفًا مستمرًا مرة أخرى، لكنني سأمنح كل مرحلة تنفيذ هدف قبول أصغر. على سبيل المثال: إنشاء حساب، وتسجيل الدخول، ورؤية مساحة العمل الخاصة به، ورفض الوصول من حساب ثانٍ. أبقي خارطة الطريق الأكبر كسياق، وأنهي ذلك التدفق، ثم أنتقل إلى الخطوة التالية.
ما سأقيسه لاحقًا
لا يزال منتج SEO قيد التطوير ولم يُطلق حتى 9 أكتوبر. والقياس المفيد التالي هو تدفق مستخدم كامل مقابل التطبيق المجمّع الحالي، مع إدراج العوائق المتبقية صراحةً.
بعد ذلك، أريد أدلة على تسجيل الدخول عبر Google، والتكاملات المرتبطة بالعملاء، ومفاتيح MCP الشخصية، والإطلاق الآمن. يواصل Codex العمل على المهام؛ ويسجل هذا المقال لقطة 9 أكتوبر. وسأقيّم البناء بناءً على تلك النتائج، لا على مدة بقاء الهدف مفتوحًا.
المصادر وحدود هذه الرواية
يأتي المؤقت من لقطة الشاشة أعلاه. ويأتي معرّف النموذج، والتغييرات في الإعدادات، وتدخلاتي من سجل الجلسة الرئيسية. ويأتي النطاق وأعداد التقدم من خطة المشروع وسجل التسليم المؤرخ الخاص بها. هذه السجلات الخاصة بالمشروع هي مستندات عمل خاصة؛ ولم أنشر السجلات أو بيانات العملاء.
تشرح صفحة OpenAI حول استخدام الأهداف في Codex سير العمل القائم على الأهداف المستمرة. وهي تدعم وصف الأهداف، لا ادعاءات التسليم المتعلقة بمشروعي.
يُعد عدد النقاط البالغ 69 لقطة قبول واسعة، وليس مقياسًا للساعات المتبقية. ولا تثبت لقطة الشاشة استدلالًا متواصلًا، ولا تثبت تغييرات الإعدادات وفورات في التكلفة، ولا تثبت الفحوصات المحلية الجاهزية للإنتاج. لا يزال هذا البناء قيد التنفيذ.
*تمت صياغة هذا المقال بمساعدة AI اعتمادًا على لقطة الشاشة الخاصة بي، وسجل الجلسة، وسجلات تسليم المشروع. وهو يصف بناءً واحدًا مستمرًا. ولا يثبت حدًا عامًا لوقت تشغيل Codex، أو ترتيبًا للنماذج، أو تكلفة مدققة، أو جاهزية للإنتاج.*