Yapay Zekâ Çağında Mühendislik Mükemmelliği Nasıl Görünüyor?

Transkripti okuyun:

Podcast’lerimizin transkripsiyonunu bir yazılım programı kullanarak deniyoruz. Bot her zaman yüzde 100 doğru çalışmadığı için lütfen olası yazım hatalarını mazur görün.

Hannah Clark: Yapay zekâ çağının teknoloji alanındaki her işin sonunu getirdiği artık bir şakaya dönüştü. Aslında bu yıl o kadar çok iş sona erdi ki daha fazla cenazeye davet edilmemiş olmama şaşırıyorum. Ürün yönetimi öldü, kullanıcı araştırması öldü ve hepsinden daha vahimi, yazılım mühendisliği öldü. Burada aynı fikirde olanlara sesleniyor olabilirim ama mahallemizdeki dost canlısı büyük dil modeliniz kod yazabiliyor diye yazılım mühendisliğinin gerçekten öldüğüne inanan biri kesinlikle mühendis değildir.

Bugünkü konuğum, Cortex.io’nun kurucusu Anish Dhar, mühendisliğin kesinlikle ölmediğini savunuyor. Mühendislik yalnızca olgunlaşıyor. Daha önce Uber’de mühendis olarak çalışan Anish, mühendislerin karmaşık kod tabanlarını anlamasını kolaylaştırmak için Cortex’i kurdu. Kendisi de bir mühendis ve kullanıcıları mühendislerden oluşuyor. Bu nedenle bu alanda gördüğü şey, aslında mühendislik mükemmelliğinin evrimi ve bunu ölçmenin eski ve yeni yöntemleri arasındaki kopukluk. Mühendislikte mükemmelliği ölçme ve değerlendirmeye yönelik yeni nesil düşünceleri ve “vibe coding” çılgınlığının bu tartışmadaki yerini ele aldık. Hemen başlayalım.

Bu arada, her hafta bunun gibi sohbetler gerçekleştiriyoruz. İlginizi çektiyse neden abone olmayasınız? Şimdi başlayalım.

The CPO Club podcastine tekrar hoş geldiniz. Bugün Cortex.io’nun kurucusu Anish Dhar ile birlikteyim.

Anish, bugün benimle konuşmaya zaman ayırdığınız için teşekkür ederim.

Anish Dhar: Beni davet ettiğiniz için çok teşekkür ederim.

Hannah Clark: Bize biraz geçmişinizden ve bugünkü rolünüze nasıl ulaştığınızdan bahsedebilir misiniz?

Anish Dhar: Elbette. Cortex.io’nun kurucu ortağı ve CEO’suyum. Şirketi yaklaşık altı yıl önce kurduk. Bundan önce Uber’de mühendis olarak çalışıyordum. Kariyerime büyük ölçüde orada başladım ve Uber’de mühendis olarak karşılaştığım sorunların çoğu Cortex’i kurmamızın nedenlerine ilham verdi.

Uber’in devasa bir dahili hizmet mimarisi var. Orada mühendis olarak çalışırken, özellikle şirkete ilk katıldığımda kod tabanının farklı bölümlerini anlamak benim için gerçekten zordu. Oluşturulan çok sayıda farklı hizmet vardı. Bu durum ciddi bir karmaşıklık yaratıyordu. Çok yakın bir arkadaşımla konuşuyordum; kendisi Lend adlı çok küçük bir girişimde mühendisti.

Onların yalnızca yüz mühendisi vardı, Uber’de ise binden fazla mühendis çalışıyordu. Buna rağmen hizmet mimarimizi düzenleme ve anlama konusunda benzer zorluklarla karşılaşıyorduk. Bu durum alarm zillerinin çalmasına neden oldu. Uber gibi büyük ölçekli bir şirket ile mikro hizmet yolculuğuna yeni başlayan başka bir şirket aynı sorunları yaşıyorsa, bunun sektörde büyük bir problem olduğu açıktı.

Böylece şirketi kurmaya karar verdik. Winter 20 Y Combinator grubundan geçtik. Bugüne hızlıca ilerlersek, kısa süre önce C serisi yatırımımızı gerçekleştirdik ve birkaç yüz farklı işletmenin Cortex’i hizmetlerini yönetmek için kullanmasına yardımcı oluyorum.

Hannah Clark: Harika bir yolculuk. Bir şirketin, çok yakından bildiğiniz bir sorunun küllerinden doğduğunu duymak her zaman çok güzel.

