Prince Kohli, Sauce Labs Başkanı ve CEO’su – Röportaj Serisi

Prince Kohli, Sauce Labs Başkanı ve CEO’su, yapay zeka, kurumsal yazılım, bulut bilişim, otomasyon, ağ ve siber güvenlik alanlarında kapsamlı deneyime sahip kıdemli bir teknoloji yöneticisidir. Sauce Labs’a Şubat 2025’te katılmadan önce, Automation Anywhere’de altı yıldan fazla süreyle Teknoloji Direktörü (CTO) olarak çalıştı ve büyük işletmeler için AI‑destekli otomasyon teknolojilerini ilerletmeye yardımcı oldu. Daha önce Kohli, ThoughtSpot’ta Kıdemli Başkan Yardımcısı (Senior Vice President) olarak Mühendislikten sorumlu oldu ve Ericsson’ta 10.000’den fazla mühendisi kapsayan küresel Ar‑Ge organizasyonlarını yöneten üst düzey liderlik görevlerinde bulundu. Ayrıca Citrix’te neredeyse bir on yıl platform, bulut ağları, mühendislik ve operasyon girişimlerini yönetti. Kariyerinin erken dönemlerinde uygulama güvenliği şirketi Teros’u ortak kurdu ve SGI’de teknik lider olarak çalıştı. Yönetim görevlerinin yanı sıra, Kohli Ethical AI Governance Group aracılığıyla teknoloji yönetişimi girişimlerine katkıda bulundu ve daha önce Dünya Ekonomik Forumu’nun Güvenli Sistemler ve Teknolojiler çalışma grubunda yer aldı.

Sauce Labs, işletmelere tarayıcılar, işletim sistemleri, sanal ortamlar ve gerçek cihazlar üzerinden web ve mobil uygulamaları test etmek için altyapı ve araçlar sunan bir yazılım kalitesi ve sürekli test şirketidir. Platformu, otomatik ve manuel test, görsel test, mobil uygulama dağıtımı, hata raporlama ve AI‑destekli test oluşturma ve analiz gibi yetenekleri destekler; aynı zamanda yaygın sürekli bütünleşme ve teslim (CI/CD) iş akışlarıyla entegrasyon sağlar. Sauce Labs, teknolojisini giderek AURA etrafında konumlandırmaktadır; bu, AI‑Birleşik Sürüm Güvencesi (AI‑Unified Release Assurance) platformu, AI ajanlarını kullanarak testleri oluşturur, yürütür ve analiz eder ve yazılım sürüm sürecinin tamamında insan denetimini korur. Şirket, altyapısının 8,7 milyardan fazla test yürütmesini ve 300.000’den fazla kurumsal kullanıcıyı desteklediğini, neredeyse iki on yıl süren çapraz‑platform test verilerine dayandığını belirtiyor.

Sauce Labs’a katılmadan önce, Automation Anywhere’de AI‑destekli otomasyonu yönettiniz ve Ericsson ve Citrix gibi şirketlerde büyük bulut ve mühendislik organizasyonlarını yönettiniz. Bu deneyimler, yazılım kalitesi sorununa bakış açınızı nasıl şekillendirdi ve AI‑yerel sürüm güvencesini Sauce Labs’ta merkezi bir öncelik haline getirmenizi ne ikna etti?

Ericsson ve Citrix’te, bir yazılım hatasının ne kadar hızlı yayılabileceğini ve dünya çapındaki altyapıyı etkileyerek güvenlik, müşteri operasyonları, güven ve gelir üzerinde büyük etkiler yaratabileceğini gördüm. Automation Anywhere bana AI’nın işin hızını ve yapısını nasıl değiştirdiğini gösterdi ve testin AI‑tarafından üretilen yazılıma ayak uydurmak için yeniden inşa edilmesi gerektiği açıkça ortaya çıktı. Sauce Labs test otomasyonunun öncüsü olduğundan, AI‑yerel sürüm güvencesi çözmemiz gereken bir sonraki büyük sorundur.

