نرى أن وكلاء الذكاء الاصطناعي أصبحوا جزءًا لا يتجزأ من بيئة عمل المطورين، لكن هل يترجم هذا بالضرورة إلى تسريع عمل الفرق الهندسية بأكملها؟ تشير الملاحظات الأخيرة من العديد من المؤسسات الهندسية، بما في ذلك وكالات البرمجيات واستوديوهات الألعاب ومقدمي الخدمات المالية، إلى أن الإجابة ليست واضحة بالقدر الذي قد نتوقعه.
بينما يرى المطورون الأفراد مكاسب واضحة في السرعة بفضل استخدام وكلاء الذكاء الاصطناعي يوميًا، فإن هذه المكاسب غالبًا ما تتوقف عند مستوى الفريق.
سرعة المطور الفردي لا تعني تسليمًا أسرع للفريق
على الرغم من أن حوالي 80% من المهندسين في بعض الشركات يستخدمون وكلاء الذكاء الاصطناعي بشكل يومي، فإن الشركات تواجه تحديات في تحويل هذه السرعة الفردية إلى تسليم أسرع للمشاريع كفريق. تظهر ثلاثة سيناريوهات رئيسية تبرز هذه المشكلة:
1. الجميع يمتلك وكيلاً، ولا أحد يشارك الإعدادات. عندما يُسأل المطورون عما إذا كانوا يشاركون التوجيهات (prompts) أو القواعد أو ملفات التعليمات لوكلاء الذكاء الاصطناعي، تكون الإجابة غالبًا بالنفي. حتى الفرق التي بدأت في وضع ممارسات رسمية، تنتشر المعرفة فيها ببطء شديد وغير منظم. على سبيل المثال، يصف أحد رؤساء الهندسة في شركة للتقنيات القانونية كيف تنتشر المعايير «ببطء» من مستودعات فريق الذكاء الاصطناعي إلى المشاريع القديمة من خلال «مشاركة ما هو فعال». عندما تكون المشاركة منهجية، قد تكون هشة، حيث إن تحديث القواعد الأساسية يتطلب تحديثًا يدويًا في جميع المستودعات التي قد تكون مخصصة بالفعل. هذا يؤدي إلى فجوة متزايدة داخل الفريق. يلاحظ مدير هندسة في شركة خرائط أن «20% من المهندسين ينتجون 80% من الكود أو يستهلكون 80% من الرموز». هذا يثير تساؤلات حول فعالية استخدام الـ 80% الآخرين.
تحولات في عنق الزجاجة وعقبات تشغيلية جديدة
2. التنفيذ أصبح رخيصًا، لكن المراجعة لم تتغير. صرح رئيس الهندسة في شركة التقنيات القانونية بأن «عنق الزجاجة ينتقل إلى مرحلة مراجعة الكود والتخطيط». على الرغم من سرعة التنفيذ، فقد زادت أوقات مراجعة طلبات السحب (PRs) بسبب الحاجة إلى التدقيق البشري وانعدام الثقة في جودة الكود المنتج بواسطة الذكاء الاصطناعي. تصف مجموعة منصات في شركة شبكات كبيرة، حيث يستخدم الجميع الوكلاء يوميًا، نفس المشكلة: «نحن نحاول تطبيق عمليات غير قائمة على الوكلاء على عمل يتغير بسرعة كبيرة جدًا». يشير مهندس رئيسي في شركة ألعاب إلى أن التجريب شيء، ووضع الأشياء في الإنتاج مع جميع التدفقات والمراجعات والمشكلات التي يتعامل معها الناس في عام 2026 شيء آخر.
3. أتمتة الأعمال الروتينية تخلق عبئًا تشغيليًا جديدًا. الفرق تعرف بالضبط ما يمكن أن توكله لوكلاء الذكاء الاصطناعي، مثل تشغيل مهام محددة عند كل طلب دمج (merge request) أو تحديث الوثائق تلقائيًا كل ليلة. الطموح يتجاوز ذلك ليشمل ترقية المكتبات والأطر ومعالجة الثغرات الأمنية بشكل مستقل. لكن العديد من الفرق تجد صعوبة في تحقيق هذه الأتمتة الخلفية بسبب نقص الوقت والبنية التحتية المخصصة. حتى الفرق التي تنجح في بناء مسارات عمل تشغيلية تواجه تحديات في التوسع، مثل كيفية توزيع التحديثات على مشاريع متعددة أو من يمتلك ويحافظ على هذه الأتمتة. على سبيل المثال، قام مهندس كبير في شركة استشارية ببناء وكيل يعمل في حاوية Docker على جهاز افتراضي ويتفاعل مع الـ webhooks، لكنه واجه مشكلة رئيسية في صيانة هذا النظام وتوزيع تحديثاته.
ما يجمع هذه التحديات هو أن مجرد توفير وكلاء ذكاء اصطناعي قادرين لكل مطور لا يحل المشكلات بمفرده. تفتقر بعض الفرق إلى البنية التحتية المشتركة، بينما تبنيها فرق أخرى وتكتشف العمل المستمر المطلوب لصيانتها.
ما الذي يعنيه هذا للمطورين؟
بالنسبة للمطورين ومصممي المنتجات في عالمنا العربي، نرى أن التركيز يجب أن ينتقل من مجرد زيادة السرعة الفردية إلى كيفية دمج وكلاء الذكاء الاصطناعي بشكل فعال ومنظم ضمن سير عمل الفريق. يتطلب هذا وضع معايير مشتركة للإعدادات والتوجيهات، وإعادة تقييم عمليات مراجعة الكود لتتناسب مع سرعة إنتاج الذكاء الاصطناعي، والتفكير في بنية تحتية قوية لدعم الأتمتة المستمرة وصيانتها. التحدي الحقيقي يكمن الآن في إدارة وتوسيع نطاق الأتمتة، وليس فقط في توليد الكود بسرعة.
المصدر: blog.jetbrains.com