Ali-Reza Adl-Tabatabai, Gitar’ın Kurucusu ve CEO’su – Röportaj Serisi

Ali-Reza Adl-Tabatabai, Gitar’ın kurucusu ve CEO’sudur. Uber, Google (GOOGL), Facebook (META), Intel (INTC), AMD ve IBM dahil Silikon Vadisi’nin en etkili teknoloji şirketlerinden bazılarında çalışmış deneyimli bir mühendislik lideridir. Gitar’ı 2023’te kurmadan önce Uber’de Kıdemli Mühendislik Direktörü olarak görev yaptı ve şirketin geliştirici platformu girişimlerine liderlik etti. Daha önce Google’da İletişim, Fotoğraflar, Sosyal, Bulut ve teknik altyapı gibi ürünlerin Site Güvenilirliği Mühendisliğini yöneten liderlik rolleri üstlendi.

Kariyerinin önceki dönemlerinde Intel Labs ve Facebook’un HipHop VM ekibinde derleyici teknolojileri, sanal makineler, paralel bilgi işlem sistemleri ve donanım optimizasyonu üzerinde çalıştı; ayrıca Stanford Üniversitesi’nde ileri derleyici tasarımı dersleri verdi. Programlama dilleri, altyapı güvenilirliği, geliştirici araçları ve büyük ölçekli sistem mimarisindeki onlarca yıllık geçmişi, onu yapay zekâ destekli yazılım mühendisliğinin gelişen alanında öne çıkan bir isim haline getirdi.

Gitar, yapay zekâ destekli yazılım geliştirmenin yükselişiyle ortaya çıkan büyüyen bir probleme odaklanıyor: kurumsal sistemlere akan devasa miktardaki makine üretimi kodu doğrulamak ve güvenli hale getirmek. Platform; kod incelemesini otomatikleştirmek, CI/CD işlem hattı arızalarını araştırmak, hata ve güvenlik açıklarını belirlemek, düzeltmeler önermek ve GitHub, GitLab, Jenkins, Jira ile Slack gibi araçlar üzerinden mevcut mühendislik iş akışlarına doğrudan entegre olmak için yapay zekâ ajanlarını kullanıyor. Şirket yalnızca yapay zekâyla kod üretiminde rekabet etmek yerine “ajan tabanlı kalite kapıları” olarak tanımladığı alanda konumlanıyor; yazılım geliştirme giderek özerk ve yapay zekâ destekli kodlama iş akışlarına kayarken mühendislik ekiplerinin güvenilirliği, güvenliği ve operasyonel denetimi korumasına yardım ediyor.

Uber, Google ve Intel Labs’de büyük ölçekli geliştirici platformları ve altyapı üzerinde mühendislik ekiplerine liderlik ettiniz. Bu yolculuktaki hangi deneyimler sizi Gitar’ı kurmaya yöneltti ve neden kod üretimi yerine kod doğrulamaya odaklandınız?

Uber, Google, Facebook ve Intel Labs’de çok farklı ölçeklerde geliştirici platformları üzerinde çalıştım ve aynı ders tekrar tekrar karşıma çıktı: geliştirici deneyimi rekabet avantajıdır. Harika araçlar en iyi mühendisleri çeker ve elde tutar, şirketlerin hızlı hareket etmesini sağlar. Geliştiriciler akışlarını bozmayan, gürültüsüz, hızlı ve angarya işleri otomatikleştiren araçlar ister. Ancak geliştirici araçları son derece parçalıdır ve çoğu şirket tutarlı bir deneyimi bir araya getirmek için devasa mühendislik kaynakları harcar. Bunu düzeltmenin ne kadar büyük bir kaldıraç yarattığını bizzat gördüm.

Yapay zekâ, geliştirici iş akışının çok daha büyük bir bölümünü otomatikleştirmeyi mümkün kılarak denklemi değiştiriyor. Kod üretimi zaten iyi karşılanıyor, fakat bu yalnızca darboğazı daha aşağıya, artık görülmemiş hacimde ürettiğimiz kodun doğrulanması, yeniden düzenlenmesi ve bakımına taşıdı. Gitar burada odaklanıyor. Yapay zekâ daha fazla kod yazdıkça kıt kaynak üretim değil; yayımlanan kodun güvenilirliği, doğruluğu ve sürdürülebilirliğidir. Kod doğrulama, yapay zekâ üretimi kodun üretime gerçekten güvenle ulaşıp ulaşmadığını belirleyen iş akışı bölümüdür ve çözülmesi daha zor, daha değerli problemdir.