Bu konudan hareketle, bu bölümde mühendislik mükemmelliğinden ve bunun günümüz teknoloji dünyasında nasıl göründüğünden bahsedeceğiz. Bu nedenle kariyeriniz boyunca yakından ilgilendiğiniz bir konu. Başlangıç olarak, 2025’te mühendislik mükemmelliğini nasıl tanımlıyorsunuz ve bu konu neden CTO’lar ile mühendislik başkanları için giderek daha kritik bir odak noktası hâline geliyor?

Anish Dhar: Cortex’te gördüğümüz kadarıyla, uzun süre konuşmalar ağırlıklı olarak geliştirici deneyimine odaklandı. Geliştirici deneyimi her mühendislik organizasyonunun çok kritik bir parçasıdır. Örneğin geliştiricilerin bir şirkete katıldıklarında dahili sistemlerini kolayca kurabilmelerini, GitHub’a ve kullandıkları çeşitli araçlara bağlanabilmelerini sağlamak. Ya da bir hizmet dağıtırken altyapının doğru şekilde kurulması ve sorun giderme ya da gerekli adımların çok fazla zaman almaması.

Ancak özellikle son birkaç yılda konuşmanın yalnızca geliştirici deneyiminden, bizim mühendislik mükemmelliği adını verdiğimiz kavrama doğru kaydığını gördük. İkisi arasındaki temel fark şu: Mühendislik mükemmelliği, organizasyonunuzdaki farklı ekiplerin çalışmalarına odaklanır.

SRE, güvenlik, geliştirici verimliliği ve hatta geliştirici deneyimi ekiplerini düşünebilirsiniz. Ancak mühendislik mükemmelliği bu ekipleri gerçek iş sonuçlarıyla aynı hizaya getirir. Buradaki temel fark budur. Mühendislik mükemmelliği, yaptığım işin işletmeyi nasıl etkilediğini ve işletmeyi nasıl ileriye taşıdığını düşünmektir.

CEO’nun organizasyonundan, üzerinde çalışan belirli bir SRE’ye kadar sahip olduğumuz hedefleri ele alalım. İyi bir örnek şu olabilir: Bir organizasyon olarak müşteri deneyimimizi iyileştirmeye odaklanıyoruz. Müşteriler ürünümüzü kullandığında ürünün güvenilir olmasını istiyoruz; daha iyi bir müşteri deneyimi de insanların ürünümüzü daha fazla kullanması sayesinde daha fazla gelir getiriyor.

Bu durumda bir mühendislik mükemmelliği girişimi kapsamında SRE ekibiniz, uygulamaya koymaya çalıştığı bir üretime hazırlık kontrol listesine sahip olabilir. Hizmetler dağıtılmadan önce tüm hizmetlerin organizasyon standartlarını karşıladığından emin olmak isterler. Böylece SRE ekibiyle başlayan bir girişimin, organizasyonun önemsediği gerçek bir iş sonucuna nasıl bağlandığını görebilirsiniz.

Ekiplerin girişimlerini bu şekilde düşünmesi gerçekten kritik. Çünkü bu, teknik girişimlerin değerini ortaya koyar ve onları işletmenin önemsediği şeylerle aynı hizaya getirir. Bence mühendislik mükemmelliği temelde budur.

Hannah Clark: İlginç. Bunun, birçok disiplinin birlikte çalışmasını gerektiren, hiç bitmeyen bir yolculuk olduğunu defalarca anlatmış olmalısınız.

Geliştirdiğiniz bu çerçeveden bahseder misiniz? Temel sütunlar neler? Buna kendi organizasyonunuz açısından nasıl bakıyorsunuz?

Anish Dhar: Kesinlikle haklısınız. Gerçekten hiç bitmeyen bir yolculuk. Birlikte çalıştığımız şirketlerin çoğunda, özellikle büyük işletmelerde, yeni teknolojiler üzerine kurulmuş ve hatta yapay zekâ öncelikli yeni bir şirketle karşılaştırıldığında çok sayıda eski altyapı bulunuyor.

Buna rağmen mühendislik mükemmelliği etrafında farklı girişimler var. Tüm bu ekipler arasında, yapılan işin ne olduğu ve bunun nihai olarak sahip olduğumuz işletme mükemmelliği hedeflerini nasıl etkilediği konusunda gerçekten düşünceli bir yaklaşım gerekiyor. Çerçeve açısından üzerinde çok çalıştığımız konulardan biri, organizasyonunuz için mühendislik mükemmelliğini nasıl tanımlayacağınızdır.

