البرمجة بسجل تدقيق: قواعد العمل الجديدة مع الوكلاء

بقلم كوامي بواتينغ

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

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

المحادثة ليست سجل العمل

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

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

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

خمس طبقات للعمل المرئي

يمكن للفرق التي تعتمد وكلاء البرمجة أن تتعامل مع كل تغيير باعتباره ملف حالة صغيرًا قابلًا للفحص. وتفيد خمس طبقات على وجه الخصوص:

1. النية: المشكلة، ومعايير القبول، والقيود، والنطاق المطلوب.
2. الخطة: النهج المقترح من الوكيل قبل أن يعدّل الملفات. وفي المهام غير البسيطة، تُعد هذه نقطة تحقق للموافقة، وليست مجرد إضافة شكلية.
3. الفرق: الإضافات والحذوفات الدقيقة، وتغييرات التبعيات، وتعديلات الإعدادات، والأصول المُنشأة.
4. الأدلة: نتائج الاختبارات، ومخرجات أدوات فحص الشيفرة، وفحوصات الأمان، ولقطات الشاشة، ومعاينة مباشرة أو قابلة للنشر حيثما كان ذلك مناسبًا.
5. سجل القرار: تعليقات المراجع، والتغييرات المطلوبة، والموافقة، والرفض، والتراجع، أو أعمال المتابعة.

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

ينبغي ربط الموافقات بالإجراءات

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

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

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

تحوّل المعاينات المراجعة إلى فحص

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

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

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

تحتاج الفروق إلى سياق، لا إلى ألوان فحسب

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

تشمل المطالبات المفيدة للمراجعة ما يلي:

• ما السلوك الظاهر للمستخدم الذي تغيّر؟
• ما الملفات التي تغيّرت فقط لدعم التنفيذ؟
• ما الافتراضات التي وضعها الوكيل بشأن السلوك القائم؟
• ما الاختبارات التي أُضيفت أو عُدّلت أو لم تُشغّل؟
• هل يمكن أن يؤثر هذا التغيير في الأذونات أو الاحتفاظ بالبيانات أو الفوترة أو واجهات برمجة التطبيقات الخارجية؟

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

أرشِف الاستدلال المهم

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

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

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

ما الذي يتغير بالنسبة إلى المهن البرمجية

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

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

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

قاعدة تشغيل بسيطة

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

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