إعادة اختراع فريق التطوير في عصر البرمجة الوكيلة

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

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

من نقص السرعة إلى فائض القدرة

تصف Foxwell مساراً بدأ بفرق تطلق البرمجيات مرتين سنوياً، ثم انتقل عبر Agile والحوسبة السحابية وDevOps والتسليم المستمر إلى عمليات نشر متعددة يومياً. وترى أن ما كان يُقدم بوصفه هدفاً بعيداً، أي السرعة العالية، بدأ يتحول إلى واقع لا تعرف المؤسسات بعد كيف تستثمره.

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

المرتَكز الأول: بناء ما يستحق البناء

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

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

وتعرض Foxwell تجارب لإعادة النظر في حجم الفرق ونسبتها. فبدلاً من نموذج الفريق المكوّن من ستة إلى ثمانية مطورين ومدير منتج واحد، تختبر بعض المؤسسات فرقاً أصغر، بينما اقترح Andrew Ng نموذجاً معاكساً يضم مديرَي منتج لمطور واحد قادر على تنسيق أسطول من الوكلاء. ولا تقدم هذه النماذج كقواعد ثابتة، بل كتجارب تعكس تغير نقطة الاختناق من قدرة التطوير إلى وضوح المتطلبات وسرعة القرارات.

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

المرتَكز الثاني: السرعة تحتاج إلى أمان

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

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

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

كما ترى أن النشر التدريجي، وأعلام الميزات، واختبارات A/B، والنشر الأزرق-الأخضر، تساعد على إدارة التغييرات الكثيرة من دون تعريض جميع المستخدمين لها دفعة واحدة. وتعيد النظر في دور فرق هندسة موثوقية المواقع والمنصات الداخلية، باعتبارها وظائف استشارية وتمكينية توفر مساراً آمناً وممهداً لفرق التطوير.

ما الذي يتغير عملياً؟

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

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