غوتام كورلام، مهندس رئيسي في Sonar – سلسلة المقابلات

Gautam Korlam، مهندس رئيسي في Sonar، هو مهندس برمجيات مخضرم وقائد تقني ركّزت مسيرته على بنية تحتية للمطورين، جودة الشيفرة، الأتمتة، وتطوير البرمجيات المدعوم بالذكاء الاصطناعي. قبل انضمامه إلى Sonar، شارك في تأسيس Gitar وشغل منصب الرئيس التقني، حيث بنى منصة أصلية للذكاء الاصطناعي صُممت لأتمتة مراجعة الشيفرة، تشخيص فشل التكامل المستمر (CI)، تحديد الأسباب الجذرية، وتوليد الإصلاحات. استحوذت Sonar على Gitar في مايو 2026، وانضم كورلام وفريق Gitar إلى الشركة لمواصلة تطوير التقنية كجزء من منصة التحقق من الشيفرة الأوسع لـ Sonar. قبل Gitar، قضى كورلام ما يقرب من عقد من الزمن في Uber، بدءًا من مهندس مؤسس في فريق منصة الهواتف المحمولة وصولاً إلى مهندس رئيسي. خلال فترة عمله، ساهم في بناء وتوسيع بنية تحتية مركزية للمطورين في Uber، قاد مبادرات كبرى للـ monorepo ونظام البناء، طوّر بيئات تطوير عن بُعد وأدوات CI/CD، وجرب نماذج لغة كبيرة مفتوحة المصدر مثل StarCoder وOctoCoder وCode Llama لتحسين الترميز المدعوم بالذكاء الاصطناعي داخل قاعدة شيفرة Uber. تشمل خبراته السابقة أدوار هندسية في Lookout وأعمال بحثية في جامعة كاليفورنيا سانتا باربارا، بالإضافة إلى تدريبات صيفية مع Microsoft وOracle.

Sonar هي شركة برمجيات تركز على التحقق من الشيفرة، مراجعة الشيفرة الآلية، جودة الشيفرة، وأمان التطبيقات. منصة SonarQube الرائدة تحلل الشيفرة المكتوبة من قبل المطورين والشيفرة المولدة بالذكاء الاصطناعي لتحديد الأخطاء، الثغرات، مشاكل الصيانة، وغيرها من قضايا الجودة قبل وصولها إلى الإنتاج، مع عروض تمتد عبر السحابة، الإدارة الذاتية، وتدفقات عمل بيئات التطوير المتكاملة. تقول Sonar إن تقنيتها يستخدمها أكثر من 7 ملايين مطور و22,000 عميل، وتُحلل أكثر من 750 مليار سطر شيفرة يوميًا. وسّع الاستحواذ على Gitar هذا النهج إلى مراجعة الشيفرة الأصلية للذكاء الاصطناعي وإصلاحها، من خلال دمج محرك التحقق في SonarQube مع أدوات ذكية قادرة على مراجعة الشيفرة، التحقيق في فشل CI، واقتراح أو تطبيق الإصلاحات مع تزايد الاعتماد على الذكاء الاصطناعي في تطوير البرمجيات.

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

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

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

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

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

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

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

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

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

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

تجمع Sonar بين مراجعات طلب السحب المدركة للسياق والتحليل الحتمي وبوابات الجودة. كيف يبدو عملية تحقق متعددة الطبقات فعّالة، وكيف ينبغي للطبقات المختلفة التفاعل دون تكرار العمل أو إغراق المطورين بالاكتشافات؟

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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