spinny:~/writing $ cat codex-role-plugins-sites-workflows.md

Codex يتحول إلى مساحة عمل، لا مجرد وكيل لكتابة الكود

· 2 min read · Filippo Spinella · AI, Codex, Developer Tools, Productivity

أكثر ما لفتني في إعلان Codex الجديد لم يكن كلمة plugins. الفكرة الأهم هي أن Codex يحاول أن يصبح مكانا يهبط فيه العمل ويتحول إلى شيء قابل للمراجعة.

نشرت OpenAI في 2 يونيو 2026 مقال Codex for every role, tool, and workflow. الميزات الواضحة هي إضافات حسب الدور، و Sites، والتعليقات الدقيقة. لكن السؤال الحقيقي أبسط: هل يستطيع الوكيل أن يأخذ سياقا متفرقا داخل الشركة ويحوّله إلى شيء يمكن للفريق أن يقرأه ويناقشه ويحسنه؟

التحول الحقيقي

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

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

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

Sites هي الجزء الذي سأراقبه

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

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

التعليقات تجعل المراجعة أدق

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

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

كيف سأجربه

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

القائمة بسيطة:

  • تحديد المصادر التي يمكن لـ Codex قراءتها;
  • تحديد ما يمكنه كتابته;
  • طلب روابط للمصادر المهمة;
  • تعيين مالك لكل مخرج مولد;
  • أرشفة أو حذف ما لم يعد مفيدا.

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

قراءتي

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

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

المصادر

spinny:~/writing/codex-role-plugins-sites-workflows $
try:
spinny:~/writing/codex-role-plugins-sites-workflows·codex-role-plugins-sites-workflows.md
·
·--:--:--
    Codex يتحول إلى مساحة عمل، لا مجرد وكيل لكتابة الكود | فيليبو سبينيلا - مهندس برمجيات