Gautam Korlam, Sonar’da Kıdemli Mühendis – Röportaj Serisi

Gautam Korlam, Sonar’da Kıdemli Mühendis, geliştirici altyapısı, kod kalitesi, otomasyon ve yapay zeka destekli yazılım geliştirme üzerine odaklanan deneyimli bir yazılım mühendisi ve teknoloji lideridir. Sonar’a katılmadan önce Gitar’ı kurmuş ve CTO olarak görev yapmış, kod incelemesini otomatikleştiren, sürekli entegrasyon (CI) hatalarını teşhis eden, kök nedenleri belirleyen ve düzeltmeler üreten AI‑yerel bir platform inşa etmiştir. Sonar, Gitar’ı Mayıs 2026’da satın almış ve Korlam ile Gitar ekibi, teknolojiyi Sonar’ın daha geniş kod doğrulama platformunun bir parçası olarak geliştirmeye devam etmiştir. Gitar’dan önce Korlam, Uber’de neredeyse on yıl çalışmış, mobil platform ekibinde kurucu mühendis olarak başlayıp Kıdemli Mühendis pozisyonuna yükselmiştir. Görev süresince Uber’in merkezi geliştirici altyapısını inşa ve ölçeklendirmeye yardımcı olmuş, büyük monorepo ve derleme sistemi girişimlerini yönetmiş, uzaktan geliştirici ortamları ve CI/CD araçları geliştirmiş ve StarCoder, OctoCoder ve Code Llama gibi açık kaynak büyük dil modelleriyle deneyler yaparak Uber kod tabanında AI‑destekli kodlamayı iyileştirmiştir. Önceki deneyimleri arasında Lookout’ta mühendislik rolleri, UC Santa Barbara’da araştırma çalışmaları ve Microsoft ve Oracle’da stajlar yer alır.

Sonar, kod doğrulama, otomatik kod incelemesi, kod kalitesi ve uygulama güvenliğine odaklanan bir yazılım şirketidir. Öncü SonarQube platformu, geliştiricilerin yazdığı ve AI tarafından üretilen kodu analiz ederek hataları, güvenlik açıklarını, sürdürülebilirlik sorunlarını ve üretime ulaşmadan önce diğer kalite problemlerini tespit eder; hizmetleri bulut, kendi kendine yönetilen ve entegre geliştirme ortamı iş akışlarını kapsar. Sonar, teknolojisinin 7 milyondan fazla geliştirici ve 22 000 müşteri tarafından kullanıldığını ve her gün 750 milyar satırdan fazla kod analiz ettiğini belirtiyor. Gitar’ın satın alınması, bu yaklaşımı AI‑yerel kod incelemesi ve düzeltmeye genişletti; SonarQube’un doğrulama motorunu, kodu inceleyebilen, CI hatalarını araştırabilen ve düzeltme önerip uygulayabilen ajan araçlarıyla birleştirerek yazılım geliştirmeyi giderek daha fazla AI‑odaklı hâle getirdi.

Kariyeriniz Uber’ın mobil ve geliştirici altyapısını inşa etmekten, kod tabanında açık kaynak büyük dil modelleri eğitmeye, ardından Gitar’ı kurup Satın alınmasının ardından Sonar’a katılmaya uzandı. Bu deneyimler, kod üretmenin sadece sorunun bir parçası olduğu ve onu güvenilir şekilde doğrulamanın daha zor bir problem olduğu inancınızı nasıl şekillendirdi?

Uber’da, bir şeyin dağıtılıp dağıtılmayacağını belirleyen sistem bileşenleri üzerinde çalıştım: monorepo, derleme, CI kuyruğu, test paketi. Değişiklik üretmeyi kolaylaştırmak, tüm baskıyı bu altyapıya yönlendirir. Kimsenin tahmin etmediği şekillerde daha fazla hizmet etkileşime girer ve daha çok mühendis, değişikliklerinin birleştirilmeye güvenli olup olmadığını öğrenmek için bekler.

Daha sonra kendi kod tabanımızda modelleri eğitmek üzerine çalıştım; asimetri burada belirginleşti. Bir model hızlıca makul bir uygulama üretebilir. Ancak bu uygulamanın canlı üretim sistemine uyduğunu, ekibin gerçekten kullandığı kurallara uygun olduğunu ve iki hizmet arasındaki bir şeyi kırmadığını göstermek çok daha uzun sürer ve bu işin çoğu insanlara düşer. Gitar bu deneyimin bir sonucuydu ve Sonar’ın analiz tarafında on yedi yıldan fazla süredir yaptığıyla uyumlu.