Bunu düşünme biçimimiz işletme mükemmelliğiyle başlıyor. Bir liderlik ekibi olarak farklı hedefleriniz olabilir. Bunlar yeniliğin önünü açmak ve pazara çıkış süresini kısaltmak, maliyetleri düşürmek ve verimliliği artırmak ya da kaliteyi ve müşteri deneyimini iyileştirmek olabilir.

Bunun altında mühendislik mükemmelliğinin sütunları bulunur. Bunlar nihai hedefleri destekleyen girişimleri oluşturan farklı ekipler ve uygulayıcılardır. Hız, verimlilik, güvenlik ve güvenilirlik bunlara örnektir. Bu alt kategorilerin içinde de güvenlik geçişi, üretime hazırlık kontrol listesi ya da uygulamaya koymaya çalıştığınız bir olay yönetimi süreci gibi girişimler yer alabilir.

Ya da verimlilik açısından mühendislik ekibimizin nasıl performans gösterdiğini anlamak için mühendislik metriklerini takip etmek kadar basit bir şey olabilir. Her mühendislik mükemmelliği girişiminin temeli, bizim dört C adını verdiğimiz unsurlardan oluşur: eksiksiz görünürlük, sürekli iyileştirme, tutarlı geliştirici deneyimi ve elbette net sahiplik. Sahiplik olmadan, kod tabanınızın ve hizmetlerinizin farklı bölümlerini anlamadan bu girişimleri ileriye taşımak çok zordur.

Bu temel olmadan herhangi bir girişimi ilerletmenin zor olduğunu görüyoruz. Dahili geliştirici platformları veya dahili portallar bu temeli oluşturmanın güçlü bir yolu. Bu işlem dahili araçlarla da yapılabilir; ancak insanların ne oluşturduğunu anlayabilmeniz ve mühendislik girişimlerini ilerletebilmeniz için bir tür sisteme ihtiyacınız var.

Hannah Clark: Performansı ölçmek konusuna biraz daha girmek istiyorum. Geliştirici verimliliğini ve kod satırı sayısı gibi metrikleri ölçme konusunda mühendisler arasında tartışmalar olduğunu biliyorum. Mühendislik liderleri, tüm bu C’leri ve benzer unsurları hesaba katan daha bütünsel bir yaklaşımla verimliliği nasıl düşünmeli?

Anish Dhar: Son birkaç yılda geliştirici verimliliği büyük ölçüde kod satırı sayısı veya DORA metrikleri üzerinden ele alındı. Verimliliği düşünmeyi basitleştirmeye çalışan çeşitli çerçeveler var ve bu metriklerin hesaplanma biçiminde bazı doğrular bulunuyor.

Kod satırı sayısı, birinin verimli olup olmadığının iyi bir göstergesi değildir. Ancak çeyrekten çeyreğe sürekli olarak sıfır satır kod teslim ediyorsanız, çıktıda açıkça bir sorun vardır. Ekipleri karşılaştırırken bu veri noktalarını görmek bazen ilginç olabilir. Fakat asıl konuşma artık “Bu veriye sahibim” noktasından “Mühendislerin bu veriyi düşünmesini veya bu veriyi iyileştirmesini nasıl sağlayabilirim?” noktasına kaydı.

Bunu gerçekten parçalara ayırdığınızda tamamen farklı ve çok daha zor bir problemle karşılaşırsınız. Herkes GitHub API’nize erişip bu metrikleri alabilir ve ekibinizin nasıl çalıştığına dair bir anlık görüntü elde edebilir. Ancak bir mühendise bir dizi metrik gösterip “Bu metriği iyileştirmeliyiz” demeniz, mühendis için tek başına bir anlam ifade etmez.

Ben işletme için yazılım geliştirmeye ve bunu genellikle mümkün olan en verimli şekilde yapmaya odaklanırım. Bu nedenle özellikle birlikte çalıştığımız CTO’larla konuşmanın “Bu metriklere sahibim, şimdi bunları bir mühendisin önemsediği bir şeye nasıl dönüştürürüm?” noktasına kaydığını görüyoruz.

Mühendislik mükemmelliğinin bu kadar kritik bir rol oynamasının nedeni de bu. Özellikle hızlı büyüyen şirketlerde çalışan mühendisler işletmenin büyümesini ister. Ürün geliştirirler çünkü çalışmalarının müşteriler üzerindeki etkisini görmek isterler.

