أنجز Pepper-orchestrator ثلاث حزم خلال ساعة و52 دقيقة من دون كتابة الكود يدويا

يستطيع وكيل ذكاء اصطناعي واحد بناء نموذج أولي بصورة جيدة ما دام المشروع بأكمله قابلا للاستيعاب في ذهن شخص واحد. بعد ذلك تبدأ المشكلات المألوفة: يؤثر تغيير في واجهة API في مستودع مجاور، ويعدل منفذان الملف المشترك نفسه، بينما تؤكد الاختبارات الافتراضات ذاتها التي كتب الكود على أساسها. يقترح Maksim Nikitin، مؤلف استوديو ITSalt، حل هذه المشكلة ليس عبر إطالة الموجه، بل بفصل المسؤوليات.

يحول مكونه الإضافي pepper-orchestrator المخصص لـ Claude Code وCodex الهدف الكبير إلى برنامج يتألف من حزم عمل صغيرة. تحصل كل حزمة على سياق مستقل وفرع أو نسخة عمل ومسارات مسموح بها وتبعيات ومعايير قبول قابلة للتحقق. ولا يكتب المنسق كود الوحدات بنفسه، بل يحتفظ بالصورة العامة، ويحدد ترتيب التشغيل، ويسلم النتيجة إلى مراجع مستقل.

كيف يبدو ذلك في حالة بسيطة

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

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

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

لماذا لم تكن الاختبارات الناجحة كافية

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

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

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

أين يكون هذا النهج مفيدا فعلا

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

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

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