AI kod incelemesinin deterministik analizi tamamlaması gerektiğini, yerini alması gerektiğini savundunuz. Tekrarlanabilir, kural‑tabanlı analizle en iyi tespit edilen sorun türleri nelerdir ve AI’nin geleneksel tekniklerin yapamadığı yetenekleri nerelerde sunabilir?

Kural‑tabanlı analiz, özelliğin koddan kendisi üzerinden karar verilebilir olduğu durumlarda doğru araçtır. Kirli girdinin bir hedefe ulaşması, birinin kaçırdığı bir yolda null referans, sabit kodlanmış kimlik bilgisi, bilinen bir CVE’ye sahip bir bağımlılık, olması gerekmediği bir katmanı geçen bir import. Her çalıştırmada aynı yanıtı alırsınız ve tetiklenme nedenini gösterebilirsiniz; bu yüzden zorlamanın bu katmanda olması gerekir.

Kuralların kapsamadığı şey niyettir. Hiçbir ayrıştırıcı, kullanıcıya yönelik bir dizeyi çeviren herkes için belirsiz olacağını, bir değişikliğin bir biletin yarısını uygularken onu kapattığını iddia edeceğini veya yeni bir yeniden deneme döngüsünün hizmetin geri basınçla başa çıkma şekliyle çeliştiğini söylemez. Diff’i, ilgili sorunu ve tam kod tabanı bağlamını okuyan bir model bu durumları ortaya çıkarır ve bunlar bir kişinin kontrol ettiği bulgular olarak gelmelidir, kararlar olarak değil.

AI sistemleri iş mantığını, geliştirici niyetini ve mimari tavizleri değerlendirebilir, ancak sonuçları olasılıksaldır. Geliştirme ekipleri bu bağlamsal akıl yürütmeden nasıl faydalanabilir ve AI inceleme çıktısını doğası gereği doğru olarak kabul etmemeli?

AI incelemesi, geleneksel kontrollerin kaçırdığı sorunlarda yerini alır: mantık hataları, belirtilen niyetle uyuşmayan davranışlar, tek başına iyi görünüp bu belirli sistemde yanlış olan değişiklikler. Bu sonuçlar olasılıksaldır, bu yüzden kararın kendisi yerine kararın girdisi olarak değerlendirilmelidir. Ekipler, birleştirme öncesinde deterministik kontrolleri tutarak bu sınırı korur; bu otomatik testler, CI doğrulaması, güvenlik taramaları, politika kontrolleri ve değişikliği sahiplenen bir insan demektir. AI, ekibin belirlediği koruma çerçeveleri içinde düzeltmeler önerebilir veya uygulayabilir; bu değişiklikler bir insanın yazdığı gibi aynı doğrulamadan geçer ve makine tarafından üretildiği için ayrıcalık elde etmez.

Kendi uygulamamızda da aynı sınırı çizeriz. Model bulgular önerir ve inceleme kararı, bu bulguların durumundan kod içinde hesaplanır. Çözümleme de aynı şekilde çalışır. Bir bulgunun arkasındaki kod diff’ten kaldırıldığında, bu ayrıştırılmış diff’e karşı deterministik bir kontroldür ve model, diff’in zaten düzelttiği şeyi geri almasına izin verilmez.

Bunun genel versiyonu, olasılıksal katmana hatalı olmanın telafi edilebilir olduğu işleri vermek, durum makinesini deterministik tutmak ve sorumluluğu ekibe bırakmaktır. Güveni sağlayan, birinin inceleyip kontrol edebileceği ve her çalıştırmada aynı şekilde davranan kanıtlardır.

Sonar, bağlam‑duyarlı pull request incelemelerini deterministik analiz ve kalite kapılarıyla birleştiriyor. Etkili çok katmanlı bir doğrulama süreci nasıl görünmeli ve farklı katmanlar işi tekrarlamadan ya da geliştiricileri bulgularla boğmadan nasıl etkileşimde bulunmalı?

Deterministik analiz ve kalite kapıları, pazarlık konusu olmayan unsurları taşır ve birleştirmeyi engelleyen şeylerdir. Bağlamsal inceleme ise bir değişikliğin iddia ettiklerini yapıp yapmadığı, kod tabanına uyup uymadığı ve belirli bir riskin bir kişinin dikkatine değer olup olmadığı gibi yargı kararlarını alır.

