Yapay zeka, yön değil, bir güçlendiricidir.

Yazı yazarı, kaynak: InfoQ

Yapay zeka, kod yazmanızı 10 kat hızlandırıyor, sonra ne oluyor? Daha fazla kod, daha uzun derleme süreleri, daha ağırlaşmış testler, daha tıkanık kod incelemeleri ve kimse anlayamadığı bir kod tabanı anlamına gelir. Yazılım bir borçtur; ne kadar hızlı yazarsanız, o kadar çok borçlanırsınız.

Google baş yazılım mühendisi Adam Bender'in uyarısı oldukça açık: Bugün yazılım oluşturduğunuz yöntem, 10 kat hızda tamamen işe yaramaz. Ancak AI çağının gerçek kazananları, en yüksek çıktıya sahip takımlar değil, temel becerileri en iyi olanlardır. Çünkü AI yalnızca büyütür, yön vermez.

Google I/O 2026'da yapılan ana konuşmada Adam Bender, çoğu insanın henüz düşünemeyeceği bir soruyu ortaya attı: AI, kod üretimi hızını mevcut mühendislik süreçlerinin taşıyamayacağı seviyeye çıkardığında, geliştirici ekosistemimizde ne ilk olarak çökecek? Konuşmasını, yazılım üretimi için sosyal-teknik ekosistemi bütüncül bir şekilde inceleyen bir disiplin olan yazılım ekolojisi adlı, muhtemelen daha önce duymadığınız bir kavramla birleştirdi. Başka bir deyişle, yalnızca teknolojiye değil, insanlara, kültüre ve organizasyon içindeki yazılı olmayan kurallara da bakmalısınız. Bu konuşma videosuna dayanarak InfoQ, içeriği düzenledi.

Ana noktalar şunlardır:

• Yapay zeka, sorunlarınızı çözmek için varsayılan olarak size yardımcı olmaz. Pratikleriniz iyi ise, onları güçlendirir. Ancak yeterince iyi değilse, sadece daha fazla sorun yaratır.
• Herkes bir yapımcıdır, bu harika, ancak herkesin oluşturduğu her şeyi korumak zorunda kalınca değil.
• Mühendislik uygulamaları kutsal ve değişmez değildir. Uygulamalar değişir, ancak ilkeler önemlidir.
• Bu kritik anında, bir ilk çizgi yazılım mühendisi olarak, yazılım mühendisliğinin nereye doğru ilerleyeceğini belirleyen merkezde bulunuyorsunuz. Araçlardan iş akışlarına, mühendislik uygulamalarından mühendislik kültürüne kadar, çalışmakta olan sistemi görebiliyorsanız, kaldıraç noktalarını bulabilirsiniz.

“Sistem” nedir?

2026 yılındaki işiniz, 2020 yılında hayal ettiğiniz şekilde tamamen farklı olacak. Bugün olanları 2020 yılındaki benimle açıklamaya çalışırsanız, inanmazdım. Değişimler o kadar çok ki, biraz yorucu hale geliyor. Geleceği tahmin edemiyorum, ancak şu anki yazılım ekosistemini dikkatlice inceleyecek olursak, bazı cevapların hayal ettiğimizden daha yakın olduğunu düşünüyorum.

Bugün sizinle konuşmak istediğim bir kelime var: Yazılım Ekolojisi. Yukarı çıkmak için rastgele uydurulmuş gibi görünüyor, ama değil, bu gerçek bir terim. Tanımı vermeden önce, biraz arka plan hazırlamak istiyorum; biraz sistem düşüncesiye derinleşelim.

Bir sistem, bir dizi kurala göre çalışan ve bir bütün oluşturan birbirine bağlı öğelerden oluşur. Bu soyut gibi görünse de, sistemlerden alışkınız. Örneğin, klima: Hedef sıcaklığı bilen bir termostat, ısıtma veya soğutma görevini üstlenen bir HVAC sistemi, bir oda; sıcaklık uygun olduğunda sinyal durur. İşte bir sistem.

Eğer yazılım mühendisiyseniz, her gün sistemlerle çalışırsınız, sistemler tasarlıyorsunuz, kuruyorsunuz ve işletiyorsunuz; bu süreçte muhtemelen bir şeyi öğrendiniz: her şey birbirine bağlı.

Sonraki, özel bir sistem olan ekosistemdir. Tanım biraz uzun ancak önemlidir: Ekosistem, birbirine bağımlı aktörlerden oluşan, çevresiyle birlikte evrimleşen ve ortaya çıkan davranışlar ile merkeziyetsiz otonomiye sahip dinamik bir ağdır. İnsan diliyle anlatmak gerekirse, ekosistem çok karmaşıktır, bileşenleri derin bağlantılara sahiptir ve her bileşen kendi kararlarını alabilir ve eylemlerde bulunabilir. En önemli nokta ise: çevre, sistemin bir parçasıdır ve ikisini birbirinden ayıramazsınız.

Ekosistemler, zamanla büyüyen, değişen ve evrilen karmaşık uyum sistemleridir. Ayrıca, tek bir bileşeni inceleyerek gözlemlenemeyen, ancak sistemin tamamı bir araya geldiğinde ortaya çıkan bir özellik olan ortaya çıkma (Emergent Property) özelliğine de sahiptirler. Sürekli değişme, sürekli öğrenme ve ortaya çıkma bu nedenle, ekosistemlerde ne olduğunu anlamayı son derece zor hale getirir.

Ekosistem sözü duyduğunda aklınıza muhtemelen dağlar, nehirler, kuş sesleri ve çiçek kokuları gelir. Ancak dahili geliştirici ortamı da bir ekosistemdir: çeşitli araçlar ve hizmetler, kendi fikirleri ve talepleriyle gelen insanlar ve iş kısıtlamaları vardır. Ayrıca bu, insanlar ve teknolojinin bir araya gelmesiyle oluşan özel bir sistemdir: sosyo-teknik sistem. Sosyo-teknik sistemler son derece karmaşıktır, çünkü önce tüm bu teknolojilerle başlarsınız, ardından insanları da karıştırırsınız.

