بيئات التمكين: الاستفادة من Codex في عالم يتبنى نهج الوكيل أولًا

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

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

البشر يتولون التوجيه، والوكلاء يتولون التنفيذ.

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

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

شهدت أواخر شهر أغسطس من عام 2025 تسجيل أول عملية إيداع كود برمجي في المستودع الفارغ، للإعلان بذلك عن البداية الفعلية للمشروع.

لقد تولت أداة Codex CLI، مدعومة بنموذج GPT‑5، إنشاء البنية التحتية الأساسية للمشروع؛ بما في ذلك هيكلية المستودع وتكوين CI وقواعد تنسيق الكود البرمجي وإعدادات مدير الحزم وإطار العمل البرمجي، وذلك بناءً على مجموعة من القوالب الجاهزة. ومن المثير للاهتمام أن ملف AGENTS.md التأسيسي، الذي يحدد للوكلاء آليات العمل والتعاون داخل المستودع، قد صِيغ بالكامل بواسطة Codex نفسه.

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

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

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

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

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

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

أما في ما يخص التفاعل ين الإنسان والنظام، فيتم بشكل شبه كامل عبر المطالبات؛ إذ يحدد المهندس تفاصيل المهمة، ويترك للوكيل حرية التنفيذ وفتح طلب السحب. ولضمان جاهزية طلب السحب، نُكلف Codex بمراجعة تعديلاته محليًا، وطلب تقييمات إضافية من وكلاء متخصصين في البيئات المحلية والسحابية، والتفاعل مع التعليقات الواردة من البشر أو الآلات، والاستمرار في هذه الحلقة حتى ينال العمل استحسان كافة الوكلاء المراجعين (وهذا ما نطلق عليه اسم "حلقة رالف ويغوم التكرارية⁠(يفتح في نافذة جديدة)"). كما يمتلك Codex قدرة الوصول المباشر إلى أدواتنا التطويرية المعتادة (مثل gh والبرامج النصية المحلية والميزات المضمنة في المستودع)، مما يمكنه من استقاء المعلومات وسياق العمل ذاتيًا دون أن يضطر المهندسون إلى تكرار عمليات النسخ واللصق في CLI.

وتظل مراجعة البشر لطلبات السحب خيارًا متاحًا ولكنها ليست إلزامية؛ حيث نجحنا مع تطور المشروع في توجيه كافة جهود التدقيق والمراجعة تقريبًا لتتم آليًا بين الوكلاء البرمجيين.

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

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

لقد طبقنا المنهجية ذاتها على أدوات تتبع الأداء والتحليل؛ إذ تُعرض السجلات والمؤشرات ومسارات التتبع لـ Codex من خلال بيئة تتبع محلية مؤقتة تنتهي بانتهاء العمل على المستودع الفرعي (worktree). يباشر Codex مهامه على نسخة من التطبيق تتمتع بعزل كامل، بما في ذلك بيانات التشغيل والمقاييس التي تُزال فور إنهاء المهمة المطلوبة. ويملك الوكلاء صلاحية الاستعلام عن السجلات عبر LogQL والمقاييس عبر PromQL؛ وبوجود هذه المعطيات، غدت مطالبات مثل 'تحقق من أن تشغيل الخدمة يستغرق أقل من 800 مللي ثانية' أو 'ألا يتخطى زمن الاستجابة في مسارات المستخدم الأربعة الأساسية حاجز الثانيتين' أهدافًا واقعية وقابلة للتحقيق بدقة.

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

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

اختبرنا في البداية منهجية "ملف AGENTS.md⁠(يفتح في نافذة جديدة) الموحد والشامل"، إلا أنها تعثرت بطرق كانت متوقعة سلفًا بالنسبة لنا:

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

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

تتوزع المعرفة البرمجية للمستودع داخل دليل docs/‎ منظم، والذي يُعد المصدر الموثق والمعتمد للمعلومات في النظام. وفي المقابل، يبرز ملف AGENTS.md المختصر (حوالي 100 سطر) ليُحقن ضمن سياق العمل كخريطة إرشادية، توفر للوكيل روابط وإشارات تحيل إلى مراجع معرفية أكثر عمقًا واستفاضة في أجزاء أخرى من المشروع.

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

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

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

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

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

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

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

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

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

