Bu yazı, kısıtlar, davranışsal determinizm ve Formal Spec-Driven Development üzerine iki bölümlük serinin ikinci yazısıdır. İlk bölümde yapay zekânın olasılıksal doğasını ortadan kaldırmadan, kabul edilebilir davranış uzayını matematiksel ve yapısal kısıtlarla daraltarak determinizme yaklaştırıp yaklaştıramayacağımızı ele aldım. Bu bölümde ise aynı fikrin doğal devamına geçiyorum: spesifikasyonun yalnızca rehber olmaktan çıkıp programın kabul edilme koşulu haline gelmesi.
Bu yazı, kısıtlar, davranışsal determinizm ve Formal Spec-Driven Development üzerine iki bölümlük serinin ilk yazısıdır. Bu bölümde yapay zekânın olasılıksal doğasını ortadan kaldırmadan, kabul edilebilir davranış uzayını matematiksel ve yapısal kısıtlarla daraltarak determinizme yaklaştırıp yaklaştıramayacağımızı ele alıyorum. İkinci bölümde ise aynı fikrin doğal devamına geçiyorum: spesifikasyonun yalnızca rehber olmaktan çıkıp programın kabul edilme koşulu haline gelmesi.
Üretken yapay zekâ ile yazılım geliştirirken karşılaştığımız temel çelişkilerden biri şu: Giderek daha fazla kodu doğası gereği olasılıksal sistemlere ürettirirken, ortaya çıkan yazılımdan mümkün olduğunca kesin, tekrarlanabilir ve güvenilir davranmasını bekliyoruz. Büyük dil modeli aynı probleme farklı zamanlarda farklı çözümler önerebilir; aynı çözümü üretmesi halinde bile bu çözümün doğru olduğunu üretim sürecinin kendisi garanti etmez. Buna karşılık yazılımın özellikle finans, güvenlik, üretim, altyapı veya fiziksel sistemlerle etkileşime girdiği alanlarda “büyük ihtimalle doğru” olması yeterli değildir.
Yapay zekânın yazılım geliştirmeye etkisini tartışırken konu çoğu zaman aynı eksene sıkışıyor: Bir geliştirici AI destekli araçlarla ne kadar daha hızlı kod yazabilir, aynı ekip daha fazla işi tamamlayabilir mi, yazılım geliştirme maliyetleri ne kadar düşebilir? Bunların hepsi bugün için anlamlı sorular, ancak birkaç yıl sonrasını düşündüğümüzde asıl dönüşümün burada olmayacağı giderek daha belirgin hale geliyor. Eğer yazılım üretmenin teknik maliyeti dramatik biçimde düşüyorsa, asıl kıt kaynak artık kod yazma kapasitesi değil; doğru problemi seçmek, neyin inşa edilmesi gerektiğini tarif etmek, ortaya çıkan sistemi yönlendirmek ve ona güvenebilmek oluyor.
Bugün kullandığımız AI ajanların önemli bir bölümü düşündüğümüz kadar “ajan tabanlı” değil. Repository’yi okuyabiliyor, kod üretebiliyor, dosyaları değiştirebiliyor, test çalıştırabiliyor ve bazı durumlarda pull request açabiliyorlar; fakat production sistemlerinin gerçek durumunu (state) değiştirebilecekleri noktaya geldiğimizde etraflarına oldukça kalın güvenlik duvarları örüyoruz. Bunun iyi bir nedeni var. Bir ajanın yanlış bir SQL sorgusu önermesi ile o sorguyu production veritabanında çalıştırması arasında yalnızca bir yetki farkı yok; iki durumda sahip olduğumuz risk modeli bütünüyle farklı.
Yazılım dünyasında uzun yıllardır oldukça doğal kabul ettiğimiz bir kariyer yolu vardı. Üniversiteden mezun olur, junior geliştirici olarak bir ekibe katılır, küçük hataları düzeltir, nispeten basit geliştirmeler yapar, code review’larda hatalarınızı görür, daha deneyimli geliştiricilerin kodlarını okur ve zaman içinde daha karmaşık problemlerin sorumluluğunu almaya başlardınız. Bu süreç yalnızca kod yazmayı öğretmezdi; bir production sisteminin neden belirli şekilde tasarlandığını, bir teknik kararın hangi sonuçları doğurabileceğini, ne zaman soru sormanız gerektiğini, ne zaman araştırmaya devam etmenin doğru olduğunu ve bazen de çalışan bir çözümün neden iyi bir çözüm olmadığını anlamanızı sağlardı.