SENAR يُدخل «بوابات الجودة» إلى التطوير بالذكاء الاصطناعي: كيف تقلّل المواصفات والمقاييس الأخطاء

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

كيف تعمل منهجية SENAR

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

وفي دورة المهمة الواحدة تعتمد SENAR على عدة عناصر إلزامية:

• هدف رسمي للمهمة ضمن منطق المنتج
• معايير قبول قابلة للتحقق
• قسم مستقل للسيناريوهات السلبية
• حدود التغييرات والسياق المعماري
• مقاييس إشارية لجودة العملية

ويؤكد الكاتب أن هذه المنهجية ليست محاولة لاستبدال الاختبارات أو أدوات فحص الشيفرة (linters) أو المراجعة. فالمنطق مختلف: الفحوص المعتادة تنظر إلى الشيفرة، أما البوابات فتنظر إلى المهمة نفسها قبل البدء، وإلى جودة قبولها بعد الانتهاء. وفي التطبيق العملي TAUSIK دُمجت هذه الخطوات مباشرة في الأداة، ولذلك لا يمكن تخطّيها دون الالتفاف على النظام نفسه. وهذا بالتحديد، في رأي الكاتب، ما يحمي الفريق من إرهاق «يوم الجمعة»، حين تتسلل أصغر المهام، في الغالب، إلى بيئة الإنتاج وفيها عيب.

ما الذي تفحصه البوابات

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

«الخطوة لم يتخطّها الوكيل، بل أنا».

وعند الخروج تعمل بوابة QG-2، وهي تمنع إغلاق المهمة إلى أن تُطابَق النتيجة مع الوعود المقدَّمة عند الدخول. ويحدد الكاتب في المقال ثلاثة فحوص إلزامية: تأكيد كل معيار قبول باختبار أو بفحص يدوي أو بمخرَج (artifact)؛ وتسجيل جميع التعديلات اليدوية التي أُجريت بعد عمل الوكيل؛ وتحديث ذاكرة المشروع إذا كشفت المهمة حالة حدّية جديدة أو خصوصية في البنية التحتية. وهذا النمط ليس للبيروقراطية، بل كي لا يكرر الوكيل في المهمة التالية الأخطاء نفسها بسبب إصلاحات أدخلها الإنسان بصمت.

المقاييس والحدود

يخصص المقال قسمًا مستقلًا للمقاييس التي تستخدمها SENAR كإشارات على حالة العملية. يُظهر FPSR نسبة المهام المحلولة من المحاولة الأولى؛ ويُظهر MIR عدد مرات الحاجة إلى تعديل يدوي بعد عمل الوكيل؛ ويقيس DER الفروع المسدودة والوقت الضائع؛ ويعكس ERR المهام التي اضطُرّ إلى إصلاحها بعد إغلاقها. وبحسب السجل العملي للكاتب، ارتفع FPSR في مهام الخوادم ضمن مجال مألوف من نحو 40% إلى 75–80%، وانخفض MIR في مشروع Sortule من 20% إلى 5–7%، وتراجع ERR من نحو 15% إلى 6%.

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

ماذا يعني ذلك

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