Muhtemelen farkında olmadan sosyal teknoloji sistemlerinin zekâsına maruz kalmışsınızdır. Conway Yasası'nı biliyor musunuz: bir organizasyonun oluşturduğu teknoloji, iç iletişim yapısını yansıtır. Basitçe ifade edersek, aynı bir derleyici üzerinde dört takım çalışıyorsanız, dört kez derlenmiş bir derleyici elde edersiniz, işte bu kadar. Conway Yasası'nın temel gözlemi, teknolojiyi nasıl oluşturduğumuzun, onu oluşturan organizasyon yapısıyla ayrılmaz şekilde bağlantılı olduğudur; organizasyon, sonunda oluşturulacak şeyi şekillendirir.

Ancak sadece organizasyon yapısı değil, değerler ve kültür de geliştirici ekosistemini derinlemesine etkiler. Ekosisteminiz, organizasyonun teşvik ettiği şeyleri oluşturur; mühendislik kültürü, geliştirici ekosistemi etrafında bir ortam yaratır. Sosyal teknik sistemleri anladığınızda, yazılım geliştirmenin her yerinde onları göreceksiniz: mimari, olay inceleme kültürü, kod incelemesi, güvenlik stratejileri — her yerde. Ne oluşturduğumuz ve bunları nasıl oluşturmayı seçtiğimiz, neyi önemsiyorsak onu yansıtır. Eğer yeterince dikkatliyseniz, bu bilgiyi kullanarak değerlerinizi güçlendirebilir ve onları oluşturduğunuz şeylere aktarabilirsiniz.

Şimdi size doğru bir tanım verebilirim: Yazılım ekolojisi, yazılım üretimiyle ilgili sosyo-teknik ekosistemleri bütüncül bir şekilde inceleyen bir disiplindir. Eğer öncekiler biraz soyut geldiyse, endişelenmeyin, şimdi gerçek bir örnek inceleyelim.

Google'un geliştirici ekosistemi

Google'dan bahsediyorum, orada çalıştığımdan dolayı onu övmek için değil, çünkü en iyi bildiğim geliştirici ekosistemi o. Amacım, sizin Google'ı takip etmenizi söylemek değil; çünkü siz farklı şirketlersiniz, farklı aşamalardasınız ve farklı dengelemelerle karşı karşıyasınız. Google'ın yaptığı birçok seçim, ekosistemi kurarken o dönemdeki spesifik ihtiyaçlarımızla ilgilidir.

Birkaç yıl önce, dahili olarak "Flamingo Kitabı" adını verdiğimiz bir kitap yazdık. Kitabın yarısı sürüm kontrolü ve testlerle ilgiliydi, ancak tüm ilk bölüm mühendislik kültürüne ayrılmıştı. Çok sayıda kişi, neden kültüre bu kadar çok yer ayırdığımızı sordu; çünkü Google'ın kültürünü anlamazsanız, neden bu teknik kararları aldığımızı anlayamazsınız; bunlar birbirine bağlıdır.

Google'ın birkaç benzersiz kültürel özelliği vardır. Derin bir mühendislik odaklıyız ve önemli kararlar alınırken mühendisler her zaman mevcuttur; şeffaflığa büyük önem veririz ve mümkün olduğunca tüm belgeleri ve kodları herkes için açık tutarız; yardımseverliğe teşvik ederiz; aslında Google'tan ayrılan herkesle konuşursanız, yardımcı olma isteği onların ilk bahsettikleri şey olur; kod incelemesini sınav düzeltme değil, rehberlik fırsatı olarak görürüz; standartlaşmaya büyük önem veririz; sürekli iyileştirmeye inanırız; sorumluluk talep etmeyen olay incelemelerini öncüleriz; sürdürülebilirliğin kahramanlık üzerine, otomasyonun el emeği üzerine daha değerli olduğuna inanırız. Elbette bu tüm idealleri her zaman gerçekleştiremeyiz, ancak kültürel olarak bu yönde çaba sarf etmeye devam ediyoruz.

Teknik olarak? Tek bir kod deposu, neredeyse tüm kodlar tek bir depoda; ana kola dayalı geliştirme, her değişiklik doğrudan ana kola entegre edilir; bir ikili dosya oluştururken, neredeyse her satır kod kaynaktan derlenir; herkesin kullandığı tek bir yapılandırma araç zinciri; küresel bir test otomasyon platformu, tüm testler tek bir yerde çalıştırılır, her gün milyarlarca test senaryosu; global bir "son yeşil" sinyali, basit bir dahili web sitesiyle herhangi bir derlemenin durumunu size anında bildirebilirim; unified hesaplama ortamı, bu nedenle "benim makinemde çalışıyor" gibi durumlar neredeyse mümkün değildir; yüksek derecede standartlaştırılmış geliştirici çerçeveleri ve sınırlı sayıda temel programlama dili.

Bu kültür ve teknoloji karışımı, Google'un bugünün halini oluşturdu; bunun yalnızca bir kısmını anlayıp diğerini göz ardı edemeyersiniz.

Ortak bir kader

Bizi sürekli olarak yönlendiren bir ilke seçmem gerekirse, “Paylaşılan Kader (Shared Fate)”’i seçerdim. Bu, bir ekosistem ile bileşenleri arasındaki sıkı bağlantıyı tanımlar; yüksek paylaşılan kaderli bir ekosistemde, bir bileşen tüm diğer bileşenleri etkileyebilir. Geliştirici ekosistemlerinde, paylaşılan kader hem bir teknik seçimdir hem de bir sosyal seçimdir. Tüm insanların aynı teknolojiyi kullanmasına sadece izin vererek paylaşılan kaderi sağlayamazsınız; bu teknolojileri nasıl yöneteceğiniz konusunda sosyal bir sözleşmeniz de kurmalısınız.

