Connect with us

Düşünce Liderleri

AI Kod Yazıyor, Ancak Altyapınız Takip Edebiliyor mu?

mm

Yazılım mühendisliği tarihindeki en garip dönüşümlerden birini yaşıyoruz. Onlarca yıl boyunca determinizm hedeflenirdi; her zaman aynı şekilde davranan sistemler oluşturulmaya çalışılırdı. Şimdi ise bu temel üzerine olasılıksal AI ajanlarını katlıyoruz ve kodları alarm verici bir ölçekte ve hızda üretiyoruz. Ve dürüst olmak gerekirse? Altyapımızın çoğu buna göre inşa edilmedi.

Yıllarca DevOps araçları üzerinde çalıştım, araştırmalara ortak oldum ve mühendislik ekiplerinin en yüksek performansına ulaşmalarına yardımcı oldum. Şimdi AI ile sürülen geliştirme ile neler olduğunu görüyorum ve bu sadece bir evrim değil. Mevcut iş akışlarımızdaki her çatlak ortaya çıkıyor.

Sorun Zaten Burada

2025 GitClear çalışması neredeyse %7’sinin AI tarafından üretilen kod içerdiğini buldu. Daha önceki analizleri 153 milyon satır değişen kod ortaya çıkardı: “kod değişimi”—iki hafta içinde yeniden yazılmış veya silinmiş kod—2024’te AI öncesi referanslara kıyasla iki katına çıktı.

Güvenlik etkileri aynı derecede sert. Son analiz 80 seçilmiş kodlama görevi üzerinden 100’den fazla büyük dil modelini inceledi ve AI tarafından üretilen kodun %45’inde güvenlik açıkları ortaya çıkardı. Gerçek dünya etkisi? Bir olan beş CISO artık AI tarafından üretilen kodun doğrudan neden olduğu büyük olayları rapor ediyor.

Hız kazanımları gerçek, ancak istikrar maliyetleri de öyle.

Amplifikasyon Etkisi

Öğrendiğim bir şey var: AI her şeyi amplifiye ediyor. İyi uygulamalarınız varsa, AI onları daha iyi ve daha hızlı hale getirir. İşlemleriniz karışıksa, AI bu karışıklığı da artırır. Bu, DORA‘nın yıllık DevOps raporlarında yıl yıl ortaya çıkan bir modele benzer: daha az değişken, daha iyi sonuçlar anlamına gelir. Başarılı ekipler daha az işletim sistemi, daha az programlama dili, daha az şey yapma yolu üzerinde standartlaşıyorlar. Karmaşıklığı kasıtlı olarak azaltıyorlar.

AI ajanları aynı modeli takip ediyor. Onlara tutarlı bir ortam verin, her geliştiricinin makinesinde Python aynı versiyonu ifade etsin, bağımlılıklar kilitlensin ve takip edilsin, ve onlar mükemmel şekilde çalışırlar. Onları 17 farklı yapılandırma ile baş başa bırakın, her biri ince farklılıklarla, ve siz environmental tuhaflıkları çözmek yerine gerçek sorunları çözmek için token yakıyorsunuz.

Determinizm Paradoksu

Bu, ilginç bir gerilimi yaratıyor. Yıllarca bilgisayar bilimi determinizmi en büyük hedef olarak takip etti. Şimdi ise olasılıksal iş yükleri, AI modelleri—ki literal olarak aynı çıktıyı iki kez garanti edemez—öngörülebilirlik için tasarlanmış sistemlerin üzerine çalıştırıyoruz.

Cevabım? Yığının mümkün olduğunca çok kısmını deterministik tutun. Altyapınızın %80’ini deterministik seviyede tutabilirseniz, AI ajanlarınız daha az değişkeni yönetmek zorunda kalır. “Bu bağımlılık neden kurulmadı?” veya “Bu derleme komutunu tekrar denerim” gibi şeylerle uğraşmıyorlardır. Size yaptırmak istediğiniz gerçek işi yapıyorlar.

Düşünün: Bir ajan bir şeyi derlemeye çalıştığında ve yerel bağlamalar ImageMagick kurulmadığı için başarısız olursa, bu token-pahalı bir tur anlamına gelir. Ortamınız zaten her şeye dahilse (derleyiciler, kütüphaneler, tam bağımlılık ağacı libc’ye kadar), ajan sadece çalışır. Hiçbir hata ayıklama, hiçbir deneme yanılma, sadece ilerleme.

Özellik ve Doğrulama Anahtardır

Açık olan şey, AI ile sürülen geliştirmenin bizi iki tarihi olarak düşük değerli beceri hakkında daha sert düşünmeye zorladığıdır: özellik ve doğrulama. Ne inşa ettiğinizi net bir şekilde ifade etmeniz ve elde ettiğinizi doğrulamak için güçlü yollarınız olmalıdır.

İlginç bir şey fark ettim: ürün yönetimi veya ürün mühendisliği geçmişine sahip olanlar, şu anda AI ajanları ile daha başarılı oluyorlar. Zaten gereksinimler, başarı kriterleri ve ticaretler hakkında düşünmeye alışkınlar. “Neden bu seçimi yaptın?” sorusunu sormak ve nedenlerine göre ayarlamak konusunda rahatlar.