لقد ساعدنا هذا المنظور على حسم الكثير من الموازنات الصعبة؛ إذ منحنا الأولوية للتبعيات والأنماط التجريدية التي يمكن للنظام استيعابها وتحليلها منطقيًا بالكامل داخل المستودع. وغالباً ما تكون التقنيات المستقرة أو ما يُطلق عليه "المملة" أيسر في التعامل بالنسبة للوكلاء، بفضل مرونة تركيبها وثبات واجهة API الخاصة بها وتوافرها بكثرة في نماذج التدريب. وقد وجدنا في أحيان معينة أن إعادة بناء أجزاء من الخصائص البرمجية بواسطة الوكيل أقل كلفة من محاولة معالجة السلوكيات غير الشفافة للمكتبات الخارجية؛ فمثلاً، عوضً عن استيراد حزمة برمجية عامة من نوع p-limit، طورنا أداة المساعدة (map-with-concurrency) الخاصة بنا، لتكون متصلة بعمق مع أدوات تتبع OpenTelemetry ومحصنة باختبارات شاملة، ولتعمل بتوافق تام مع متطلبات بيئة التشغيل لدينا.

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

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

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

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

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

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

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

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

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

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

مع ارتفاع معدل إنتاجية Codex، باتت الكثير من المعايير الهندسية التقليدية تعطي نتائج عكسية.

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

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

عندما نقول إن قاعدة الأكواد تم إنشاؤها بواسطة وكلاء Codex، فإننا نعني كل شيء تمامًا في القاعدة.

ينتج الوكلاء:

• رمز المنتجات والاختبارات
• تكوين CI وأدوات الإصدار
• أدوات المطور الداخلية
• الوثائق وسجل التصميمات
• أدوات التقييم
• مراجعة التعليقات والردود
• البرامج النصية التي تدير المستودع نفسه
• ملفات تعريف لوحة التحكم في الإنتاج

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

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

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

بمجرد تلقي مطالبة واحدة، يمكن للوكيل الآن:

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

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

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

في بادئ الأمر، كان المهندسون البشر يتولون معالجة هذه المسألة يدويًا؛ إذ اعتاد فريقنا قضاء كل يوم جمعة (أي نحو 20% من أسبوع العمل) في تنقية قاعدة الأكواد مما يسمى بـ 'مخلفات الذكاء الاصطناعي' (AI slop). وكما هو متوقع، فإن هذا النهج لم يكن قابلًا للتوسع أو الاستمرار بمرور الوقت.

بدلًا من ذلك، شرعنا ببرمجة ما نسميه 'المبادئ الذهبية' مباشرة داخل المستودع، وقمنا ببناء عملية تنظيف دورية. وتُعد هذه المبادئ بمثابة قواعد منهجية وميكانيكية حاسمة تضمن بقاء قاعدة الأكواد مقروءة ومتسقة لدورات تشغيل الوكلاء المستقبلية. فعلى سبيل المثال: (1) نفضل استخدام حزم الأدوات المساعدة المشتركة بدلاً من إنشاء الأدوات المساعدة المكتوبة يدويًا للحفاظ على مركزية الثوابت البرمجية، و(2) لا نقوم بفحص البيانات 'بأسلوب عشوائي' (YOLO-style)، بل نتحقق من الحدود أو نعتمد على حزم تطوير برمجيات (SDK) محددة الأنواع حتى لا يبني الوكيل وظائف اعتمادًا على افتراضات غير دقيقة. وبشكل دوري، نشغّل مجموعة من مهام Codex في الخلفية لمراجعة أي انحرافات، وتحديث درجات الجودة، وفتح طلبات pull requests موجهة لإعادة الهيكلة. ويمكن مراجعة معظم هذه الطلبات في أقل من دقيقة ودمجها تلقائيًا.

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

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

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

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

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

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