Google'da, ortak kader tek bir kod deposuyla başlar. Şirketin her satır kodu, Android ve Chrome gibi az sayıdaki istisnalar dışında, ortak bir depoda bulunur. Tüm kodlar ana kola gönderilir, dal yoktur, sürüm numarası yoktur, her şey bir yerde toplanır. Bu ortak kader, bir dosyada bir güvenlik düzeltmesi uygulamamıza ve bir hafta içinde şirketin her uygulamasının düzeltilmiş olduğunu bilmemize olanak tanır. On satır kodla on milyar satır uygulama ve sistem yazılımını düzeltmek, bir süper güç gibidir.

Ancak ortak bir kader her zaman iyi bir şey değildir; bu bir seçimdir. Bazı durumlarda ortak bir kader uygun değildir, örneğin üretim ortamında hiçbir zaman bir hizmetin tüm diğer hizmetleri etkilemesini veya bir kümenin tüm bir bölgeyi bulaştırmasını istemeyiz. Bu nedenle, kaskat etkiler yaratabilecek tehlikeli ortak kaderlerden kaçınmak için büyük çaba harcadık. Ortak kader bir dengelemedir; doğru yerleştirme konumunu bulmanız ve bunun sizin için çalışmasını sağlamalısınız.

Büyük ölçekli değişiklik

Paylaşılan kader ortamının en ilginç ortaya çıkan özelliklerinden biri, büyük ölçekli değişikliklerdir. Bunun üzerinde durun: AI ortaya çıkmadan çok önce, Google'ın dahili araçları, bir geliştiricinin milyonlarca satır kodu değiştirmesini mümkün kılıyordu—milyonlarca satır, ki onları okumayacak, daha asla tekrar görmeyecek ve muhtemelen tamamen bilmediği kodlar. Bunun tamamen otomatikleşmesini sağlayan araçları inşa ettik, bugün de aynı şekilde yapıyoruz ve en az on beş yıldır bunu yapıyoruz.

Bu yetenek, bize tek bir kod deposunu sürekli olarak geliştirmeye, dilleri ve çerçeveleri güncellemeye ve iç ortamın sertleşmesini önlemeye olanak tanır. Büyük ölçekli değişiklikler olmasaydı, bugünün Google’ı olmazdık. Bu araçları geliştiren meslektaşlarımız, şirketin ihtiyaç duyduğu hızda ilerlemesini sağlayan arka plandaki kahramanlık işlerini yapmaktadır.

Ancak anahtar nokta, büyük ölçekli değişiklikleri mümkün kılan kültürel ve teknik bileşenleri anlamadan bunu gerçekten anlayamamanızdır. Ne gerekiyor? Yaygın bir test kültürü, herkesin test yazması gerekiyor. Tek bir test platformu, sonuçların nereden alınacağını biliyorsunuz. Ortak bir build aracı, benim build ettiğimle sizin build ettiğiniz aynı sonucu veriyor. Standartlaştırılmış kütüphaneler, bileşenleri değiştirdiğinizde hangi sürümün sizin için işe yaradığını, benim için yaramadığını aramak zorunda kalmıyorsunuz. Standartlaştırılmış kod incelemesi, kod deposunun kendisindeki şeffaflık, böylece hangi kodların değiştirilmesi gerektiğini biliyorsunuz. Büyük ölçekli değişiklikler, Google’ın “otomasyon, el emeğinden üstündür” fikrinin en nihai örneğidir ve bu, tüm ekosistem birlikte çalıştığında mümkündür. Geliştirici ortamının bir parçasını gösterip “işte bu, bunun nedenidir” diyemezsiniz; tüm parçaların birbirine bağlanmasıdır neden.

Ekosisteminiz, dengeleriniz

Her geliştirici ekosistemin böyle bir ortaya çıkarma özelliği vardır. Genellikle çalıştığınız yerin biraz farklı hissettirdiği şeyleri temsil eder, çünkü bunlar yaptığınız bir dizi seçimin sonucudur.

Google'un geliştirici ekosistemi, teknik ve iş hedeflerimizi hizmet etmek için benzersiz bir denge kurar. Ancak her ekosistemde olduğu gibi, bu ekosistem tüm görevlerde mükemmel olamaz. Biz, bazen geliştirici verimliliğini mağdur ederek bile, aşırı ölçeklenebilirlik, güvenlik ve performansı optimize etmeyi tercih ediyoruz ve bu dengeyi kurmaya razıyız. Beş kişilik bir startup'ın ekosistemi tamamen farklı görünecektir; hız ve esneklik en önemli unsurlar olacaktır.

Çoğunuzun yaşadığı ekosistem, beş kişi ile yirmi bin kişi arasında yer alıyor. Yapmanız gereken dengelemeler çok önemlidir, çünkü bu dengelemeleri incelediğinizde, organizasyonun gerçek değerlerini—anladığınızda değil, gözlemlediğinizde—görebilirsiniz. Bu değerleri anladığınızda, ortaya çıkan değişimi şekillendirmeye başlayabilirsiniz.

10 kat anı: Her düğüm baskı altında

Token yiyen fillerden konuşmanın zamanı geldi: AI ilk geliştirici ekosistemi nasıl görünür?

Sıfırdan tamamen yeni bir ekosistem kurmak elbette harikadır, ancak bunu yapma lüksüne sahip olan yoktur. Neredeyse her parçayı değiştirirken yazılımın teslimini sürdürmeniz gerekir. Şirket, sorunsuz kalmasını sağlarken değer yaratmaya devam etmenizi bekliyor.