Büyük bir bulgu duvarı, hiç bulgu olmamasına benzer bir oranda görmezden gelinir. Her şey yazarına ulaşmadan önce inceleyenler arasında tekrarları temizleriz, doğrulayamayan adayları eleriz ve yüksek sinyalli bulgulara odaklanırız. Kurallar tarafında, bir koşul, model çalıştırılmadan önce kuralın mevcut diff’e uygulanıp uygulanmayacağını belirler; böylece çoğu kural çoğu değişiklikte maliyet oluşturmaz. Tüm bunlar, geliştiricinin zaten açık olan pull request’te ortaya çıkar.

Kodlama ajanları daha fazla kod ve pull request ürettikçe, yazılım incelemesi ve doğrulaması yeni bir darboğaz haline gelebilir mi? İnceleme sürecinin hangi bölümleri otomatikleştirilmeli ve hangi kararlar deneyimli mühendislerde kalmalı?

İnceleme ve doğrulama zaten darboğaz haline gelmiştir. Aslında, bizim 2026 State of Code Developer Survey anketi, ekiplerin haftalık çalışma zamanının yaklaşık dörtte birini AI çıktısını kontrol edip düzeltmeye harcadığını ortaya koymuştur. Bu bağlamda, geliştiricilerin yalnızca %48’inin AI tarafından üretilen kodu her zaman gönderimden önce kontrol ettiği, çoğunluğun (%96) ise fonksiyonel olarak doğru olduğuna tam güven duymadığı şaşırtıcı değildir.

Otomatize edilmeye değer işler mekanik ve sıkıcıdır: bir CI hatasını kök nedenine indirgeyerek dört bin satır logun kimse tarafından okunmamasını sağlamak, bir bulgunun yeniden temellendirme sonrası hâlâ geçerli olup olmadığını belirlemek, bir hatayı yeniden üretmek, açıkça görülen düzeltmeyi yazmak. Mühendisler niyeti, tasarımı ve belirli bir değişiklik için ne kadar kanıtın yeterli olduğuna karar vermeyi sürdürmelidir. Kıdemli bir mühendis bir akşam logları okuyup dokuz hatadan hangisinin önemli olduğunu anlamaya çalışıyorsa, bu karar vermekten ziyade triyajdır ve tam da bu tür işleri onlardan almalıydık.

AI kod inceleme sistemleri sorunları tespit edebilir, düzeltmeler önerebilir ve bu değişiklikleri sürekli entegrasyon hattına karşı doğrulayabilir. Otonom bir iyileştirme sisteminin gerilemelere yol açmasını veya sadece başarılı bir derlemeye odaklanarak yazılımın daha geniş kalitesini göz ardı etmesini nasıl önlersiniz?

Ana nokta, yeşi kabul kriteri olarak görmeyi reddetmektir; çünkü geçen bir derleme, mevcut testlerin başarısız olmadığını sadece söyler.

Kendi iyileştirmemize koyduğumuz kısıtlamaların çoğu kapsamla ilgilidir. Gitar, kırılan CI’yi düzeltir ve kendi itmesinden önceki commit’in yeşil olduğunu kontrol eder, ardından sorumluluk alır. Kırmızı bir derlemeyi sürdürmek yerine iki takip commit sonrası durur. Hata değişiklikle ilgisiz bir durumdaysa, örneğin dalgalı bir test ya da altyapı sorunu, bu durum düzeltme yolundan ziyade yeniden deneme yoluna yönlendirilir; çünkü “testin başarısızlığını durdurmak”, yetenekli bir ajanın en az istemesi gereken hedeftir.

Bundan sonra değişiklik, Gitar’ın kontrol etmediği bir katmanı geçmelidir. SonarQube sonucu kendi koşullarıyla değerlendirir, kalite kapısı birleştirmeye bağlıdır ve bu politikayı ekip yönetir. Ayrıca değişikliği, uygulamayı iddia ettiği sorunla karşılaştırırız; gereksinim çıkarımı tamamlama kararından ayrı tutulur, böylece sessizce biletten çıkan bir gereksinim uygulanmış gibi geri gelmez.

Etkin AI kod incelemesi, bir depodaki kuralları, bağımlılıkları, mimariyi ve önerilen değişikliğin amacını anlamaya dayanır. Bir AI inceleyicisinin faydalı kararlar alabilmesi için ne tür bir bağlama ihtiyacı var ve organizasyonlar bu bağlamı sistemleri evrimleştikçe nasıl güncel tutabilir?

Sadece diff’i okuyacak kadar değil, deneyimli bir inceleyici gibi akıl yürütmek için yeterli bağlama ihtiyaç duyar. Bu bağlam, değişikliğin amacı, ilgili kod yolları ve tip bilgileri, bağımlılıklar, test davranışı, depo kuralları ve ekibin değişikliğin uyması gereken mimari sınırları içerir.

