مقابلات
علي رضا آدل طباطبائي، مؤسس ومدير تنفيذي في Gitar – سلسلة المقابلات
أضف Unite.AI إلى مصادرك المفضلة على Google
علي رضا آدل طباطبائي، المؤسس والمدير التنفيذي في Gitar، هو قائد هندسي متمرس الذي شغل مناصب في بعض أكثر الشركات التكنولوجية تأثيراً في وادي السيليكون، بما في ذلك Uber و Google (GOOGL ) و Facebook (META ) و Intel (INTC ) و AMD و IBM. قبل إطلاق Gitar في عام 2023، شغل منصب المدير السينيور للهندسة في Uber، حيث ساعد في قيادة مبادرات منصة المطورين في الشركة، بعد أدوار قيادية سابقة في Google للإشراف على هندسة المواقع الموثوقة للمنتجات مثل الاتصالات والصور والاجتماع والسحابة والبنية التحتية الفنية.
في وقت سابق من مسيرته، عمل على تقنيات المترجمات والمكائن الافتراضية وأنظمة الحوسبة الموازية وتنظيم الأجهزة في Intel Labs وفريق HipHop VM في Facebook، بالإضافة إلى تدريس تصميم المترجمات المتقدم في جامعة ستانفورد. وقد وضعت خلفيته الطويلة في لغات البرمجة وثبات البنية التحتية وأدوات المطورين وهندسة الأنظمة على نطاق واسع في وضعته كشخصية بارزة في مشهد هندسة البرمجيات المدعومة بالذكاء الاصطناعي المتطور.
Gitar تركز على مشكلة متنامية بسبب تطوير البرمجيات بمساعدة AI: التحقق من الكم الهائل من الشيفرة التي تولدها الآلات وتأمينها قبل تدفقها إلى أنظمة المؤسسات. تستخدم المنصة وكلاء AI لأتمتة مراجعة الشيفرة والتحقيق في إخفاقات CI/CD وتحديد الأخطاء والثغرات واقتراح الإصلاحات والتكامل مع GitHub وGitLab وJenkins وJira وSlack. وبدل المنافسة في توليد الشيفرة فقط، تتمحور الشركة حول بوابات جودة وكيلة تحافظ على الموثوقية والأمن والإشراف التشغيلي.
لقد قادت الهندسة في Uber و Google و Intel Labs، وعملت على منصات المطورين على نطاق واسع. ما هي الخبرات المحددة من هذه الرحلة التي أدت بك إلى تأسيس Gitar، ولماذا التركيز على التحقق من صحة الكود بدلاً من توليده؟
على مدار Uber و Google و Facebook و Intel Labs، عملت على منصات المطورين على مستويات مختلفة، وظهرت نفس الدروس دائماً: تجربة المطور هي ميزة تنافسية. الأدوات الجيدة تجذب وتحافظ على أفضل المهندسين وتسمح للشركات بالتحرك بسرعة. يريد المطورون أدوات سريعة وخالية من الضوضاء التي تبقيه في تدفق العمل وتأتمتيك العمل الشاق. لكن أدوات المطورين متفرقة للغاية، وتستخدم معظم الشركات موارد هندسية هائلة فقط لتحقيق تجربة مترابطة. رأيت بنفسي كم هناك من قوة في إصلاح ذلك.
يغير AI المعادلة لأنه يتيح أتمتة أجزاء أكبر بكثير من سير عمل المطور. توليد الشيفرة مغطى جيدًا بالفعل، لكنه نقل الاختناق إلى المراحل اللاحقة: التحقق وإعادة الهيكلة والصيانة. تُنتج الشيفرة الآن أسرع من أي وقت مضى، ولذلك تركز Gitar على ما يحدث بعد التوليد حتى تصبح زيادة المخرجات زيادة حقيقية في الإنتاجية لا تراكمًا للمخاطر.
مع صعود الكود الذي تم توليده بمساعدة الذكاء الاصطناعي، يتعامل العديد من الفرق الآن مع ما يسمى “التحميل الزائد للكود”. كم هي هذه المشكلة كبيرة داخل المؤسسات اليوم، وأين يتعثر الفرق أكثر؟
التحول لا يتعلق بكتابة الشيفرة، فهذا الجزء يتحرك أسرع مما تستطيع معظم الفرق استيعابه. ما تغير هو كل ما يأتي بعده. تنتج أدوات AI تدفقًا مستمرًا من طلبات السحب أسرع من قدرة الفرق على مراجعتها، فتضغط على أجزاء من النظام لم تُصمم لهذا الحجم.
كل تغيير يجب أن يمر عبر التحقق من الصحة. مراجعة الكود. CI. التحقق الأمني. الموافقات. لا شيء من ذلك يختفي فقط لأن الكود يتم توليده بشكل أسرع. ما كان يعتبر تدفقاً قابلاً للإدارة قد تحول إلى قائمة انتظار. الفرق لا تعوق على الأفكار أو التنفيذ بعد الآن. إنها معوقة على الثقة. هل يمكن شحن هذا؟ هل هو آمن؟ هل كسر شيئاً دقيقاً؟
هذا هو حيث تقع الاحتكاكات الآن. ليس في الإنشاء، ولكن في الحصول على الكود عبر خط النهاية دون إدخال المخاطر.
ركزت الصناعة إلى حد كبير على توليد الشيفرة بسرعة أكبر. لماذا جرى تجاهل التحقق، ولماذا يزداد أهمية الآن؟
لأن النظام الواقع بعد توليد الشيفرة لم يتطور بالسرعة نفسها. عندما تزيد المخرجات يتعرض كل ما بعدها للضغط؛ تكبر طلبات السحب وتتكرر، وتتراكم إخفاقات CI، وتضيق دورات المراجعة لأن لا أحد يملك وقتًا للتعمق في كل تغيير.
تبدأ الجودة في التراجع، لا بسبب عدم اهتمام المهندسين، بل لأن الحجم يفرض مفاضلات. تتحمل فرق المنصة مشكلات خطوط الأنابيب وفرز الإخفاقات والحفاظ على التدفق، فيما يتحول كبار المهندسين إلى منسقين يجمعون السجلات ويشخصون المشكلات ويقررون ما يمكن دمجه بأمان.
تواجه الفرق خيارين غير مرضيين: تمرير الشيفرة بسرعة ومعالجة التراجعات لاحقًا، أو الإبطاء لحماية الجودة مع قبول انخفاض السرعة. هذا التوتر ظاهر الآن في مؤسسات الهندسة.
تستخدم Gitar وكلاء AI لمراجعة الشيفرة والاختبار ومسارات CI. كيف يختلف هؤلاء الوكلاء جذريًا عن أدوات التحليل الساكن وخطوط الأنابيب القائمة على القواعد؟
الفرق ليس شكليًا. يجب أن يتعامل الوكيل الحقيقي مع عمل متعدد الخطوات، ويخطط ويستخدم الأدوات ويحافظ على السياق ويدفع المهمة إلى الأمام دون طلب إدخال مستمر.
معظم الأنظمة لا تبلغ هذا المستوى. هي تنتج مخرجات لكنها لا تدير التنفيذ. وعند وضعها في سير عمل حقيقي تظهر الفجوات بسرعة؛ لا تقلل التعقيد، بل تضيف طبقة أخرى يحتاج شخص إلى إدارتها.
لذلك يتحول السؤال من «هل لدينا وكلاء؟» إلى «ما العمل الذي يمكنهم إنجازه بموثوقية؟»
الثقة عائق رئيسي أمام الأتمتة في تطوير البرمجيات. كيف تضمن Gitar موثوقية التحقق إلى درجة اعتماد الفرق عليه؟
النمط الناجح بسيط: تقسيم العمل إلى خطوات أصغر، ووضع حدود واضحة، والتحقق المستمر من المخرجات، وإبقاء البشر مشاركين حيث تحمل القرارات مخاطرة.
يستطيع الوكلاء مراجعة الشيفرة وكشف مسائل يسهل تفويتها على نطاق واسع، وتحليل إخفاقات CI وتجميع الأخطاء المرتبطة وتحديد السبب المرجح واقتراح إصلاحات أو تطبيقها بصورة محكومة.
يقلل ذلك الفرز اليدوي ولا يزيل المهندسين من الحلقة، بل يغير موضع وقتهم. تعمل معظم الأنظمة بنقاط تحقق لا باستقلال كامل.
تتيح منصتكم للفرق إنشاء وكلائها. ما أهمية التخصيص لاعتماد المؤسسات، وما أكثر حالات الاستخدام إثارة للاهتمام؟
التخصيص أساسي. تنفق كل فرق المنصة موارد كبيرة لتكييف CI مع احتياجات شركتها عبر نصوص مخصصة وإعدادات وتكاملات ومعالجات سجلات وغيرها من الوصلات التي تمسك البنية الحديثة معًا.
تختصر Gitar هذا العمل. تكتب الفرق فحوصًا مخصصة بلغة طبيعية للتحقق مما يصعب على التحليل التقليدي، مثل اكتشاف نصوص واجهة ملتبسة للترجمة أو التحقق من تحديثات AGENTS.md، كما تؤتمت ربط طلبات السحب بتذاكر Jira وإعادة الاختبارات المتذبذبة وإنشاء مهام متابعة.
أكثر الحالات إثارة هي التي لم نتوقعها. تعرف الفرق قواعد شيفرتها وآلامها أفضل من أي بائع؛ وعندما تتحول عبارة «نتمنى لو يفحص CI هذا» إلى مطالبة من عشرة أسطر، تبدأ بأتمتة أمور لم نكن سنبنيها افتراضيًا.
تعتمد الفرق الحديثة على GitHub وGitLab وJira. ما أهمية اندماج Gitar في سير العمل الحالي بدل محاولة استبداله؟
يعتمد الاعتماد على لقاء المطورين حيث يعملون. لا يريدون واجهة أو لوحة أخرى ولا مزيدًا من تبديل السياق؛ يريدون أن تصبح مساراتهم الحالية أسرع وأهدأ. لذا فإن التكامل العميق مع GitHub وGitLab (GTLB ) وJira وبقية الأدوات هو الاستراتيجية كلها.
طموحنا يتجاوز التكامل. نحن نؤتمت سير العمل العابر للأدوات: مراجعة الطلب وربطه بالتذكرة والمهام اللاحقة وإعادة الاختبارات. يعدل الوكيل الطلب لمعالجة الملاحظات وإصلاح CI، ثم يتولى الموافقة والدمج ضمن سياسات الفريق. ينتقل دور المطور من قيادة كل خطوة إلى تحديد النية ومراجعة النتائج والاستثناءات.
الحالة النهائية ليست أداة جديدة يسجل المطور الدخول إليها، بل أدواته الحالية وهي تنجز المزيد تلقائيًا كي يركز على العمل الذي يحتاج فعلًا إلى حكمه.
لقد ذكرت أن المراجعة البشرية للكود قد تصبح في النهاية الاستثناء وليس القاعدة. ما الذي يجب أن يحدث لكي تشعر المنظمات بالراحة مع هذا التحول؟
الثقة تبنى على مراحل، وليس كلها في المرة الواحدة. المنظمات تحتاج إلى رؤية، مع كودها الخاص، أن الذكاء الاصطناعي يمكن أن يجد الأخطاء والثغرات الأمنية التي تهم حقاً وينفذ قواعدها المخصصة بدقة وغطاء عالٍ. من هناك، فإن المسار إلى الدمج التلقائي هو تقدم طبيعي عبر أربع مستويات من الثقة المتزايدة.
المستوى الأول هو الكشف. تكتسب الفرق الثقة بأن الوكلاء يجدون قضايا حقيقية مع معدل إيجابي كاذب منخفض. بمجرد أن تُثبت هذه الثقة، يسمحون للذكاء الاصطناعي بمنع طلبات Pull تلقائياً عند العثور على قضايا حرجة.
المستوى الثاني هو الإصلاح. لا يجد الذكاء الاصطناعي فقط المشاكل، بل يحلها، ويفك الحظر عن طلب Pull ويجعل CI أخضر دون تدخل بشري. الثقة هنا تعني أن الوكيل يمكنه حل المشاكل وفشل CI بدقة، دون كسر الأشياء.
المستوى الثالث هو الموافقة. بمجرد أن ترى الفرق الوكلاء يؤدون طلبات Pull بشكل موثوق، يسمحون للذكاء الاصطناعي بموافقة طلبات Pull تحت القواعد التي يحددونها. إعطاء المنظمات التحكم الصريح في شروط الموافقة التلقائية هو ما يجعل هذا الخطوة تشعر بالأمان بدلاً من التهور.
المستوى الرابع هو الدمج. يصل الوكيل التغيير، مرة أخرى تحت الشروط التي تتوافق معها الفريق. هذا الخطوة له عتبة خاصة به: يجب على الوكيل حل النزاعات المتعلقة بالدمج بدقة، دون إدخال انحدارات أو كسر الرئيسي. هذا يهم أكثر مما يُدرك، لأن تكرار النزاعات يزيد مع تدفق الإرسال، وتدفق الإرسال يفجر مع توليد الذكاء الاصطناعي للمزيد من الكود.
التحول إلى الذكاء الاصطناعي كمراجع افتراضي ليس قفزة واحدة من الإيمان. إنه سلم، وتسلق المنظمات درجاته واحدة تلو الأخرى مع تجميع الأدلة.
كيف ترى دور المهندسين الكبار يتطور على مدى السنوات القليلة القادمة مع اتخاذ الذكاء الاصطناعي المزيد من عملية الترميز؟
المهندسون الكبار يتحولون بالفعل إلى أدوار تنسيق، حيث يجمعون بين سجلات الأخطاء، ويشخصون المشاكل، ويتخذون قرارات حول ما يمكن شحنه. هذا ليس دوراً مخططاً له. إنه رد فعل على نظام ينهار تحت الحمل.
مع اتخاذ الوكلاء المزيد من العمل التكراري للتحقق من الصحة، يبقى المهندسون في الحلقة، ولكنهم يتحركون إلى أعلى السلسلة. يقضون وقتًا أقل في التriage اليدوي، وأكثر وقتًا في اتخاذ قرارات حول ما يجب شحنه ولماذا.
جمعت Gitar مؤخرًا 9 ملايين دولار لتوسيع المنصة. ما أولويات هذا رأس المال، وكيف يبدو النجاح خلال 12 إلى 18 شهرًا؟
تذهب الأموال إلى أولوياتين. الأول هو التسويق: نحن نمو حركتنا المؤسسية ونتحقق من الوعي بين المطورين حتى تعرف الفرق التي سوف تستفيد من Gitar أننا موجودون. الثاني هو المنتج: نحن نمو لتحقيق رؤيتنا للتحقق التلقائي الكامل من جودة الكود، مما يعني قدرات وكيل أعمق، وتغطية سير عمل أوسع، وتكامل أوثق مع الأدوات التي يستخدمها المطورون بالفعل.
النجاح على مدى السنوات 12 إلى 18 المقبلة يبدو وكأنه قاعدة هامة من العملاء المؤسسيين الذين يديرون Gitar عبر قواعد بياناتهم، ومجتمع من المطورين يعترف بنا كافتراضي للتحقق من صحة الكود المدعوم بالذكاء الاصطناعي، والدليل الواضح على أن وكلائنا يقومون بمزيد من العمل المراجعة والإصلاح والدمج بشكل تلقائي مع مرور الوقت. إذا كنا على المسار الصحيح، فإن المحادثة بعد عام لن تكون حول ما إذا كان الذكاء الاصطناعي يمكن أن يثبت صحة الكود، بل حول حجم مسارات التحقق من الصحة التي سلمها الفريق إلى الوكلاء.
شكراً على المقابلة الرائعة، القراء الذين يرغبون في التعلم المزيد يجب أن يزوروا Gitar.
