نموذج تسليم تكنولوجيا المعلومات باستخدام وكلاء البرمجيات الذكاء الاصطناعي

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

تبدأ الأسئلة الأكثر جوهرية في الظهور عندما يدرك الفريق أن عنق الزجاجة في تسليم البرمجيات ليس سرعة الكتابة. فالمتطلبات لا تزال غامضة. وتتراكم مراجعات الكود. ويأتي الاختبار متأخرًا. وتستغرق الحوادث وقتًا طويلاً لفهمها. ولا يزال تسليم المهام بين الأدوار المختلفة مصدرًا للتأخير لا تمسه أي أداة مساعدة في البرمجة.

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

ما الذي يتغير عندما يبدأ الذكاء الاصطناعي في العمل ضمن سير العمل

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

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

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

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

ليس وكيلاً واحدًا لكل شيء

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

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

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

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

يمكن دمج وكيل الأمان (Security agent) في وقت مبكر لفحص التبعيات عالية المخاطر، ووضع علامات على أنماط البرمجة المعرضة للخطر، والتحقق من تعرض الأسرار (secret exposure)، وربط التغييرات بسياسات البرمجة الآمنة. عندما يضيف وكيل المطور مكتبة جديدة، يمكن لوكيل الأمان أن يشير فورًا إلى أن هذه المكتبة بها مشكلة تحتاج إلى مراجعة.

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

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

تخيل فريقًا يقوم ببناء تحسين على وحدة خدمة العملاء في نظام CRM داخلي. يقوم وكيل المحلل بتقسيم المتطلبات إلى قصص مستخدم. يقوم وكيل المطور بإنشاء مسودة التنفيذ. يقوم وكيل ضمان الجودة بتوليد اختبارات الوحدة وسيناريوهات الانحدار. يقوم وكيل الأمان بفحص التبعيات الجديدة وأنماط الوصول إلى بيانات العملاء. يقدم وكيل المراجع تعليقات أولية على طلب السحب. يقوم المهندس البشري بمراجعة التصميم، وإصلاح الحالات الحدودية (edge cases)، ويقرر ما إذا كان التغيير يستحق الدمج. يقوم خط أنابيب CI/CD بتشغيل الضوابط التلقائية قبل أن يتمكن التغيير من المضي قدمًا. هذا النمط أكثر واقعية من سرد "الذكاء الاصطناعي يكتب التطبيق بأكمله."

عمليات تكنولوجيا المعلومات: من التنبيه إلى إجراء أسرع

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

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

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

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

ضوابط لا تقبل المساومة

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

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

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

لا ينبغي قياس نجاح وكلاء الهندسة فقط من خلال كمية الكود المنتجة. المقاييس الأكثر صلة هي المهلة الزمنية (lead time)، وتسرب العيوب (defect leakage)، ومتوسط وقت الحل للحوادث (MTTR)، ورضا المطورين، وعبء المراجعة. يجب قراءة المقايضات هنا بأمانة. إذا انخفضت المهلة الزمنية ولكن زاد تسرب العيوب، فإن النموذج ليس صحيًا بعد. إذا أصبحت البرمجة أسرع ولكن عبء المراجعة قفز، فإن الشركة فقط تنقل عنق الزجاجة.

متى لا يكون هذا النمط مناسبًا بعد

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

عادةً ما تمتلك المؤسسات الأكثر استعدادًا خط أنابيب هندسي ناضج بما فيه الكفاية، ومعايير برمجة واختبار واضحة، و ITSM ومراقبة متصلة، وملكية واضحة بين الهندسة والمنصة والأمن والعمليات.

ستصبح هندسة المنصات (Platform engineering) وظيفة رئيسية في هذا النموذج. ليس فقط لأنهم يبنون منصة المطورين، ولكن لأنهم يجب أن يوفرون سجل أدوات آمن، والوصول إلى CI/CD والمراقبة بشكل خاضع للرقابة، وفرض السياسات، ومسار التدقيق، وبيئة تفصل بين إجراءات المسودة والاختبار والإنتاج. بدون انضباط المنصة، ستتحول وكلاء البرمجيات بسرعة إلى مجموعة من الأتمتة غير المنضبطة التي يصعب تدقيقها.

أسئلة للتفكير فيها

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

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

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