Geliştirme verimliliği, yalnızca bir grup metrikten, işletme olarak önemsediğimiz şeylere dönüştü. Bu metrikler de bu hikâyenin bir parçasını anlatıyor. Ancak mühendis açısından önemli olan, yaptığı işin bu hikâyeye nasıl bağlandığıdır. Gördüğümüz büyük değişim bu.

Hannah Clark: İnsanların uzaklaşmaya başladığı eski değerlendirme yöntemleri veya KPI’lar fark ettiniz mi? Yeni değerlendirme yaklaşımını nasıl tanımlarsınız?

Anish Dhar: Verimliliği girdi ve çıktı metrikleri olarak düşünürüm. Çıktı metrikleri, mühendislik verimliliğini takip etmek için bugün kullanılan klasik çerçevelerdir. En bilinen ve popüler olanlardan biri, mühendislik ekibinin nasıl performans gösterdiğine dair bütünsel bir görünüm sunması amaçlanan DORA metrikleridir.

Bugün çoğu mühendislik organizasyonu bu çıktı metriklerini görmek ve yakalamak istiyor. Ancak daha önce söylediğim gibi, asıl soru bu metrikleri nasıl etkileyebileceğiniz ve hareket etmelerini nasıl sağlayabileceğiniz. Müşteri tabanımızda gördüğümüz ve Cortex’in son birkaç yılda büyümesinin nedenlerinden biri, çıktı metriklerini etkileyen girdi metrikleri kavramının önem kazanması.

Örneğin dağıtım sıklığını ele alalım. Mühendislerin yazılım dağıtma hızı, ürünü ne kadar hızlı geliştirdiğinizin iyi bir göstergesidir. Bu da nihayetinde ürünü pazara rakiplerden önce sunmanızı ve işletme olarak daha hızlı ilerlemenizi sağlar.

Bir organizasyon olarak takip etmek istediğiniz temel metriğin dağıtım sıklığına karar verdiğinizi düşünelim. Bir dağıtım sıklığı panosuna sahipsiniz ve bunu tüm mühendislik ekibine gösterebiliyorsunuz: “Herkes, haftada iki dağıtım yapıyoruz. Bunu dörde çıkarmak istiyoruz.”

Bir mühendis olarak bunun kendi işimle, işletmedeki bölümümle veya sahip olduğum hizmetlerle ilişkisini nasıl düşünmeliyim? Daha hızlı dağıtım yapmak daha fazla şey teslim etmek anlamına gelebilir; ancak bu daha fazla hataya yol açar mı? Daha fazla teslimat yaptığım için güvenilirlik düşer mi?

Bu sürece giren çok sayıda değişken var. Girdi metrikleri bu yüzden kritik. Çünkü girdi metrikleri nihayetinde çıktı metriklerini etkiler. Dağıtım sıklığı için daha hızlı ilerlemenizi sağlayacak bir süreç oluşturabilirsiniz.

Müşterilerimizden biri dağıtım sıklığını motor zekâsı panolarımızdan biriyle takip ediyordu. Mühendislerin daha hızlı dağıtım yapmasını istiyorlardı; ancak bunu, dağıtım sürecine önemli güvenlik sınırları koyarak ve güvenilirlik kurallarına göre iyi bir dağıtımın nasıl göründüğüne dair net yönergeler vererek yapmaya karar verdiler.

Çünkü mühendisler daha hızlı dağıtım yapmaya çalışırken hatalar ortaya çıkıyor veya sistemler bozuluyordu. Bu nedenle mümkün olduğunca hızlı ilerleme konusunda bir tereddüt oluşuyordu. Girdi metriklerine dönerek bir üretime hazırlık kontrol listesi oluşturdular. Bu liste, dağıtım süreçlerinin sağlıklı olup olmadığını anlamaya yardımcı olan sekiz veya dokuz farklı girdi metriğinden oluşuyordu.

Örneğin nöbetçi çağrı yapılandırmamız doğru mu, derleme sürecimiz başarılı mı, hizmetlerimizde geçen testler var mı gibi sorulara bakıyorlardı. Bu girdi metriklerini uygulamak mühendislere net bir yol gösterdi: “On hizmetin sahibi benim. Süreç bu ve bunlar benim için anlamlı olan girdi metrikleri; çünkü hizmetleri ve çalışma biçimlerini temsil ediyorlar.”