Sauce Labs’ın araştırması %80’inin AI‑tarafından üretilen kodun bir üretim olayı, kesinti veya müşteri etkili hataya yol açtığını ortaya koydu. Bu durum, daha çok AI’nın ürettiği kodun zayıflıklarından mı yoksa işletmelerin test ve yönetişim süreçlerini güncellemeden AI kodlama araçlarını benimsemelerinden mi kaynaklanıyor?

%80’lik oran, tüm yazılım teslim zinciri boyunca bir soruna işaret ediyor. AI sektörü, özel sermayeden bir trilyon dolardan fazlasını çekti; bu yatırımların çoğu, AI’nın işletmeleri çok daha üretken hale getireceği varsayımına dayanıyor. Ancak daha fazla kod üretmek, şirketlerin bu kodun kalitesine ve güvenliğine üretime girmeden emin olabilmeleri durumunda değer yaratır.

AI‑tarafından üretilen kod, ince hatalar ve güvenlik sorunları getirebilir ve işletmeler bu kodu zaten hızla değişen test ve yönetişim süreçlerinden geçirmek zorunda kalıyor. Bu da trilyon dolarlık bir yürütme problemi yaratıyor: AI yazılım oluşturmayı hızlandırabilir, ancak modernleştirilmiş bir sürüm güvencesi olmadan hataları da aynı hızla artırır. Her hata sonunda ortaya çıkar, bu yüzden şirketlerin hatayı müşteriden veya saldırganlardan önce bulması gerekir.

Rapor, geliştiricilerin %741 daha fazla kod ürettiğini, ancak sürüm hızı %20’den az arttığını belirtiyor. Doğrulama sistemlerinin bu hıza ayak uydurmasını engelleyen nedir ve yazılım geliştirme yaşam döngüsünde en büyük darboğaz genellikle nerede ortaya çıkar?

Kod üretimi, test oluşturma, bakım ve analizinden çok daha ileriye geçti. En büyük darboğazlar genellikle kod yazıldıktan sonra kullanıcı yolculuğu bağlamında doğrulanması gerektiğinde ortaya çıkar. Bu süreç, kodun kendisinden daha karmaşık olabilir; çünkü kod fonksiyonları ve nesnelerini kapsayan uç‑uç yolları hesaba katmak gerekir ve bir yerdeki küçük anlamsal değişiklikler büyük aşağı akış etkileri yaratabilir. Uygulamanın amacını doğru ve eksiksiz yakalayan testleri oluşturmak tarihsel olarak neredeyse imkânsızdı ve çok büyük bir manuel çalışma ve bakım gerektiriyordu. Ayrıca testler çalıştıktan ve bir şey başarısız olduğunda, ekiplerin sorunu anlaması, tanılaması ve hatanın üründen mi yoksa eski bir testten mi kaynaklandığını belirlemesi gerekir. Bu iş hâlâ büyük ölçüde manuel inceleme ve mühendislik bağlamına dayanıyor.

İncelenen işletmelerin %50’den fazlası, kritik hatalarla yazılımı bilerek yayınladıklarını, %66’sı ise bir son tarihe yetişmek için kalite ya da test standartlarından ödün verdiklerini kabul etti. İşletmeler bu risk seviyesini neden kabul ediyor ve yazılım kalitesinin bir iş önceliği haline gelmesi için ne gibi değişiklikler gerekir; sadece bir mühendislik kontrol noktası olmaktan çıkması için?

Organizasyonlar riski kabul ediyor çünkü sürüm hedefleri doğrudan müşteri, gelir ve ürün taahhütleriyle bağlantılı ve hataların maliyeti genellikle birkaç ekip arasında daha sonra ortaya çıkıyor. Kalite, liderler üretim olaylarını, müşteri etkisini, güvenlik açıklarını, yeniden işleme maliyetlerini ve gecikmiş geliri sürüm hızının yanında ölçtüğünde iş önceliği haline gelir.