Yapay zekâ üretimi kodun yükselişiyle birçok ekip artık “kod aşırı yükü” denilen durumla karşılaşıyor. Bu problem günümüz işletmelerinde ne kadar ciddi ve ekipler en çok nerede zorlanıyor?

Değişim kod yazma bölümünde değil. Bu bölüm zaten çoğu ekibin özümseyebileceğinden daha hızlı ilerliyor. Değişen, sonrasında gelen her şeydir. Yapay zekâ araçları sürekli bir pull request akışı üretiyor ve bunu çoğu zaman ekiplerin inceleyebileceğinden daha hızlı yapıyor; bu da sistemin bu çıktı düzeyi için tasarlanmamış bölümlerinde baskı yaratıyor.

Her değişiklik yine de doğrulamadan geçmelidir: kod incelemesi, CI, güvenlik kontrolleri ve onaylar. Kod daha hızlı üretildi diye bunların hiçbiri ortadan kalkmaz. Eskiden yönetilebilir olan akış bir iş yığınına dönüştü. Ekipler artık fikir veya uygulama nedeniyle değil, güven eksikliği nedeniyle tıkanıyor: Bu yayımlanabilir mi? Güvenli mi? İnce bir şeyi bozdu mu?

Sürtünme artık burada bulunuyor: yaratımda değil, risk yaratmadan kodu bitiş çizgisinden geçirmekte.

Sektör büyük ölçüde daha hızlı kod üretmeye odaklandı. Sizce doğrulama neden gözden kaçtı ve şimdi neden daha kritik hale geliyor?

Çünkü kod üretiminin aşağı akışındaki sistem aynı hızda gelişmedi. Çıktı arttığında aşağıdaki her şey zorlanır. Pull request’ler daha büyük ve daha sık hale gelir. CI arızaları birikmeye başlar. Hiç kimsenin her değişikliği derinlemesine incelemeye vakti olmadığı için inceleme döngüleri sıkışır.

Kalite, mühendisler umursamadığı için değil, hacim ödün vermeyi zorunlu kıldığı için düşmeye başlar. Platform ekipleri işlem hattı sorunlarıyla ilgilenme, arızaları önceliklendirme ve işlerin ilerlemesini sağlama yükünün daha fazlasını üstlenir. Kıdemli mühendisler günlükleri bir araya getiren, sorunları teşhis eden ve neyin güvenle birleştirilebileceğine karar veren koordinatörlere dönüşür.

Ekiplerin iki şekilde de işe yaramayan bir seçim yapması gerekir: kodu hızla geçirip gerilemelerle sonra uğraşmak veya yavaşlayıp kaliteyi korurken hızın düşmesini kabul etmek. Bu gerilim şu anda mühendislik kuruluşlarının tamamında görülüyor.

Gitar kod incelemeleri, testler ve sürekli entegrasyon (CI) iş akışlarını yürütmek için yapay zekâ ajanları kullanıyor. Bu ajanlar geleneksel statik analiz araçlarından ve kural tabanlı işlem hatlarından temelde nasıl ayrılıyor?

Fark yüzeysel değil. Gerçek bir ajanın istemlere yanıt vermekten fazlasını yapması gerekir. Çok adımlı işleri yürütmeli, plan yapmalı, araç kullanmalı, bağlamı izlemeli ve sürekli girdi olmadan görevleri ilerletmelidir.

Çoğu sistem bu çıtayı karşılamıyor. Çıktılar üretiyorlar, ancak yürütmeyi yönetmiyorlar. Bu araçlar gerçek iş akışlarına yerleştirildiğinde boşluklar hızla ortaya çıkıyor. Karmaşıklığı azaltmıyorlar; çoğu durumda birinin yönetmek zorunda olduğu başka bir katman ekliyorlar.

Bu nedenle tartışma “ajanlarımız var mı?” sorusundan “hangi işler gerçekten güvenilir biçimde yürütülebilir?” sorusuna kayıyor.

Güven, yazılım geliştirmede otomasyonun önündeki büyük bir engel. Gitar doğrulama sürecinin ekiplerin dayanabileceği kadar güvenilir olmasını nasıl sağlıyor?

İşe yarayan örüntü basittir: işi daha küçük adımlara bölmek, net sınırlar tanımlamak, çıktıları sürekli doğrulamak ve risk taşıyan kararlarda insanları sürece dahil etmek.

Ajanlar kodu inceleyebilir ve ölçekte gözden kaçması kolay sorunları ortaya çıkarabilir. CI arızalarını analiz edebilir, ilişkili hataları gruplayabilir ve muhtemel temel nedeni gösterebilirler. Düzeltmeler önerebilir ve bazı durumlarda kontrollü biçimde uygulayabilirler.

