مهندسان وCodex أوصلوا نظاما إلى المرحلة التجريبية خلال شهرين بدلا من فريق من خمسة أشخاص

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

ما الذي بنياه وكيف نظما العمل

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

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

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

يعتمد مستوى الإشراف على المواعيد. يمكن مراجعة النتيجة بعد كل بند فرعي، أو ترك الوكيل يعمل طوال الليل حتى النشر على بيئة التطوير. وفي أسوأ الحالات، يجري التراجع عن التغييرات.

مواضع الألم

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

تكلفة التطوير بالوكلاء:

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

لماذا يظل الأمر مجديا

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

أما من الناحية الاقتصادية، فيقدر صاحبا التجربة أنهما كانا سيحتاجان، من دون الوكلاء، إلى مطور frontend، ومطوري backend اثنين، ومختبر، ومهندس DevOps. وبدلا من ذلك استخدما اشتراكين Pro بسعر $200 لكل منهما.

ما الذي ينبغي تذكره

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

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