يثير ازدهار أدوات التطوير العاملية، التي تُسند إلى وكلاء الذكاء الاصطناعي مهمة إعداد تعديلات الكود، مسألة إمكانية تدقيق سير العمل. ففي القطاعات المنظمة، لم يعد يكفي معرفة من وافق على التعديل؛ بل يجب أن يكون بالإمكان إعادة تركيب السياق والضوابط والقرارات التي أدت إليه.
داخل مؤسسة مالية كبيرة تستخدم وكيلًا في سير عمل التطوير الخاص بها، طرح فريق التدقيق الداخلي والامتثال سؤالًا محددًا. بالنسبة لطلب دمج (merge request) فتحه وكيل لتحديث تبعية خدمة دفع، هل يمكن تحديد من وافق عليه، وما هي بيانات الإدخال والمطالبات (prompts) التي استخدمها الوكيل، وأي ضوابط سياسة تم تقييمها، وكيف يمكن إعادة إنتاج هذه المهمة أو التراجع عنها؟ لم يكن لدى الفريق إجابة. فالنظام التسليمي لم يعتبر عمل الوكيل معاملة محدودة وقابلة للتدقيق.
إن الاختلاف (diff) الذي تم التحقق منه بواسطة التكامل المستمر (CI) والموافقة عليه يثبت حدوث تعديل. لكنه لا يثبت السياق الذي استخدمه الوكيل، ولا قرارات السياسة التي تم تقييمها قبل إنشاء طلب الدمج، ولا إمكانية إعادة إنتاج النتيجة عند تنفيذ لاحق. ومع ذلك، في البيئات المنظمة، فإن « الكيفية » و »السببية » أمران أساسيان. هذه الحالة موجودة عبر جميع المنصات وفي منظمات DevSecOps: يتم اعتماد ميزانية الأدوات العاملية في غضون أسابيع، بينما لا تظهر ميزانية تسجيلات التنفيذ وربط الهوية وأدوات إعادة التشغيل أبدًا أو يتم التعامل معها على أنها مجرد تكلفة امتثال.
أربعة استثناءات متكررة
بمجرد أن يفتح الوكلاء طلبات دمج في بيئة CI/CD منظمة، تظهر أربعة أنواع من استثناءات الامتثال. الأول هو نقص إثبات المصدر: لا يمكن لأحد تحديد البيانات التي استخدمها الوكيل، سواء كانت المواصفات، أو السياق المسترجع، أو استدعاءات الأدوات، أو حالة المستودع. الثاني هو عدم اليقين في إسناد الهوية، حيث أن الوكيل تصرف تحت رمز خدمة مشترك، دون مسؤول بشري محدد. الثالث هو سلسلة قرارات غير قابلة لإعادة التركيب، حيث تم التقاط المنطق بشكل عابر فقط. الرابع هو التراجع غير المحدد: نظرًا لأن تعديلات الوكيل مترابطة، يصبح أي إلغاء عملًا يدويًا عبر الالتزامات (commits) والمستودعات.
إعادة التركيب اللاحقة تتضمن فحص سجلات المحادثة، ومخرجات CI الجزئية، وآثار الوكيل المتاحة. في معظم المنظمات، لا يحسب أحد الساعات المخصصة أسبوعيًا لهذه المهمة، مما يفسر بقاء تكلفتها غير مرئية. المصدر يقترح اختبارًا بسيطًا: هل يستطيع فريق إنتاج ملف أدلة في أقل من ساعة يجمع مواصفات المهمة، وحالة المستودع، والضوابط التي تم تقييمها، والمسؤول البشري الذي بدأ الإجراء؟
« التسليم أولاً » وحدوده
قد تنجح استراتيجية « التسليم أولاً، ثم الحوكمة » عندما يُحصر الوكلاء في نطاقات محدودة، مثل إنشاء الاختبارات، وإعادة الهيكلة الصغيرة، أو تحديث الوثائق، مع مراجعة بشرية قوية. لكنها تتعطل عندما تتجاوز الفرق هذه الحدود، وتتضاعف مكتبات المطالبات (prompts) مع تسجيل غير متناسق، وتجعل الرموز المشتركة الإسناد مستحيلاً على مستوى المحفظة. المقالة تذكر أيضًا حالة شركة كبيرة أرادت بناء أساس لسير العمل قبل تعميم الوكلاء: امتد مشروع المنصة على عدة أرباع، وانتهى الأمر بالفريق إلى تجاوزه.
تؤكد المقالة أن « الضغط التنافسي يكافئ السرعة، بينما المنظمون يكافئون القدرة على إعادة التركيب ». وتصف تكلفة هذه الفجوة: أدلة مفقودة تُكتشف أثناء التدقيق، ومعالجة تمتد لأسابيع، ونطاق تأثير يتسع مع كل إجراء للوكيل لم يتم تسجيله جيدًا. وتستشهد في هذا الصدد بـ Crédit Agricole CIB، التي تقود، وفقًا للنص، تسليمًا يجمع آلاف المطورين موزعين على عشرات البلدان على منصة DevSecOps واحدة، وهو شرط مطلوب لتدقيق العمل العاملية.
تسمية العمل وقياسه
يوصي المصدر بمعالجة هذا المشروع كمنتج كامل، يُسمى « التنفيذ المسجل لـ CI/CD العاملية »، مع موارد تجمع هندسة المنصة، والأمن، والتدقيق، وتجربة المطور. تشمل مخرجاته مخطط تسجيل يلتقط بيانات الإدخال، والمخرجات، واستدعاءات الأدوات، وإصدار النموذج، وربط هوية يربط كل إجراء بمسؤول بشري، وسجلات لقرارات السياسة، بالإضافة إلى آليات إعادة التشغيل والتراجع. يمكن أن يعتمد المتابعة على عمق قائمة الاستثناءات، والوقت المتوسط للحصول على الأدلة، ومعدل نجاح عمليات إعادة التشغيل، ومعدل إعادة فتح الاستثناءات.
إذا كان لا بد من اتخاذ خطوة واحدة، ينصح النص بالبدء بالحالات الأكثر خطورة، مثل تغييرات التبعيات، وتعديلات البنية التحتية ككود (Infrastructure as Code)، وتهيئة الأمن. الاختبار الأخير المقترح هو أن تطلب من فريق التراجع بشكل نظيف عن تعديل مدمج كتبه وكيل، بالاعتماد فقط على القطع الأثرية المسجلة.