Bu, mühendislerin yapmak zorunda olduğu manuel ön inceleme miktarını azaltır. Mühendisleri döngüden çıkarmaz, ancak zamanlarını nerede harcadıklarını değiştirir. Çoğu sistem tam bağımsızlıkla değil, kontrol noktalarıyla çalışır.

Platformunuz ekiplerin kendi ajanlarını oluşturmasına izin veriyor. Özelleştirme kurumsal benimseme için ne kadar önemli ve gördüğünüz en ilginç kullanım alanları neler?

Özelleştirme kurumsal benimseme için gereklidir. Her platform ekibi CI’ı şirketinin özel gereksinimlerine uyarlamak için önemli kaynaklar harcar; bu da geleneksel olarak özel betikler, yapılandırmalar, araç entegrasyonları, günlük işleyicileri ve modern geliştirici altyapısını bir arada tutan diğer tüm geçici bağlantıları gerektirir.

Gitar bu işi tek yerde toplar. Platform ekipleri doğal dil istemleriyle özel kontroller yazabilir; böylece çeviri açısından belirsiz kullanıcıya dönük ifadeleri işaretlemek veya AGENTS.md dosyalarındaki güncellemeleri doğrulamak gibi geleneksel program analiziyle zor ya da imkânsız olan şeyleri denetleyebilirler. Pull request’lerin üzerinde özel iş akışlarını da otomatikleştirebilirler: PR’leri Jira sorunlarına bağlamak, çözümlenmemiş inceleme yorumları için takip kayıtları açmak, kararsız testleri otomatik yeniden denemek veya PR özetlerine özel yapılacaklar listeleri eklemek.

En ilginç kullanım alanları genellikle öngörmediklerimizdir. Ekipler kendi kod tabanlarını ve sorun noktalarını herhangi bir sağlayıcıdan daha iyi bilir. “Keşke CI şunu kontrol edebilse” düşüncesini 10 satırlık bir isteme dönüştüren temel bir olanak verdiğinizde, varsayılan olarak asla geliştirmeyeceğimiz şeyleri hemen otomatikleştirmeye başlarlar. İstediğimiz tam olarak budur.

Modern mühendislik ekipleri GitHub, GitLab ve Jira gibi karmaşık bir araç yığınına dayanıyor. Gitar’ın bunların yerine geçmeye çalışmak yerine mevcut iş akışlarına entegre olması ne kadar önemli?

Benimseme, geliştiricilerle zaten bulundukları yerde buluşmaya bağlıdır. Mühendisler öğrenilecek yeni bir arayüz, kontrol edilecek başka bir pano veya araçlar arasında daha fazla bağlam değişimi istemiyor. Mevcut iş akışlarının daha hızlı ve daha sessiz olmasını istiyorlar. Bu nedenle GitHub, GitLab (GTLB), Jira ve yığının geri kalanıyla derin entegrasyon bizim için hoş bir ek değil, stratejinin tamamıdır.

Ancak hedefimiz entegrasyondan ileri gider. Bu araçların yerini almaya çalışmıyoruz, yalnızca onlara bağlanmaya da çalışmıyoruz. Aralarında çalışan iş akışlarını otomatikleştiriyoruz. PR incelemesi, kayıt bağlantısı, takip görevleri, kararsız testlerin yeniden denenmesi; bunların tümü arka planda özerk olarak gerçekleşmelidir. Daha ileriye de gidiyoruz: bir ajan kod incelemesi geri bildirimini karşılamak ve CI arızalarını düzeltmek için PR’ı doğrudan düzenler, sonunda ekibin politikalarını karşılayan değişikliklerin onayını ve birleştirilmesini üstlenir. Geliştiricinin rolü her adımı yürütmekten niyet belirlemeye, sonuçları incelemeye ve istisnaları ele almaya kayar.

Nihai durum geliştiricilerin giriş yaptığı yeni bir araç değildir. Mevcut araçların kendi başlarına daha fazlasını yapmasıdır; böylece geliştiriciler gerçekten kendi değerlendirmelerini gerektiren işe odaklanabilir.

İnsanların yaptığı kod incelemelerinin zamanla kural değil istisna olabileceğini söylediniz. Kuruluşların bu geçiş konusunda rahat hissetmesi için ne olması gerekiyor?

