Habr: وكلاء الذكاء الاصطناعي يغيرون التوصيل، والفرق يجب أن تعيد بناء دورة التطوير بالكامل

نُشر على Habr تحليل لسبب أن فريق الهندسة مع وصول وكلاء الذكاء الاصطناعي يواجهون اختناق لا في سرعة كتابة الأكواد بل في تكلفة المراجعة ونقل السياق. يشير المؤلف إلى DORA 2025، حيث يستخدم 90% من متخصصي التكنولوجيا الذكاء الاصطناعي في العمل، وأكثر من 80% يربطونه بنمو الإنتاجية. لكن كلما تسارعت وتيرة إنشاء الأكواد والوثائق وADRs، زادت الحمل على المراجعة والتحكم في الاستقرار.

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

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

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

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

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

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

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

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

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

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