Kendinize şu soruyu sorun: Bugünki geliştirici ekosistemini ne kadar iyi tanıyorsunuz? Onu tamamen çizebilir misiniz? Tüm bileşenlerin nerede olduğunu biliyor musunuz, sadece teknik olanları değil, sosyal olanları da mı? Ekosisteminizin hangi unsurlardan oluştuğunu listeleyebilir misiniz? Kurumunuzdaki diğerlerinin bu konuda ne kadar bilgisi var? Avantajları ve dezavantajları nelerdir? Sıkışma noktaları nerededir? Nerede kısıtlanıyorsunuz, nerede özgürsünüz? Hangi seçimlere sahipsiniz? Hangi ortaya çıkan özellikler gördünüz? Belki de en kritik soru: Ekosisteminizin gelecek on sekiz ay içinde kod miktarını 10 ila 15 katına çıkarmak zorunda kalması durumunda, neyin önce çökeceğini biliyor musunuz?

Dünyanın her geliştirici ekosistemi, belki de henüz her yerine ulaşmamış olsa da, yakında gelecek olan ve her geliştirici ekosisteminin 10 katlık anla yüzleşmesi zorunlu olacak köklü bir dönüşüm yaşıyor. Bu inanılmaz bir dönem, ancak aynı zamanda oldukça kafa karıştırıcı. Geçtiğimiz yirmi beş yıl boyunca bilinçli olarak şekillendirdiğimiz tüm dengelemeler yeniden ayarlanacak.

Kod üretiminin 10 kat hızlanması ve mühendislik geliştirme hızının 10 kat hızlanması iki farklı şeydir. Google'da genellikle mühendisliğin zamanla entegre edilen programlama olduğunu söyleriz. Ancak sorun şu ki, şu anda kodlama aşamasını büyük ölçüde hızlandırıyoruz ve kod makinesini hızlandırıyoruz. Bu nedenle, gerçekten müşterilere sonuç sunabilmek için bu kod makinesi etrafında mühendislik yapma yolları bulmalıyız. Bu verimlilik artışı nereye kadar sürebilecek kimse bilmiyor, ancak kesin olan bir şey var: Buradan itibaren yukarı doğru ilerliyoruz.

Sorun şu ki, bugün bizim yazılım oluşturup teslim etme şeklimiz, 10 kat veya 100 kat hızda işe yaramaz, bir şeyler değişmelidir.

Geliştirici ekosistem haritasının basitleştirilmiş bir versiyonuyla başlayalım. Etkinlik düzeyi 10 kat artan bir dünyada ne değişmelidir?

Kod girişi

Kod yazın. Eğer herkes kod yazmayı çok hızlı hale getirirse, kod miktarı çok artar ve bu iyi bir şey değildir. Jeff Atwood, yazılımın bir borç olduğunu söylemiştir. Yani, 10 kat kod, 10 kat borç demektir. Herkese bir sürü token verip “İyi şanslar” demek mümkün değildir; eğitimi tamamladıktan sonra yatırım yapmayı düşünün: Mühendislik uygulamaları belgeleriniz nerede? Bunları nasıl geliştireceğinizi biliyor musunuz? Bundan sonra düşünebilirsiniz.

Sistem oluşturun. Daha fazla kod, daha büyük sistemler daha uzun derleme süreleri anlamına gelir. Şirketinizde şu anda kimse derlemenin yavaş olduğunu şikayet etmiyor olabilir, ama tahmin edin ne oluyor? Daha da yavaşlayacaklar. Ve eğer bir ajan çok sayıda işi yönetiyorsa, derleme sayıları da patlamaya geçiyor. Derleme, hem zamanda hem de hesaplama kaynaklarında ücretsiz değil. Derlemeye ne kadar zaman harcadığınızı belki hiç fark etmediniz, ancak 10 kat büyüklükte kesinlikle fark edeceksiniz.

Kod tasarımı. Çözümlenmeyi teşvik edecek uygun bir ajan beceriniz var mı? Farklı yetenekleri hızlı ve güvenli bir şekilde birleştirmek için uygun bir sunucu çerçevesi var mı? Şirketinizde kaç farklı Web uygulaması dağıtımı var? Kaç farklı sunucu çerçevesi çalışıyor? Ajanların yazdığı kodun bileşen yeniden kullanımını nasıl yönetiyorsunuz? Belki bunun önemsiz olduğunu düşünüyorsunuz. Ancak ajanlar, yazması kolay ancak bakımı zor kodlar üretirse, bu durumda şaşırmayın; bu, mevcut standart seviyedir. Ajanlar kod yazmada ustalar, ancak uzun vadeli düşünmeyi her zaman yapmazlar. Bu kodların iyi bir şekilde yeniden yapılandırılacağını kesinlikle sanmıyorum. Sorun değil, bu kısmı ileride çözeceğiz. Ancak gerçek şu ki, ajanlar bize büyük ölçüde yardımcı oluyor ve bu yetenekleri her gün en verimli şekilde nasıl uygulayacağımızı bulmalıyız.

Bir noktada, bu agentleştirilmiş işler, ikili dosyalarınızı derleyemeyecek kadar büyük hale getirebilir. Veya telefonlara yükleyemeyecek kadar büyük. Bu soruyu sordunuz mu: Derleyebileceğiniz en büyük ikili dosya ne kadar büyük? Cevabı bilmiyorum, ancak Google'da sınırı zorluyoruz ve bazı ikili dosyaların derlenemeyecek kadar büyük olduğunu biliyorum; bunu çözeceğimize inanıyorum. Ancak gerçek şu ki, büyük ölçekli sistemlerde birçok etki zinciri vardır ve ölçeklendirme etkisi her yerdedir.

Belki mikroservis teknoloji yığınınsınız ve düşünüyorsunuz: Hizmetlerim çok küçük, neden endişeleneyim? Ama bir sorum var: 10 kat ağ trafiği, 10 kat hizmet sayısı, 10 kat iletişim hacmi, bunlar için hazır mısınız? Kimse ölçeklendirmenin etkilerinden kaçamaz.