Sonuç olarak dağıtım sıklığının haftada ikiden üçe, ardından dörde çıktığını ve özellikle kritik hizmetlerde olayların azaldığını gördüler. Bu nedenle işletmeler artık çıktı metriklerine sahip olmanın yeterli olmadığını, bunları mühendislerin önemsediği bir şeye nasıl çevireceklerini düşünmeleri gerektiğini anlıyor. Geliştirici verimliliğini ve metrikleri iki taraf arasında eksiksiz bir hikâye olarak ele almalısınız.

Hannah Clark: Bu yaklaşım konuyu çok daha bütünsel hâle getiriyor. Biraz yön değiştirerek yine daha fazla ve daha hızlı dağıtım konusuna geçelim. 2025’te mühendislik hakkında “vibe coding”den bahsetmeden konuşamayız.

Kodlama iş akışlarını dönüştüren yapay zekâ araçlarından söz edelim. Daha önce “Günde bir milyon kullanıcıya ulaşmanın yolunu vibe coding ile yazamazsınız” dediğinizi duydum. Bu belki tartışmalı bir görüş, belki de değil. Üretim ölçeğindeki ortamlarda yapay zekâ kullanımı söz konusu olduğunda gerçek ile abartı arasındaki fark nedir?

Anish Dhar: Bu gerçekten çok sıcak bir konu. Her mühendislik organizasyonu yapay zekâyı düşünüyor veya örneğin bir yapay zekâ kodlama asistanını benimsemiş durumda. Piyasada Cursor gibi çok popüler araçlar var. Cortex’teki mühendislik ekibinin neredeyse tamamı günlük işlerinde onlara yardımcı olması için bir tür yapay zekâ kodlama asistanı kullanıyor.

Ekibimizdeki mühendislerle ve birlikte çalıştığımız müşterilerle konuştuğumuzda, bu araçların başlangıçta bir fikriniz olduğunda ve bir şeyi hızlıca doğrulamak istediğinizde çok yararlı olduğunu görüyoruz. Ön yüz mühendisiyseniz bir fikrin nasıl görüneceğini ve hissedileceğini hızlıca göstermek için prototip oluşturmak da buna dahil.

Mühendislik geliştirme sürecinde bu tür araçlar bunun için mükemmel. Hızlı ve geçici bir şey istiyorsanız, insanlara bir şeyin nasıl çalışabileceğini göstermek istiyorsanız ya da bir girişimci olarak bir fikri hızla doğrulamak istiyorsanız son derece faydalılar.

Ancak bugün kodlama asistanları ve vibe coding konusunda gerçek şu: Vibe coding ile üretilen kodun milyonlarca kullanıcı tarafından kullanılan bir üretim sistemine güvenilir biçimde güç vereceğine asla güvenemezsiniz. Bizim gördüğümüz deneyim bu yönde.

Bence vibe coding en iyi ihtimalle kod yazmayı yeni öğrenmiş bir mühendise benziyor. Buna karşılık kıdemli ve personel mühendisler sistem tasarımını ve altyapının büyük ölçekte nasıl dağıtıldığını anlıyor. Yapay zekâ henüz bu seviyeye yakın değil. Bunun hiçbir zaman ulaşamayacağı anlamına gelmiyor; yapay zekânın gelişme hızı inanılmaz.

Ancak bugün milyonlarca veya milyarlarca kullanıcıya hizmet veren herhangi bir üretim sistemini çalıştırmak için vibe coding’e güvenen bir işletme yok. Bu sistemleri kurmak, teşhis etmek ve ölçeklenmelerini sağlamak için gereken teknik uzmanlık düzeyi çok daha yüksek.

Bununla birlikte kodlama asistanlarıyla verimliliğin arttığını söyleyebilirim. Sadece bu artış, piyasanın konuşmayı sevdiği veya cazip bulduğu alanlarda değil. Gerçek şu ki bu araçlar henüz kurumsal üretim sistemleri için hazır değil.

Hannah Clark: Bu, yapay zekâ araçlarıyla kendi mesleklerinin erişilebilir hâle gelmesi konusunda meslek dışından insanların heyecanlandığını gören birçok profesyonel için oldukça tanıdık bir durum. Ancak bu, yapay zekânın hemen sizin yerinizi alacağı anlamına gelmiyor.

