يقضي المطورون الآن 11.4 ساعة أسبوعياً في مراجعة الكود المولد بواسطة الذكاء الاصطناعي، متجاوزين بذلك 9.8 ساعة لا يزالون يقضونها في كتابة الكود بأنفسهم، وفقاً لاستطلاع أجري عام 2026 وشمل 2900 مهندس. لقد تحولت نقطة الاختناق من "هل يستطيع الذكاء الاصطناعي إنتاج الكود؟" إلى "هل يمكننا الوثوق بالكود الذي ينتجه؟"، وتتجه الفرق الآن نحو سير عمل يعتمد على وكلاء الذكاء الاصطناعي المتعددين (multi-agent AI workflows) الذي يعد بمسارات قرار أكثر وضوحاً وثقة أعلى.

الاستطلاع الذي أثار النقاش

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

تعكس هذه الأرقام إحباطاً متزايداً: فبإمكان نموذج واحد متعدد الأغراض كتابة دالة (function) في ثوانٍ، ولكنه يتخذ أيضاً خيارات خفية تتعلق بهياكل البيانات (data structures)، ومعالجة الأخطاء (error handling)، وتحسينات الأداء (performance optimizations) دون ترك أي سجل لها. ينتهي الأمر بالمطورين إلى إجراء هندسة عكسية لتلك القرارات، وهي عملية قد تستهلك يوم عمل كاملاً.

لماذا لم يعد النموذج الواحد كافياً

لسنوات، كان سير العمل النموذجي يبدو هكذا: يكتب المطور أمراً (prompt)، فيقوم النموذج بإنشاء ملف، ثم ينسخه المطور إلى قاعدة الكود (codebase). تنجح هذه الحيلة في العروض التوضيحية السريعة، لكن البرمجيات المخصصة للإنتاج (production software) تتطلب ما هو أكثر من مجرد مخرجات من محاولة واحدة. فعندما يقرر النموذج، على سبيل المثال، استخدام قائمة مرتبطة (linked list) بدلاً من مصفوفة (array) أو تجاهل الاستثناءات (exceptions) بصمت، فإن هذه الخيارات تندمج في الكود وتختفي عن نظر المراجع.

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

تقسيم المهمة: كيف تساعد الأنظمة متعددة الوكلاء

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

  • وكيل المعماري (Architect agent): ينتج وثيقة تصميم رفيعة المستوى، ويحدد نماذج البيانات، وعقود واجهة برمجة التطبيقات (API contracts)، واستراتيجيات معالجة الأخطاء.
  • وكيل التنفيذ (Implementation agent): يكتب الكود الذي يتبع المعمارية بدقة، مستخدماً المواصفات كقائمة مراجعة.
  • وكيل التحقق (Verification agent): ينشئ اختبارات الوحدة (unit tests)، أو يجري تحليلاً ثابتاً (static analysis)، أو يجهز أنابيب CI/CD، مع التركيز فقط على ضمان الجودة.

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

الأدوات التي تجعل سير عمل الوكلاء المتعددين عملياً

يقوم المطورون بالفعل بتجميع هذه المسارات باستخدام مزيج من الأدوات المساعدة:

  • تكاملات بيئة التطوير المتكاملة (IDE integrations) تسمح للوكلاء بالظهور كلوحات جانبية، مما يتيح تمرير وثيقة المعمارية إلى مساعد توليد الكود بنقرة واحدة.
  • أدوات واجهة سطر الأوامر (CLI utilities) تمكن من تشغيل تسلسلات برمجية: تشغيل المعماري، ثم تمرير مخرجاته إلى المبرمج، ثم تسليم النتيجة إلى المختبر.
  • أطر العمل (Frameworks) توفر مكتبات لبناء وكلاء مخصصين يمكن استبدالهم حسب احتياجات المشروع.
  • المنصات القائمة على المواصفات أولاً (Specification-first platforms) تتطلب ملف متطلبات رسمياً قبل بدء أي عملية توليد، مما يضمن عدم إمكانية تخطي خطوة التصميم.

تشير نسبة الـ 70% في الاستطلاع إلى أن معظم الفرق قد قامت بالفعل ببناء نسخ مخصصة (ad-hoc) من هذه المسارات. المنصات الجديدة تقوم ببساطة بتقنين ما كان المهندسون يفعلونه يدوياً.

من المستفيد—ومن قد يتخلف عن الركب

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

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

ما يجب مراقبته في الأشهر القادمة

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

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