Bağlam ayrıca kodla birlikte yaşamalıdır. Kuralları ve inceleme rehberlerini depoda sürümleyin, hizmetler veya kurallar değiştiğinde güncelleyin ve mimari ve politika kararları için sorumluluğu netleştirin. Aksi takdirde, bir AI inceleyicisi, daha geniş sistemin gerçek işleyişiyle çelişen bireysel olarak mantıklı bir öneri üretebilir.

Deterministik analiz tutarlı ve denetlenebilir sonuçlar üretirken, büyük dil modeli tabanlı inceleme çalıştırmalar arasında değişebilir. Düzenlenmiş veya güvenlik açısından hassas ortamlarda işletmeler AI tarafından üretilen bulguları nasıl belgelemeli, yeniden üretmeli ve yönetişimini sağlamalı?

Denetim izleri, incelenen değişikliği, AI bulgusunu, alınan kararı ve sonucun doğrulanmasında kullanılan bağımsız kanıtları göstermelidir. Ekipler, AI’ı inceleme ve iyileştirmeyi hızlandırmak için kullanabilir, ancak zorlamayı ve onay kararlarını tanımlı politikalar ve insan sorumluluğu üzerine inşa edebilir.

Mühendislik liderleri, AI kod incelemesinin gerçekten yazılım geliştirmeyi iyileştirip iyileştirmediğini belirlemek için hangi metrikleri kullanmalı? İnceleme süresini, kaçan hataları, yanlış‑pozitif oranlarını, sürekli entegrasyon hatalarını, teknik borcu, geliştirici güvenini ya da başka bir ölçütü önceliklendirmeli?

Önce sonuçlara odaklanın, bir AI sisteminin ürettiği yorum sayısına değil. Pull request’ten birleştirmeye geçen süreyi, CI hatalarını teşhis etmede harcanan zamanı, düzeltmelerin ilk doğrulama denemesinde geçme oranını ve sorunların daha sonraki aşamalara ya da üretime kaçma sıklığını ölçerdim.

Ardından yanlış‑pozitif ve reddetme oranları, yeniden açılan sorunlar, yeni birleştirilen değişikliklerle ilişkili gerilemeler ve bulguların uygulanabilir olup olmadığına dair geliştirici geri bildirimleri gibi kalite sinyallerine bakın. Doğru metrik karışımı ekipten ekibe değişir, ancak soru tutarlı kalır: güvenli, güvenilir yazılım için standartları düşürmeden yeniden iş ve inceleme bekleme süresini azaltıyor muyuz?

İleriye baktığımızda, yazılım geliştirmesinin ajanların kod üretip, inceleyip, test edip, deterministik koruma çerçeveleri altında onarıp sürekli bir döngüye dönüşmesini bekliyor musunuz? Bu ortamda, insan yazılım mühendislerinin sorumlulukları ve gerekli becerileri nasıl değişecek?

Bu döngü zaten var ve ekipler genellikle sabit bir sırayla benimser: önce tespit, ardından iyileştirme, ardından yazdıkları koşullar altında onay, ardından birleştirme. Kimse doğrudan son adıma atlamaz ve onları ilerleten kanıt, bir benchmark değil kendi kod tabanlarıdır. Birleştirme, benim en ilginç bulduğum adımdır; çünkü çakışma sıklığı commit akışıyla artar ve akış, tüm bunların artırdığı şeydir.

Değer kazanan beceriler döngünün içinde değil, etrafında yer alır. Bir sorunu ve kısıtlamalarını net bir şekilde tanımlamak, bir ajanın açıklamanızı kelimesi kelimesine alması durumunda daha da önem kazanır. Aynı şekilde, bir değişikliğin geçmesi için hangi kanıtın yeterli olduğunu belirlemek de önemlidir; bu önce insanların kafasındaki bir alışkanlıkken şimdi otomatik bir sistemin uygulayabileceği bir politika olarak yazılmalıdır. Geri kalan kısmı sistem tasarımıdır: otomatik işin dokunabileceği alanları sınırlamak, ajanın kontrol etmediği bir şeyin sonucu kontrol etmesini sağlamak ve hatalı olduğunda sorumluluğu izlenebilir tutmak. Mühendisler, uygulamayı üretmek yerine neyin var olması gerektiğine ve bunun çalıştığını kanıtlayacak şeylere karar vermeye daha fazla zaman harcayacak.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Sonar‘ı ziyaret etmelidir.