برينس كوهلي، الرئيس التنفيذي لشركة Sauce Labs – سلسلة المقابلات

برينس كوهلي، الرئيس التنفيذي لشركة Sauce Labs، هو مدير تنفيذي مخضرم في مجال التكنولوجيا يمتلك خبرة واسعة تشمل الذكاء الاصطناعي، وبرمجيات المؤسسات، والحوسبة السحابية، والأتمتة، والشبكات، والأمن السيبراني. قبل انضمامه إلى Sauce Labs في فبراير 2025، قضى أكثر من ست سنوات كرئيس تقني لشركة Automation Anywhere، حيث ساهم في تطوير تقنيات الأتمتة المدفوعة بالذكاء الاصطناعي للمؤسسات الكبيرة. في السابق، شغل كوهلي منصب نائب الرئيس الأول للهندسة في ThoughtSpot وتولى أدوار قيادية عليا في إريكسون، بما في ذلك الإشراف على منظمات البحث والتطوير العالمية التي تضم أكثر من 10,000 مهندس. كما أمضى ما يقرب من عقد من الزمن في شركة Citrix يقود مبادرات المنصات، والشبكات السحابية، والهندسة، والعمليات. في بدايات مسيرته، شارك في تأسيس شركة أمن التطبيقات Teros وعمل كقائد تقني في SGI. إلى جانب أدواره التنفيذية، ساهم كوهلي في مبادرات حوكمة التكنولوجيا من خلال مجموعة حوكمة الذكاء الاصطناعي الأخلاقي وشارك سابقًا في مجموعة العمل للأنظمة والتقنيات الآمنة التابعة للمنتدى الاقتصادي العالمي.

Sauce Labs هي شركة جودة برمجيات واختبار مستمر توفر للمؤسسات بنية تحتية وأدوات لاختبار تطبيقات الويب والهواتف المحمولة عبر المتصفحات وأنظمة التشغيل والبيئات الافتراضية والأجهزة الحقيقية. تدعم منصتها قدرات تشمل الاختبار الآلي واليدوي، والاختبار البصري، وتوزيع تطبيقات الهواتف، وتقرير الأخطاء، وإعداد الاختبارات وتحليلها المدعوم بالذكاء الاصطناعي، مع التكامل مع سير عمل التكامل المستمر والتسليم المستمر الشائع. تتجه Sauce Labs بشكل متزايد إلى تموضع تقنيتها حول AURA، منصة ضمان الإصدار الموحد المدعومة بالذكاء الاصطناعي، التي تستخدم وكلاء ذكاء اصطناعي للمساعدة في إنشاء وتنفيذ وتحليل الاختبارات مع الحفاظ على إشراف بشري طوال عملية إصدار البرمجيات. تقول الشركة إن بنيتها التحتية دعمت أكثر من 8.7 مليار تنفيذ اختبار وأكثر من 300,000 مستخدم مؤسسي، مستندة إلى ما يقرب من عقدين من بيانات اختبار عبر المنصات.

قبل الانضمام إلى Sauce Labs، قُدت الأتمتة المدفوعة بالذكاء الاصطناعي في Automation Anywhere وأدرت منظمات سحابية وهندسية كبرى في شركات تشمل إريكسون وCitrix. كيف شكلت تلك التجارب رؤيتك لمشكلة جودة البرمجيات، وما الذي أقنعك بجعل ضمان الإصدار المدعوم بالذكاء الاصطناعي أولوية مركزية في Sauce Labs؟

في إريكسون وCitrix، رأيت مدى سرعة انتشار عطل برمجي وتأثيره على البنية التحتية العالمية، ما يخلق آثارًا كبيرة على الأمن، وعمليات العملاء، والثقة، والإيرادات. أظهر لي Automation Anywhere كيف يغيّر الذكاء الاصطناعي سرعة وهيكل العمل، وتبين أن الاختبار يجب أن يُعاد بناؤه ليتماشى مع وتيرة البرمجيات التي يولدها الذكاء الاصطناعي. كانت Sauce Labs رائدة في أتمتة الاختبارات، لذا فإن ضمان الإصدار المدعوم بالذكاء الاصطناعي هو المشكلة الكبرى التالية التي صُممنا لحلها.

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

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

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

تشير التقارير إلى أن المطورين ينتجون شفرة أكثر بنسبة 741٪ بينما ارتفعت سرعة الإصدار بأقل من 20٪. ما الذي يمنع أنظمة التحقق من مواكبة هذا التقدم، وأين يظهر أكبر عنق زجاجة عادةً في دورة حياة تطوير البرمجيات؟

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

أقرّ أكثر من نصف المؤسسات التي شُوّبت أنها تُطلق برمجيات مع عيوب حرجة عن علم، بينما أفاد 66٪ بأنها ضحّت بجودة أو معايير الاختبار لتلبية موعد نهائي. لماذا تقبل المنظمات هذا المستوى من المخاطرة، وماذا يجب أن يتغير لكي تصبح جودة البرمجيات أولوية تجارية بدلاً من مجرد نقطة تفتيش هندسية نهائية؟

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

تُقدّم Sauce Labs AURA كمنصة حلقة مغلقة تُؤلف وتنفّذ وتُحلل الاختبارات مع التعلم من كل إصدار. كيف يختلف ذلك تقنيًا وتشغيليًا عن توليد الاختبارات المدعوم بالذكاء الاصطناعي، أو سكريبتات الاختبار ذاتية الشفاء، أو أدوات الأتمتة الأخرى التي تستخدمها فرق الهندسة بالفعل؟

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

تم تصميم AURA للتحقق من البرمجيات وفق “نية الأعمال”. كيف تُعرّف تلك النية وتُترجم إلى متطلبات قابلة للاختبار، ومن المسؤول عن الموافقة عليها، وكيف يتعامل المنصة مع المتطلبات الغامضة أو غير المكتملة أو القابلة للتفسير؟

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

تُفيد Sauce Labs أن المؤسسات التي تستخدم AURA شهدت انخفاضًا بنسبة 90٪ في حوادث الإنتاج، وتسريعًا بنسبة 47٪ في دورات الإصدار، واستعادة 38٪ من طاقة الهندسة. كيف تم قياس هذه النتائج، وعلى أي فترات نشر، وما هي آلية التحقق المستقلة التي تميّز تأثير AURA عن التغييرات التنظيمية أو الهندسية الأخرى؟

عبر نشرات المؤسسات، قسنا التغييرات في حوادث الإنتاج، وسرعة دورات الإصدار، وطاقة الهندسة بعد تنفيذ الفرق لـ AURA. شهدت تلك النشرات انخفاضًا بأكثر من 90٪ في حوادث الإنتاج، وتسريعًا بنسبة 47٪ في دورات الإصدار، واستعادة 38٪ من طاقة الهندسة، مع تحقق مستقل للنتائج. أبلغ عملاء مثل Walmart وKeller Williams أيضًا عن تحسينات ملحوظة في تواتر الإصدار، وتغطية الاختبارات، ووقت الدورة.

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

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

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

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

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

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

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

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

شكرًا لكم على المقابلة الرائعة، القراء الذين يرغبون في معرفة المزيد يجب أن يزوروا Sauce Labs.