Kod incelemesi. Tüm bu kodları güvenilir bir şekilde derleyemeyeceğinizi varsayarsanız, kod inceleme sürecinizi nasıl değiştireceksiniz? Herkes kod incelemesinden endişeleniyor, bunun için nedenleri var. Bu çok insani süreci büyük bir baskı altında tutuyoruz ve birçok durumda bu süreç bir darboğaz haline geliyor; insanlar darboğaz olmak istemez. Onlara baskı uyguladığınızda davranışları garip hale gelir. 10 kat daha fazla kod miktarı varsa, ya 10 kat daha büyük değişiklikler ya da 10 kat daha fazla değişiklik elde edersiniz. Teknik lideriniz gerekli inceleme hızını koruyabilir mi? Çoğu teknik lider, beş adet 10 kat geliştiricinin bir günde ürettiği kod miktarını bile inceleyemiyor.

Bu nedenle, bir darboğaz olmamak için süreçleri yeniden düzenlemeye başlarlar, kolay yollar seçer ve kimseyi tıkandırmamaya çalışırlar, çünkü kimse bir tıkandırıcı olmak istemez. Bir kısmını AI ile çözebilirsiniz, kod incelemelerini iyileştirmek için AI uygulayabilirsiniz. Ancak bu yalnızca kısmen bir çözüm olur, çünkü ekip üyeleriniz kod yazmazsa, kodla tek karşılaşmaları inceleme anıdır ve bu sırada dikkat yetersizse, kod tabanının nasıl geliştiğini kim izliyor? Kimse. Çok kısa bir sürede kod tabanınız, kimse anlayamayacağı bir karışıklığa dönüşecektir.

Token ekonomisi. Tokenlar pahalı, bunu bazılarınız zaten biliyorsunuz. Büyük ölçeklerde, tokenlar dikkate almanız gereken gerçek bir maliyettir. Şirketinizdeki herkes 10 veya 100 kat token kullanmaya başlarsa ne olur? Bir gün içinde aylık bütçenizi tamamen harcarsanız ne olur? Tokenları nerede harcamalı olduğuna karar vermek zorunda kalırsanız, nereye öncelik vermeniz gerektiğini biliyor musunuz? Hatta tokenların nereye doğru aktığını görebiliyor musunuz?

Bu basit sistemin yalnızca ilk birkaç düğümünde zaten sorunları tespit ettik. Ayrıca, bazı zorlu ikinci derece etkilerin ortaya çıkacağı çok açık.

Test ve sürüm kontrol

Test altyapınızın ne kadar hesaplama kaynağı tükettiğini daha önce gözlemlediniz mi? Google'da, test hızımdan hiç memnun kalmadım.

Sürüm kontrolüne alınan her değişiklik test edilmelidir. Ancak bunun dışında, ajanlar testleri çalıştırmayı da sever, çünkü testler kendilerinin ne kadar iyi yaptığını gösterir. Bu nedenle ajanlar ek iş yükü oluşturur ve benim yapmam gereken iş artar. Peki, 10 kat daha fazla gönderim ve ajanın yaptığı tüm işler, şu anda kaç test hesaplama kaynağı tüketiyor?

Aslında durum daha da kötü olabilir. Google'da gözlemlediğimiz gibi, kod tabanı büyüdükçe bağımlılık grafiği lineer değil, karesel olarak büyüyor. Yani kod tabanınız 10 kat büyüdüğünde, 10 kat değil, 100 kat hatta 1000 kat daha fazla test çalıştırmak zorunda kalabilirsiniz. Bu oldukça ilginç bir zorluk olacak ve bir noktada bütçenizin bir satırı haline gelecek. Eğer şu anda test hesaplama kaynakları maliyeti konusunda endişelenmiyorsanız, bu beni daha da endişelendiriyor, çünkü bu da muhtemelen yeterli test yapmadığınız anlamına geliyor ve bu agent'ler güvenli bir ağ olmadan kod tabanınızda YOLO yapıyor.

Derleme ve test sorunları çözüldü, şimdi sürüm kontrol sistemine bakalım. En popüler sürüm kontrol sistemleri performans için optimize edilmemiştir; bunlar tutarlılık ve sıralama için optimize edilmiştir. Bu, onların temel işidir: tam bir kayıt tutmak, hızla koşmak değil. Sürüm kontrol sisteminiz dakikada kaç kez gönderim yapabilir? Garanti ediyorum, hayal ettiğinizden çok daha az. Gerekli olan 10 kat hızı ölçeklendiremez. Sürüm kontrol sisteminizin performansını son kez ne zaman düşündünüz? Git geliştiricisi değilseniz, muhtemelen hiç düşünmediniz. Aslında, sürüm kontrol performansını tartışmaya dönmek, bir şeylerin ciddi şekilde sapmış olduğu anlamına gelir. Geliştirici deneyiminin en alt katmanındayız, ancak bu sistemik değişikliklerin sonucudur: bu değişiklikler sisteminizin her köşesine ulaşır ve derhal şunu söyler: Hey, dikkat ediyor musun? Çünkü beklemediğiniz bir şey geldi.

Yüzlerce, binlerce küçük depo çalıştırmış herhangi birine sorun, sürüm kontrol sorunlarını çok sayıda küçük depo kullanarak çözmeyi planlayan arkadaşlara, bunun tamamen yeni bir dizi zorluk olduğunu garanti edebilirim; AI bu sorunları mutlaka daha kolay hale getirmeyecektir.

Beklenmedik Liste

Şu ana kadar sadece nispeten kolay bulunabilen kapasite düğümlerine odaklandık, yani bir sayıyı 10 ile çarpıp iyi mi olacak, kötü mü olacak diye sorduk; bunun dışında birçok beklenmedik zorluk da var.

Doğrulama stratejisini kontrol edin. Bugünki doğrulamanız büyük ölçüde birim testlerinden ve bazı entegrasyon testlerinden oluşuyor. Ancak 10 kat kod ve 10 kat hizmet dünyasında, entegrasyon testleri kalite stratejisinin en önemli parçası haline gelecektir. Bugünki entegrasyon testi yaklaşımınıza kaçınız memnun? Ben de memnun değilim. Entegrasyon testleri gerçekten zor, şu anda istediğim şekilde entegrasyon testi yapabileceğim bir araca sahip değilim.

