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