Programı dinleyen liderler var. Yapay zekâ araçlarına yatırım ile çalışan sayısı arasında denge kurmaya çalışan mühendislik liderleri açısından neleri değerlendirmek gerekir? Yapay zekânın ekibin verimliliği üzerindeki gerçek etkisini nasıl ölçersiniz ve bunu bütçenize nasıl yansıtırsınız?

Anish Dhar: Bunun birçok boyutu var. Makro açıdan baktığımızda mühendislik liderlerinin ekiplerinin Cursor veya GitHub Copilot gibi araçları kullanmasını engellemesi, uzun vadede mühendislik ekibinin sağlığına ve kalitesine büyük zarar verir.

Önümüzdeki on yılda insanların yazacağı sistemlerin veya en azından ilk kodların önemli bir bölümü yapay zekâ destekli olacak. Bir şirket kuruyor, bir fikir üzerinde çalışıyor veya bir şeyi hızlıca denemek istiyorsanız Cursor gibi bir araçla on kat daha hızlı hareket edebilirsiniz. Fikirlerinizi hızla yineleyebilir ve ölçek hakkında henüz düşünmeniz gerekmeyebilir.

Bu nedenle uzun vadeli baktığınızda, yapay zekâ araçlarını benimseyen ve bunları kodlama yaşam döngülerinin farklı bölümlerinde kullanmayı öğrenen mühendislik ekipleri avantajlı olacak. En büyük işletmelerde bile üretim ölçeğinde sistemlere ihtiyaç duyulduğunda, bu araçları kullanan mühendisler kullanmayanlara göre daha avantajlı konumda bulunacak.

Mühendislik liderlerinin ekiplerinin bu tür araçları keşfetmesine izin vermesi ve teknik olmayan kullanıcılarına da erişim sağlaması çok önemli. Ürün yöneticileri, teknik program yöneticileri ve veri bilimciler teknik kavramları anlayabilir ancak kodlama uzmanlığına sahip olmayabilir. Bu araçlar sayesinde fikirleri alıp mühendislik ekibiyle çok daha güçlü biçimde paylaşabilirler.

Bu açıdan bakıldığında mühendislerin bu araçlara erişmesini sağlayacak bir bütçe ayırmamak büyük bir hata olur.

Asıl soru, bu araçlarla ne kadar verimlilik kazandığımızdır. Her işletme şu anda bu sorunun yanıtını bulmaya çalışıyor. Müşterilerimiz çoğu zaman ürünümüzü bir kodlama asistanıyla birlikte satın alıyor. Sonra bize şu soruyu soruyorlar: “Bu araç mühendislik ekibimizin çıktısını üç veya dört katına çıkarmalı. Bunun gerçekten gerçekleşip gerçekleşmediğini nasıl anlayabiliriz?”

Bu soru, daha önce bahsettiğim girdi ve çıktı metrikleri sistemine geri dönüyor. Dağıtım sıklığını açıp “Kodlama asistanı bunun üzerinde etkili oldu mu?” demek yeterli değil. Belki araç daha hızlı teslimat yapmanızı sağlıyor ama ortaya çıkan kod çok kötü. Bu da güvenilirlik sorunlarına yol açabilir.

Bu nedenle konuya neredeyse 360 derecelik bir bakışla yaklaşmalı ve farklı metrikleri birlikte değerlendirmelisiniz. Günün sonunda bu, mühendislik mükemmelliğine geri dönüyor. İşletme olarak şu anda neye odaklanıyoruz? Bir sonraki büyüme seviyesine ulaşmamızı engelleyen şeyler neler?

Kodlama asistanının veya yapay zekâ aracının gerçekten fark yaratıp yaratmadığını bu açıdan değerlendirmelisiniz. Bunu anlamak biraz zaman alabilir. İşletmenizde bu tür araçların nerede etkili olacağını anlamanız gerekir.

Birçok işletmenin yaptığı hata, abartıya hemen kapılmak. İlginç görünen bir araçtan binlerce lisans satın alıyorlar ve altı ay sonra “Gerçekten bir etkisi oldu mu?” diye soruyorlar. Neden böyle araçları uygulamaya koyduğunuza dair düşünceli bir stratejiniz yoksa sonuç hayal kırıklığı olabilir.

Stratejiniz, geride kalmak istemediğimiz ve mühendislerin buranın ileri teknolojiyle çalışan bir yer olduğunu hissetmeye devam etmesini istediğimiz için yapay zekâ destekli araçları kullanmak olabilir. En azından aracı neden satın aldığınızı bilirsiniz. Daha sonra bunun beklediğiniz şeyi yapıp yapmadığını düzenli olarak kontrol edebilirsiniz.