Doğrulama, şeyin gerçekten doğru olup olmadığını bilmek, her zaman yazılım mühendisliğinin en zor problemi oldu. QA on yıllarca suçlu olarak düşük değerli görüldü, ancak bu en zorlu kısım: yazılımın gerçek kullanıcı ihtiyacını çözüp çözmediğini belirlemek. AI bunu çözmez. Aslında, deterministik gereksinimlere karşı olasılıksal çıktıları doğrulamak daha kritik hale gelir.

Güven, Ancak Doğrula (Ve Kontrol Et)

Kabul etmeye başladığım bir görüş var: AI tarafından üretilen kodu, aksi ispatlanana kadar düşmanca olarak varsaymalıyız. AI’nin kötü niyetli olmadığından değil, sadece bilmediğimizden. AI ajanları günde binlerce satır kod ürettikleri için her satırı denetleyemeyiz.

Bu, kontrol noktalarını değiştirmeyi gerektirir. Geliştirme zamanında her şeyi kapayamıyorsak, üretim zamanında daha güçlü kontrollere ihtiyacımız var. Operatörler, SRE’ler, platform ekipleri, üretimden sorumlu olan herkes, ne çalıştığını, tam bağımlılık izlemesini ve her bir sanat eseri için net bir kökeni görebilmelidir.

Bu, yeniden üretilebilirliğin neden esas olduğu yer burası. Yerel olarak test ettiğiniz ve hiçbir şeyin değişmediği aynı girdileri, aynı çıktıları ve aynı bağımlılık kapanmasını çalıştırdığınız bir sanat eseri için matematiksel olarak ispatlayabilirsiniz. İşte o zaman akıllıca kararlar alabilirsiniz. Belki CI’de birimler testlerini yeniden çalıştırmanıza gerek yok, çünkü zaten yerel olarak çalıştırdınız ve hiçbir şey değişmedi. Belki test kapsamını kod değişikliklerine map edebilir ve alakasız test süitlerini atlayabilirsiniz.

Sonraki Nedir

Bir dönemeç noktasındayız. İyi uygulamalara sahip olan ekipler, AI ile büyük verimlilik kazanımları görüyor. Çabalayan ekipler ise şimdi daha hızlı çabalıyorlar.

AI ile sürülen geliştirmeyi güçlendirerek altyapı, yeniden üretilebilirlik için temelden inşa edilmelidir. Sonradan tarama araçları ve denetimlerle değil, geliştiricilerin çalışmaya başladığı ilk günden itibaren nasıl çalıştıklarına göre inşa edilmelidir. Geliştirme ortamınız Mac ve Linux arasında aynıysa, her bağımlılık izlenip kilitlenirse ve her bir sanat eseri için net bir kökeniniz varsa, AI ajanları kaos yaratıcıları yerine güç çarpanları haline gelir.

AI çağındaki ekiplere en büyük tavsiyem:

  • Ruthless standartlaştırma. Daha az değişken, daha yüksek performansla ilişkilendirilir. Teknoloji yığınızı kilitleyin, tüm platformlar boyunca tutarlı ortamları zorlayın ve AI’nin büyüteceği yapılandırma kaymasını ortadan kaldırın. Python sürümü uyuşmazlıkları şimdi sorunlara neden oluyorsa, AI kodu büyük ölçekte ürettiğinde 10 kat daha fazla sorun çıkarır.

  • Doğrulamayı iş akışınıza entegre edin, sonuna değil. AI kodu insanların gözden geçireceğinden daha hızlı ürettiğinde, yalnızca manuel kod gözden geçirmesine güvenemezsiniz. Kodun sadece çalıştığını değil, gerçek gereksinimi çözdüğünü doğrulayan otomatik testleri uygulayın. CI/CD pipenizin üretim dağıtımları için güçlü kapıları olan güvenlik ağını yapın.

  • Yeniden üretilebilirliği altyapı olarak yatırım yapın. Çevre tutarlılığını birinci sınıf altyapı endişesi olarak tedavi edin. Yerel ortamınız, CI ortamınız ve üretim ortamınızın aynı olduğunu matematiksel olarak ispatlayabilirsiniz. Bu, “çalışıyor” sorunlarının tüm bir sınıfını ortadan kaldırır. Bu deterministik temel, olasılıksal AI iş yüklerini güvenle üzerine katmanlara ayırmanıza olanak tanır.

Soru, AI’nin çoğumuzun kodunu yazıp yazmayacağı değil. Zaten birçok ekibin kodunu yazıyor. Soru, altyapımızın takip edip edemeyeceği.

Michael Stahnke, 15+ yıldır geliştirme ve operasyonel araç geliştirme alanında çalışmış, deneyimli bir mühendislik yöneticisidir ve burada Puppet'in DevOps Raporlarının yazarı ve araştırmacısı olarak da görev yapmıştır.

Michael şu anda Flox'ta Mühendislik Başkan Yardımcısı olarak görev yapmaktadır. Daha önce CircleCI ve Puppet'te üst düzey mühendislik liderliği görevlerinde bulunmuş ve mühendislik ekiplerini 5 kat veya daha fazla büyütmüştür. Yüksek performanslı ekipler, organizasyonlar oluşturmak ve mühendislik etkinliğini araştırmak yanı sıra paketleme ve sürüm sistemleri üzerinde çalışmaya zaman ayırmıştır. 2007 yılından bu yana DevOps ve Otomasyon etkinliklerinde konuşmacı olarak yer almaktadır. Extra Packages for Enterprise Linux (EPEL) paket deposunu kurmuş ve 2005 yılında OpenSSH hakkında bir kitap yazmıştır.