Sauce Labs, AURA’yı, testleri oluşturup, çalıştırıp, analiz ederken her sürümden öğrenen kapalı‑döngü bir platform olarak konumlandırıyor. Bu, mühendislik ekiplerinin zaten kullandığı AI‑destekli test oluşturma, kendini iyileştiren test betikleri veya diğer otomasyon araçlarından teknik ve operasyonel olarak nasıl farklılaşıyor?

Çoğu AI test aracı belirli bir göreve odaklanır; örneğin bir test oluşturma ya da kırık bir locator’ı tamir etme. AURA, uygulama amacını anlayarak, testleri oluşturup yürütüp hataları analiz ederek ve üretim davranışını geliştirmeye geri besleyerek tüm süreci birbirine bağlar. Uygulamanın anlamı ya da beklenen davranışı değiştiğinde bir kişiyi sürece dahil eder. Ayrıca ürettiği testler istikrarlıdır; yani uygulama, tarayıcı, cihaz gibi değişiklikler anlamsal etki yaratmadığında testlerde değişiklik yapılması gerekmez. Son olarak, AURA içinde bir test yürütme bulutu barındırdığı için tüm süreci geliştiriciden ya da kalite mühendisliği ekibinden tamamen alıkoyabilir.

AURA, “iş amaçları”na karşı yazılımı doğrulamak için tasarlanmıştır. Bu amaç nasıl tanımlanıp test edilebilir gereksinimlere dönüştürülüyor, onaylamaktan kim sorumlu ve platform eksik, belirsiz ya da yoruma açık gereksinimlerle nasıl başa çıkıyor?

İş amaçları, ürün gereksinimleri, kabul kriterleri, iş kuralları, kullanıcı yolculukları ve müşterilerin uygulamayı gerçekte nasıl kullandığından gelir. Ürün liderleri beklenen sonucu tanımlar, mühendislik ve kalite ekipleri ise bu sonucu sistemin doğrulayabileceği davranışa dönüştürür. Gereksinimler eksik ya da belirsiz olduğunda, AURA belirsizliği ortaya çıkarır ve beklenen sonucu değiştirmeden önce insan onayı ister.

Sauce Labs, AURA kullanan işletmelerin %90 daha az üretim olayı, %47 daha hızlı sürüm döngüsü ve %38 daha fazla mühendislik kapasitesi geri kazandığını rapor ediyor. Bu sonuçlar nasıl ölçüldü, hangi dağıtım periyotları içinde değerlendirildi ve AURA’nın etkisini diğer organizasyonel ya da mühendislik değişikliklerinden ayırmak için hangi bağımsız doğrulama yapıldı?

Kurumsal dağıtımlarda, ekipler AURA’yı uyguladıktan sonra üretim olayları, sürüm döngüsü hızı ve mühendislik kapasitesindeki değişiklikleri ölçtük. Bu dağıtımlar %90’dan fazla üretim olayı azalması, %47 daha hızlı sürüm döngüsü ve %38 mühendislik kapasitesi geri kazanımı gösterdi; sonuçlar bağımsız olarak doğrulandı. Walmart ve Keller Williams gibi müşteriler de sürüm sıklığı, test kapsamı ve döngü süresinde önemli kazanımlar bildirdi.

Araştırma, olaylar artmaya devam ederken %64’ünün kalite güvence personel sayısını artırdığını ortaya koydu. İşletmeler sadece daha fazla test uzmanı işe alarak doğrulama boşluğunu neden çözemiyor ve testler daha otonom hâle geldikçe geliştiricilerin, kalite mühendislerinin ve site güvenilirliği ekiplerinin sorumlulukları nasıl değişecek?