Boole cebiri ile ilgili bir sorun. Bugün bir yazılım yayınlıyorsunuz ve her testin geçmesini, tüm Boole değerlerinin yeşil olmasını, her şeyin sorunsuz olduğunu görmeden yayınlamıyorsunuz; bu oldukça mantıklı. Ancak bir milyon testiniz varsa ve alt yapıda bir milyon testi çalıştırmak için güvenilirlik sorunu yaşıyorsanız ne olur? Yazılımı yayınlamak için tüm Boole değerlerinin doğru olması gerekiyor fikri uygulanamaz hale gelir. Tüm testleri çalıştıramayacağınız için, hangi testlerin doğru olduğunu belirlemek için istatistiksel bir stratejiye ihtiyacınız olur.

Çok büyük bir değişiklik. Her yerde yeniden yapılandırmak, dili ve çerçeveyi değiştirmek gerçekten heyecan verici. Ancak binlerce, on binlerce, hatta milyonlarca satırın birleştirme çatışmalarını yönetmek için destekleyici bir iş akışı ve toplumsal anlaşmaya sahip misiniz? Muhtemelen hayır. Şirket içinde herkes çok büyük değişiklikler yapabilseydi, yeni bir iş akışı stratejisi gerekecekti.

Ajanlar savaşını düzenliyor. Bir ajan bir değişiklik yapıyor, başka bir ajan koşarak geliyor ve “Hayır, beğenmedim, farklı bir değişiklik yapacağım” diyor. Komik görünüyor, ancak her iki tarafa da token ücreti ödüyorsanız fark ediyorsunuz.

Yayın hızı. Müşterilere bugün ne sıklıkla yayın yapıyorsunuz? Günlük? Bu iyi bir seviye. Eğer değilse, burada bir sorun var: 10 kat daha fazla yazılım elde edeceksiniz ve bu yazılımların hepsi bir yerde yer almalı. Günlük yayın yapmıyorsanız, her değişiklik çok daha büyük hale gelir. SRE arkadaşlarım size çok büyük değişikliklerin çok korkutucu olduğunu söyleyecektir. Bunu yapmayın. Ancak kodun değer yaratması için dağıtılmış olması gerekir, bu yüzden daha sık yayın yapmaya çalışabilirsiniz, bu harika bir fikir ve DORA arkadaşları memnun olacak. Ancak bir noktadan sonra getiri azalır, saniyede bir kez yayın yapmak büyük bir değer sağlamaz. Kod hala büyüyecek ve bunu daha fazla risk yaratmadan nereye koyacağınızı anlamalısınız.

İç API. Tüm API'lerinizin aniden açık hale geldiğini sürekli olarak arkadaşlarımla paylaşıyorum. Agent, sizinle görüşmeden API'leri bulup doğrudan çağırır. Erişebileceği her şeyi kullanır, bunu garanti ederim. Eğer iç API'leri ve iç veri kümelerini hiçbir zaman açık internet API'leri gibi korumadıysanız, agent sizin bulunmasını istemediğiniz şeyleri bulacaktır.

Jevons paradoksu. Jevons, bir kaynak ne kadar ucuz ve verimli olursa, o kadar çok kullanıldığını söylüyor. Token'ların patlaması bunun canlı örneği. Onları her yere yerleştiriyoruz, bu da nasıl çalıştığımızı ve işi nasıl düşündüğümüzü değiştiriyor. Daha önce görünmez olan verimlilik işlerine fiyat veriyoruz; bu, davranışlarımızı nasıl etkileyecek? Henüz bilmiyorum.

Rollback. Neden rollback'ün bugün temel olarak mümkün olduğunu biliyor musunuz? Çünkü yazılımınızı üretme hızınız, üretim ortamında sorunları tespit etmeniz için gerekli olan süreden biraz daha yavaştır. Eğer çok çok hızlı bir şekilde yayınlıyorsanız, herhangi bir sorunu tespit edemeden önce, rollback davranışınız nasıl olurdu? Her rollback, üzerinde birikmiş ve birbirleriyle çakışan birden fazla değişiklikle başa çıkmak zorunda kalırdı. Bu yüzden sadece daha hızlı yayınlamak yeterli değil, rollback gibi önemli bir güvenlik valfi dahil olmak üzere tüm sistemi düşünmelisiniz. Arada bir, token motorunu nereye koyacağınızı dikkatli seçmelisiniz. Eğer rollback sürecinizi, bir agent'in yeterli kapasiteye sahip olmasına bağlı hale getirirseniz ve daha önce kimse bu agent'in token bütçesini tükettiyse ve şimdi rollback yapamıyorsanız, bu muhtemelen iyi bir şey değildir.

Herkes bir yapımcıdır. Şirket içinde beğenmediğiniz bir aracın yerine bir vibe code alternatifi düşündünüz mü? Şimdi bunu şirketin herkesi ve her aracına çarpın. Herkes tamamen farklı araçlar kullanırken, şirketin sosyal dokusu ne olur? Şanslıysanız, tüm verilerin aynı yere girdiği tek bir veri alt yapınız vardır, o zaman sorun yoktur. Ancak yoksa? Herkesin bir yapımcı olması harika, ancak herkesin oluşturduğu her şeyi korumak zorunda kalana kadar.

Teknik liderlik intensif kursu. Bir teknik lider olmak neden o kadar uzun sürer? Çünkü karar vermenize yardımcı olacak sezgi, yargı ve uzmanlık birikimini kazanmanız gerekir; çünkü bir ekip yönettiğinizde, hatalarınız tek başına çalışırken olduğundan çok daha geniş kapsamlı etki yaratır. Yeni mezun biri, hiçbir sezgi ve yargıya sahip olmaksızın elli agent çağrabilen bir ortama girdiğinde ne olabilir? Ben nasıl 6 ayda on yıllık deneyim öğretebilirim? Bilmiyorum.