Hannah Clark: Katılıyorum. Şu anda bu araçlarda uzmanlaşma ve iş akışına nerede uyduklarını bulma konusunda çok fazla baskı var. Ancak birçok departmanda karşılaştığımız şey, çıktı miktarı ile sonuçların kalitesi arasındaki farkın çok büyük olması.

Bu nedenle araçları yalnızca çalışan sayısının gelecek yıl daha düşük olacağını varsayarak körü körüne uygulamak yerine, çalışanlarımızın en iyi performansını ortaya çıkarmak ve onları güçlendirmek için doğru bağlamda kullanıp kullanmadığımız konusunda çok bilinçli olmamız gerekiyor.

Herkesin aynı anda bunu farklı şekillerde çözmeye çalışması oldukça ilginç. Teknoloji alanında olmak gerçekten yönlendirici bir deneyim değil. Yapay zekâ araçlarının geliştirme iş akışlarında daha yaygın hâle gelmesi ve kalite konusunu düşünmemizle birlikte, kod kalitesini, güvenlik standartlarını ve güvenilirliği korurken bu araçlardan nasıl en iyi şekilde yararlanabiliriz?

Örneğin kendi organizasyonunuzda bu yaklaşımı nasıl benimsediniz?

Anish Dhar: Yapay zekânın mühendislerin yerini aldığı fikrinin çok uzak ve saçma olduğunu söyleyebilirim. Doğru olan şu: Bir şirketin ilk aşamalarında 15 mühendis işe almak yerine birkaç mühendis daha az işe alabilirsiniz. Çünkü ürün-pazar uyumunu bulmaya çalışırken bir Cursor gibi araçla daha önce mümkün olandan çok daha fazlasını yapabilirsiniz.

On farklı fikri çok hızlı deneyebilirsiniz. Yineleme hızı gerçekten güçlü bir avantaj. Ancak üretim sistemleri dağıtmaya başladığınızda, yapay zekâ sayesinde daha az mühendis işe almanız gerektiğini söyleyen işletmeler yalnızca medyanın ilgisini çekmeye çalışıyor. Bunun doğru olmadığını biliyorum.

Hannah Clark: İsim vermeden.

Anish Dhar: Evet, hepsi mühendisleri işe almaya devam edecek. Mühendisler hiçbir zaman talep görmemekten çıkmayacak.

Yapay zekâ araçlarının güvenilirlik ve güvenlik gibi temel sütunları nasıl etkileyeceği konusunda ise bunun şu anda büyük bir soru olduğunu düşünüyorum. Bu konu SRE, güvenlik ve operasyonel mükemmellik ekiplerini endişelendiriyor. Çünkü bu araçların kullanılması insanların daha fazla kod teslim etmesi anlamına geliyor ve bu da saldırı yüzeyini genişletiyor.

Sisteminizin ne kadar büyük bir bölümü yapay zekâ ile oluşturulursa, her şeyin dahili olarak nasıl çalıştığını gerçekten anlamama ihtimaliniz o kadar artar. Kaçınılmaz bir güvenilirlik sorunu yaşandığında bu ciddi bir problem yaratır. Kullanıcı akışı beklenmedik şekilde artabilir veya kod tabanınızın tam anlamadığınız bir bölümü çökebilir.

Sisteminizin daha fazla bölümü yapay zekâ destekli hâle geldikçe, mühendis olarak kod tabanının her bölümünü nasıl inceleyeceğinizi anlamak zorlaşır. Bence şu anda gördüğüm en büyük dezavantaj bu.

Bu nedenle mühendislik mükemmelliğinin temel katmanı hiç olmadığı kadar kritik. Eksiksiz görünürlük ve net sahiplik, her mühendislik mükemmelliği girişiminin temel sütunlarıdır. Sistemlerinizin daha büyük bölümü yapay zekâ ile oluşturuldukça bu konulardaki kapsama alanınız azalabilir. Bunun sahibi kim? Kimin gerçekten anlayışı ve görünürlüğü var?

Güvenlik ve güvenilirlik ekiplerini endişelendiren şeyler bunlar. Müşterilerimizde ve kendi mühendislik ekibimizde bunu görüyoruz. Yapay zekâ ile kod yayımladığımızda mühendisler bunun Cursor tarafından tamamen veya büyük ölçüde oluşturulduğunu belirtmeye dikkat ediyor ve bu sistemleri fazladan inceliyoruz.