Güven tek seferde değil, aşamalar halinde oluşturulur. Kuruluşların yapay zekânın gerçekten önemli hata ve güvenlik açıklarını bulabildiğini, özel kurallarını hassasiyet ve yüksek kapsamayla uygulayabildiğini kendi kodlarında görmesi gerekir. Buradan özerk birleştirmeye giden yol, artan güvenin dört düzeyinden geçen doğal bir ilerlemedir.

İlk düzey tespittir. Ekipler ajanların düşük yanlış pozitif oranıyla gerçek sorunları bulduğuna güvenmeye başlar. Bu güven yerleşince, kritik sorun bulduğunda yapay zekânın PR’ları otomatik engellemesine izin verirler.

İkinci düzey düzeltmedir. Yapay zekâ sorunları yalnızca işaretlemez; onları düzeltir, PR’ın önünü açar ve insan müdahalesi olmadan CI’ı başarılı hale getirir. Buradaki güven, ajanın sorunları ve CI arızalarını başka bir şeyi bozmadan hassas biçimde çözebilmesi demektir.

Üçüncü düzey onaydır. Ekipler ajanların PR’ları güvenilir şekilde başarılı hale getirdiğini gördükten sonra, kendi tanımladıkları kurallar altında yapay zekânın PR onaylamasına izin verir. Otomatik onayın koşulları üzerinde kuruluşlara açık kontrol vermek, bu adımı pervasız değil güvenli hissettirir.

Dördüncü düzey birleştirmedir. Yapay zekâ, yine ekibin rahat olduğu koşullar altında değişikliği birleştirir. Bu adımın ayrı bir çıtası vardır: ajan birleştirme çatışmalarını gerileme yaratmadan veya ana dalı bozmadan hassas biçimde çözmelidir. Bu, insanların sandığından daha önemlidir; çünkü commit hacmiyle çatışma sıklığı artar ve yapay zekâ daha fazla kod ürettikçe hacim patlıyor. Büyük monorepo’lar bunu zaten hissediyor, yakında herkes hissedecek.

Yapay zekânın varsayılan inceleyiciye dönüşmesi tek bir inanç sıçraması değildir. Bir merdivendir ve kuruluşlar kanıtlar biriktikçe basamakları birer birer çıkar.

Yapay zekâ kodlama sürecinin daha büyük bölümünü üstlendikçe kıdemli mühendislerin rolünün önümüzdeki birkaç yılda nasıl gelişeceğini düşünüyorsunuz?

Kıdemli mühendisler günlükleri bir araya getiren, sorunları teşhis eden ve neyin güvenle birleştirilebileceğine karar veren koordinasyon rollerine şimdiden kayıyor. Bu kimsenin planladığı bir rol değildi; sistemin yük altında bozulmasına verilen bir tepkidir.

Ajanlar tekrarlayan doğrulama işinin daha fazlasını üstlendikçe mühendisler döngüde kalır, ancak yığının daha üstüne çıkar. Manuel ön incelemeye daha az, neyin neden yayımlanması gerektiğine ilişkin kararlara daha fazla zaman ayırırlar.

Gitar kısa süre önce platformu ölçeklemek için 9 milyon dolar yatırım aldı. Bu sermayede en büyük öncelikleriniz neler ve önümüzdeki 12 ila 18 ayda başarı nasıl görünüyor?

Sermaye iki önceliğe gidiyor. Birincisi pazara çıkış: kurumsal satış hareketimizi ölçekliyor ve Gitar’dan yararlanacak ekiplerin varlığımızı bilmesi için geliştirici farkındalığına yatırım yapıyoruz. İkincisi ürün: tamamen özerk kod doğrulama ve kalite vizyonumuza doğru geliştirmeyi sürdürüyoruz; bu da daha derin ajan yetenekleri, daha geniş iş akışı kapsamı ve geliştiricilerin zaten kullandığı araçlarla daha sıkı entegrasyon demektir.

Önümüzdeki 12 ila 18 ayda başarı; Gitar’ı kod tabanlarının tamamında çalıştıran anlamlı bir kurumsal müşteri kitlesi, bizi yapay zekâ destekli kod doğrulamanın varsayılanı olarak tanıyan bir geliştirici topluluğu ve ajanlarımızın zaman içinde inceleme, düzeltme ve birleştirme işinin daha fazlasını özerk yürüttüğüne dair açık kanıt anlamına geliyor. Doğru yoldaysak bir yıl sonraki konuşma yapay zekânın kodu doğrulayıp doğrulayamayacağı değil, ekibin doğrulama işlem hattının ne kadarını ajanlara devrettiği hakkında olacak.

Harika röportaj için teşekkür ederiz. Daha fazla bilgi edinmek isteyen okurlar Gitar‘ı ziyaret edebilir.