İnsan dikkati, sahip olduğumuz en değerli kaynaktır. Şimdi çok fazla gürültü var, o kadar çok ajan ve o kadar çok şey dikkatimizi kazanmak için rekabet ediyor, bunu yönetmenin bir yolunu bulmalıyız. Daha önce, sorun yaratma yeteneğimizin dikkatimizi harcama yeteneğimizi aşamayacağı gerçeğinden yararlandık, ancak artık durum böyle değil.

Bunlar çok gibi görünüyor, çünkü bir sistemde her şey birbirine bağlı. Daha önce bahsettiğim tüm zorluklardan herhangi birini, sistemin yalnızca bir düğümünü izleyerek çözemezsiniz; tüm sistemi görmelisiniz.

Agent tabanlı geliştirme için, hepimizin sistemsel düşünme yöntemini sürekli olarak öğrenmeye başlamamız gerekir. Sistemleri düşünürken dikkat etmeniz gerekenler şunlardır: nesnelerin büyümesi, zamanla değişen etkiler, neden-sonuç ilişkilerinin hangi yönde aktığı, hangi düğümlerin tüm komşularıyla iletişim kurduğu, ortaya çıkmanın nasıl göründüğü ve nereden geldikleri bilinmeyen şeylerin ne olduğu. Teşvik mekanizmaları nedir? Sosyal ve teknolojik olanlar, kapasite, geri bildirim döngüleri ve darboğazlar, bu sistem analizinin araçlarıdır.

Görünüşe göre karmaşık, ancak sadece iki soru gerekiyor: Neden (Why?), ve eğer... olsaydı (What if?). Neden entegrasyon testlerimiz bu kadar az? Eğer birim testlerinden daha fazla entegrasyon testimiz olsaydı? Neden bu özel dilleri kullanıyoruz? Eğer AI tüm kodu yazsaydı?

“Neden” sistemin çekirdeğine girip nasıl çalıştığını anlamak için kullandığınız matkaptır. Hepiniz neden sorusunu sormada çok yeteneklisiniz, ancak “Peki ya” kısmı daha zordur. “Peki ya”, daha önce çok iyi tasarlanmış olduğuna inandığınız uygulamaları bırakmanızı gerektirebilir ve bu korkutucu olabilir. Test yazmazsan ne olur? Test yazmazsan ne olur? Çok uzağa gitmeyin. Ancak bunun olmasını sağlarsanız, “Peki ya” oldukça heyecan verici de olabilir.

Yapay zeka bir güçlendiricidir, yön değildir.

Yapay zeka bir kuvvetlendiricidir. Bu fikir, DORA'daki arkadaşlarımdan geldi; geçen yılki yapay zeka geliştirme raporlarında, işleri gerçekten anlayan takımlar arasında bir ilişki bulundu: Yapay zekayı nasıl kuvvetlendirici hale getireceklerini anladılar.

Yapay zeka size daha fazla şey sunabilir. Daha fazla test, daha fazla belge, daha fazla kod, ancak aynı zamanda daha fazla karışıklık. Büyütme, yön değil, genişliktir. Yapay zeka bu şeylerin nereye gittiğini umursamaz, sadece size daha fazla verir. DORA'nın gerçekten keşfettiği şey, temel becerileri sağlam olan takımların bu büyütme etkisini faydalı bir yöne yönlendirebilmeleridir.

Bu soruyu ortaya çıkarır: Temel becerileriniz hakkında nasıl hissediyorsunuz? Şirketinizin karar alma kültürü nasıl? Bunları iyileştirmek için ne yapabilirsiniz? Teknoloji stratejisi nedir? Geliştirici verimliliği üzerinde kimse dikkatli mi? Örgütünüzdeki insanlar bugün nasıl iş birliği yapıyor? Güvenlik durumu nedir? Kod sağlığı, sürüm temizliği, güvenilirlik nasıl? Yapay zeka, varsayılan olarak size hiçbir sorunu çözmüyor. Uygulamalarınız iyi ise, onları güçlendirir. Ancak yeterince iyi değilse, daha fazla sorun yaratır.

Ancak temel becerileriniz güçlü olsa bile, yakında gerçek bir yolculuğa çıkacağız. 2030 yılına kadar bugünün geliştirici ekosistemimizin, 2001 yılında bize ne kadar uzak göründüyse, o kadar uzak olacağını tahmin ediyorum. 2001 yılında hâlâ CD-ROM’larla yazılım yayınlıyorduk, 2030 yılında belki de bu kadar uzakta olacağız.

Temel becerilerinizi geliştirmeye devam ederken, yol boyunca düşünmeniz için size dört şey sunuyorum.

Birincisi, altyapı kapasitesi. Kaç kaynağınızın olduğunu bilmiyorsanız, AI’yi dağıtamaz, hesaplama kaynaklarını dağıtamazsınız; bunları takip etmenin iyi bir yoluna ihtiyacınız vardır.

İkinci olarak, stratejiyi doğrulayın. Doğrulanmamış yazılımları yayınlamayın ve yapmamalısınız. Ancak doğrulama stratejileri değişir, şimdi net bir şekilde düşünme zamanı. Entegrasyon testleri, en önemli silahınız haline gelecek ve muhtemelen henüz uygun bir araca sahip değilsiniz.

Üçüncüsü, izolasyon. Farklı amaçlar için birçok kod alacaksınız, bazı amaçlar daha önce hiç kodla kullanılmamıştı. Bu sorun değil, ancak eğlenceli bir prototip kodunun gerçekten üretim ortamına girmesini istemiyorsunuz. Eğlenceli şeyleri kazanç getiren şeyleri etkilemesine izin vermeyin.