Yapay zekâ destekli testler konusunda da büyük bir eğilim görüyorum. Bazı şirketler testleri inceleyen bir yapay zekâ mühendisi oluşturuyor. Ancak günün sonunda yapay zekâ sistemleri çok güçlü olsa ve mühendislik ekiplerine zararlarından çok fayda sağlasa da, sistemimin yüzde 80’inin yapay zekâ tarafından oluşturulduğu bir dünya hakkında endişelenmek normal.

Bu durum güvenilirlik ve sistem sorunlarının çözülmesinin daha uzun sürmesine, güvenlik olaylarının artmasına yol açabilir. Çünkü görünürlüğünüz azalır. Dikkat edilmesi gereken nokta bu.

Hannah Clark: Katılıyorum. Bu, daha fazla çıktı elde ederken daha fazla denetim ihtiyacı doğması gibi ekiplerin karşılaştığı, daha az konuşulan lojistik sorunlardan biri.

Geçen hafta Mastercard Gateway’de ürün yönetiminden sorumlu kıdemli başkan yardımcısıyla konuştuk. Yapay zekâ araçlarının yeni pazarlara girmek için gereken formları doldurmak gibi işleri hızlandırdığından bahsetti. Yeni bir pazara girmek ve tüm düzenlemelere uymak için yapılması gereken çok büyük miktarda evrak işi var.

Yapay zekâ bunların büyük bölümünün çok hızlı tamamlanmasını sağlıyor. Ancak bu başvuruların sahipliğinin kimde olduğunu güvence altına almak için aynı düzeyde denetim de gerekiyor. Yani bir şeyi daha hızlı tamamlayabilirsiniz ancak aynı hızda hesap verebilir olmanız gerekir.

Bu, mühendislik ekiplerinin ve bu araçları hızlanmak için kullanan diğer profesyonellerin karşılaştığı büyük bir lojistik darboğaz gibi görünüyor. Hızlı teslimat yapabiliriz; ancak aynı hızda bu işin sorumluluğunu taşıdığımızı söyleyebilir miyiz?

Bu konu hakkında konuşmak çok ilginçti. Her tür departmandan ve disiplinden liderlerle konuştuk. Disiplinler birbirinden çok farklı olsa da endişelerin çoğunun birbirine ne kadar benzediğini görmek büyüleyici.

Bugün paylaştığınız tüm görüşler için teşekkür ederim. Bölümümüzün sonuna geldik. İnsanlar sizi internette nereden takip edebilir, Anish?

Anish Dhar: Beni LinkedIn veya Twitter’da takip edebilirler. Adımı arattığınızda beni bulabilirsiniz. Cortex’i de LinkedIn’de bulabilirsiniz.

Dünyanın farklı yerlerinde Android erişim zirveleri düzenliyoruz. Yakınınızdaki bir şehirde gerçekleşen bir etkinlik varsa mutlaka katılın. Bu tür konular üzerine düşünen insanlardan oluşan bir topluluk oluşturmak istiyoruz. Her şirket bu konuları düşünüyor; böyle güçlü bir topluluğun ortaya çıkması çok güzel.

Ayrıca mühendislik mükemmelliğine odaklanan IDPCON adlı konferansımızı da düzenliyoruz. Farklı işletme türlerinden liderler ve mühendislik mükemmelliği konusunda diğer geliştiricilerle bağlantı kurmak isteyen geliştiriciler konferansa katılıyor.

Harika konuşmalar olacak. Ekim ayında New York’ta gerçekleşecek. Umarım orada da görüşürüz.

Hannah Clark: Harika görünüyor. Bize haber verdiğiniz için teşekkürler. Bunu açıklama bölümüne ekleyeceğiz. Bizimle konuşmaya zaman ayırdığınız için de çok teşekkür ederim.

Anish Dhar: Beni davet ettiğiniz için teşekkürler. Çok güzeldi.

Hannah Clark: Dinlediğiniz için teşekkürler. Daha fazla harika içgörü, nasıl yapılır rehberi ve araç incelemesi için theproductmanager.com/subscribe adresinden bültenimize abone olun. The CPO Club’a podcast’lerinizi dinlediğiniz her yerden abone olarak bunun gibi daha fazla sohbeti dinleyebilirsiniz.