AI, bir şirketin test personeli sayısını artırabildiğinden çok daha hızlı kod hacmini artırabilir; yeni insan eklemek de daha fazla el değiştirme ve koordinasyon gerektirir. Geliştiriciler amacı net bir şekilde tanımlamak zorunda kalacak, kalite mühendisleri risk, kapsam ve yönetişime daha çok odaklanacak, site güvenilirliği ekipleri ise üretim davranışını sürüm sürecine geri besleyecek. Ajanlar, bu yeni geliştirme modelinin gerektirdiği ölçekle tekrarlayan yürütme ve analizleri üstlenebilir.

AI ajanları testleri oluşturma, çalıştırma ve yorumlama sorumluluğunu artırdıkça, insanlar hangi kararları vermeye devam etmeli? Hangi belirsizlik, güvenlik riski ya da potansiyel müşteri etkisi otomatik olarak bir sürümü durdurmalı ya da insan incelemesi tetiklemeli?

İnsanlar, özellikle yargı, müşteri etkisi ya da iş riski söz konusu olduğunda sürüm kararları üzerinde nihai yetkiyi korumalıdır. AI ajanları sıkıcı, tekrarlayan ve net tanımlanmış test görevlerini otomatikleştirebilir, ancak kod ya da test sonuçları tam olarak anlaşılamadığında, açıklanamadığında ya da yeniden üretilemediğinde insanlar üretim sürümlerini onaylamalıdır. Gereksinimler belirsiz olduğunda, güvenlik açıkları mümkün olduğunda, üçüncü‑taraf bileşenler yeterince doğrulanmadığında ya da hatalar gelir, hassas veri, müşteri deneyimi ya da kritik operasyonlar üzerinde etkili olduğunda inceleme zorunlu olmalıdır.

Bu durumlarda, açıklanamayan davranış, tutarsız test sonuçları ya da sürüm hazırlığına dair yetersiz kanıt otomatik olarak sürümü durdurmalıdır.

Müşterilerimizde, “flaky” (düzensiz) görünen, belirgin bir hata paterni olmadan tutarsız geçen testlerin çoğu zaman göz ardı edildiği durumlar gördük. Ancak bu müşterilerin bazıları, süreçlerini iyi yönettiklerinden ve platformumuzun yardımıyla, başarısızlığı çok ince ama kritik bir zamanlama hatasına bağlayabildiler; bu hata yayınlandığında büyük etkiler yaratabilirdi ve çok yüksek bir maliyetle sonuçlanabilirdi.

Ayrıca Ethical AI Governance Group ve Dünya Ekonomik Forumu’nun Safe Systems and Technologies çalışma grubuyla da çalıştınız. AI‑tarafından üretilen kod ve otonom testler daha derin bir şekilde bağlandıkça, işletmelerin daha hızlı yazılım yaratımının yeni sistemik, güvenlik ya da sorumluluk riskleri getirmemesini sağlamak için hangi yönetişim standartlarına ihtiyaç duyacak?

AI ne kadar hızlı yazılım yaratabiliyorsa, doğrulama ve yönetişim katmanının da o kadar güçlü olması gerekir. Bu katman birçok bileşenden oluşur. İşletmeler, ajanların neyi otonom karar verebileceği konusunda net sınırlar koymalı; iş amacı, güvenlik, uyumluluk ya da anlamlı anlamsal değişiklikler konusunda belirsizlik olduğunda insan incelemesi zorunlu olmalıdır. Ayrıca, bir ajanın neyi, neden değiştirdiğine ve sürüm kararını hangi kanıtların desteklediğine dair izlenebilirlik sağlanmalıdır. Sonuçta, yönetişim, üretime ulaşan şeyin kalitesi ve öngörülebilirliğiyle ölçülmelidir; örneğin üretilen kodun 90 gün içinde kaç kez olay yarattığını izlemek gibi, AI’nın kod üretim hızına göre değil.

Harika röportaj için teşekkür ederiz, daha fazla bilgi edinmek isteyen okuyucular Sauce Labs sitesini ziyaret etmelidir.