Dördüncü, soyutlama. Kötü seçimler yapmaktan geliştiricileri korumak için soyutlama oluşturuyoruz; bu nedenle kütüphaneler ve çerçevelerimiz var. Kimse web sunucusunu sıfırdan yazmaz. Ajanlara çok sayıda karar verme hakkı vermek aynı sonucu doğurur; bu nedenle ajanların takip edeceği iyi soyutlamalara ihtiyacınız vardır. Onlara kötü seçenekler vermeyin.

Bir şeyi kabul etmeniz gerekir: mühendislik uygulamaları kutsal değildir. Uygulamalar değişir, prensipler ise önemlidir. Bu söylemek kolay, yapmak zordur; ekipmanızın neden bu şekilde yazılım test ettiğini veya yayın sürecinin neden böyle çalıştığını asla gerçekten düşünmediyseniz, bunu geliştiremezsiniz. Prensipleri anlarsanız, bu 10 katlık anı aşmak için size güç ve güven kazandırır.

Şu anda yazılım mühendisleri için büyüleyici bir dönem var. Çalıştığımız her boyut yeniden tanımlanıyor; daha önce hiç olmadığı kadar yaratıcılık sergileme ihtiyacımız var; bağlam yönetimi, token ekonomisi, model kayması gibi sorunlarla başa çıkabilmek için becerilere ihtiyacımız var; yaratıcılığa ihtiyacımız var; her şeyi optimize etme tutkusuna fazla kapılmamalı, keşfe teşvik etmeliyiz.

Bana uyku vermemiş bir soru var: Kod tabanı büyüdükçe, ona zihinsel olarak nasıl hakim kalırız? Zihinsel hakimiyet, insanın karşıdaki şeyi nasıl akıl yürütebileceğidir. Bu savaşta en az on beş yıldır kaybediyoruz; en büyük sistemlerimiz artık tek bir insanın düşünebileceği boyutun çok ötesinde. İnanmıyorsanız, bir deney yapın: Takımınızın her üyesine sistem mimari diyagramı çizer misiniz? Kaç farklı versiyon elde edeceğinizi görün.

Çok sayıda yazılım sisteminiz çok hassas; bir yanlış satır kod veya hatalı yapılandırma bayrağı, milyonlarca satırlık bir sistemi bozabilir. Bu hassasiyet, değişiklik yapmadan önce üç kez düşünmenizi zorunlu kılar. Ancak AI hakkında çok heyecan verici bir fikrim var: Sürekli güncellenen, neredeyse etkileşimli bir mimari uzay, bana sorular sorabildiğim. Eğer buradaki kapasiteyi doğu sahiline taşısak ne olur? Kullanıcı artışı aniden %40 zıplarsa ne olur? Bugün hatta orta boyutlu bir sistem için bile, bu tür sorulara cevap vermek fonksiyonel olarak neredeyse imkânsız; değişkenler çok fazla. Ama AI çok büyük veri kümelerini anlayabilir, bu yüzden burada keşfedilecek bir şey olduğunu düşünüyorum.

Bu soruyu sebevimiz, sadece kod makinelerini daha hızlı döndürmekle kalmayıp, zaten oluşturduğumuz şeyleri nasıl daha iyi anlayabileceğimizi sormaktır.

Değişim, çoğunuzun yaşadığından çok daha hızlı gerçekleşiyor. Şu anda yapabileceğiniz en önemli şeylerden biri, zorluk çekenlere yardım etmek ve hâlâ anlayamamış olanlara destek olmaktır. Hepimiz farklı hızlarda ilerliyoruz ve bu değişimi farklı şekillerde karşılıyoruz. Geride kaldığınızı hissetmek, kolayca yaşanabilen bir durumdur.

Deneyimli mühendisler, mentor olun. Takılı kalan kişileri bulun ve onlara yardım edin. AI geliştirme iş akışını zaten anladığınızda, bunu başkalarıyla paylaşın; bu hiçbir değerli gizli bilgi değildir. Teknik liderler, yazılım mühendisliğinin şirketinizdeki yönünü yönlendirmeye katılmak zorundasınız. Yazılım kalitesi veya yazılım tasarımı konusunda endişeliyseniz, bunun için sesinizi yükseltmelisiniz. Bu görevi yapacak kişiler sizsiniz; patronlarınız muhtemelen yapmayacaktır.

Eğer geliştirici ekosistemini canlı bir ekosistem olarak hayal edersek, her ağacın her dalındaki her yaprağı, özel bir yaşam biçimi gibi dikkatle gözlemlemeye alışkınız. Ancak çok geçmeden, tek bir ağaç değil, tüm ormanı yönetmeniz gerekecek. Ve bir ormanı, tek bir ağacı izleyerek yönetemazsınız; ormanı bir ekosistem olarak görmelisiniz.

Sistemik değişimlerin bir özelliği, her yerde ve her şeyde aynı anda gerçekleşmeleridir; bu kadar büyük olurlar ki, hiçbir şeyi tutamıyormuş gibi hissettirirler. Şu anda, her hafta gelen değişim dalgalarında ayaklarınızı tutmanızı sağlayabilecek hiçbir şey olmadığını düşünebilirsiniz. Ancak tam olarak şimdi keşfettiğimiz gibi, bir sistemde her şey birbirine bağlıdır ve küçük eylemler büyük sonuçlar doğurabilir.

Yüzeyde nasıl görünürse görünsün, AI dönüşümü yalnızca şirket liderlerine ait bir alan değildir. Bu kritik anında, bir一线 yazılım mühendisi olarak, yazılım mühendisliğinin nereye doğru ilerleyeceğini belirleme merkezinde bulunuyorsunuz. Araçlardan iş akışlarına, mühendislik uygulamalarından mühendislik kültürine kadar, işleyen sistemi anlayabiliyorsanız, kaldıraç noktalarını bulabilirsiniz. Kendi kendinize sahip olduğunuz otonomi, düşündüğünüzden daha fazladır; bu otonomiyi, organizasyonunuz, ekibiniz ve kendiniz için geleceğinizi şekillendirmek için kullanın.