Yapay zeka geldi ve yazılımcılık bitti, öyle değil mi?

Bu sorunun cevabını bulmak için tarihin neden tekerrürden ibaret olduğuna bakmamız gerekiyor.

Öncelikle burada yazılımdan bahsederken enterprise-level, yani karmaşık yapı ve mimariye sahip kurumsal yazılımları kastediyorum.

Bu tür yazılımları geliştirmek, yapay zeka devrinden önce de oldukça zor bir girişimdi.

Yapay zeka ile artık bunun da çocuk oyuncağı haline geldiğini düşünüyoruz. Ama durum hiç de öyle değil.

Eski zorluklar yapay zeka ile ortadan kalkmadı. Sadece kılık değiştirdi.

Bunun neden böyle olduğunu somut bir örnekle açıklayayım.

2000’lerin başında EJB’lerle yazılım geliştirirken en büyük problemlerimden biri uygulamayı lokal ortamda çalışır hale getirmekti.

Lokal bir deployment onlarca dakika sürebiliyordu. Sadece debug yapabilmek için bile günümün yarısını EJB paketlerini hazırlamak ve lokal deployment yapmakla geçirdiğimi hatırlıyorum.

Sonraları Spring çatısı yaygınlaştı ve dependency injection, daha hafif bileşen modelleri ve test edilebilirlik gibi yaklaşımlarla geliştirme süreçlerini önemli ölçüde kolaylaştırdı.

Bu, bazı problemleri çözdü. Fakat zamanla başka karmaşıklıklar ortaya çıktı.

Web servisleri, REST tabanlı sistemler, mikroservis mimarileri ve dağıtık uygulamalar derken karmaşıklık bu kez uygulamanın kendi içinden çıkarak uygulamalar arasındaki ilişkilere taşındı.

Paralelinde tasarım prensipleri, SOLID, Clean Code, Software Craftsmanship ve benzeri yaklaşımlar yazılımın sürdürülebilirliğini sağlamak için giderek daha fazla önem kazandı.

Bütün bu gelişmelerin ortak noktalarından biri, yazılım karmaşıklığına hakim olabilme çabasıydı.

Fakat yazılımcılar kurumsal projelerdeki karmaşıklığa hiçbir zaman tam anlamıyla hakim olamadılar.

Bunu özellikle duvara toslamış, geliştirilmesi artık neredeyse imkansız hale gelmiş ve karmaşıklık seviyesi insan zihninin kavrama kapasitesini zorlayan projelerde gördük.

Şimdi yapay zeka devrindeyiz.

Kurumsal yazılım projeleri açısından ne değişti?

Karmaşıklık problemi açısından bakarsak, özünde hiçbir şey!

Greenfield olarak başladığınız bir kurumsal projede yapay zeka ile inanılmaz hızlı ilerleyebilirsiniz.

Ama er ya da geç EJB döneminde ve sonrasında gelen teknolojilerde karşılaştığımız, sizi yavaşlatan veya tamamen durduran engellerin benzerleriyle yeniden karşılaşacaksınız.

Bunu yine somut bir örnekle açıklayayım.

Şu anda üzerinde çalıştığım platform 40’a yakın Git projesinden oluşuyor. Bunların tamamı birbirleriyle entegre çalışarak tek bir platform meydana getiriyor.

Platformun parçalarını oluştururken inanılmaz hızlı ilerledim.

Ancak şimdilerde bu parçaların birbirleriyle entegrasyonu söz konusu ve başlangıçtaki 10x–20x geliştirme hızım yeniden standart 1x seviyesine düşmüş durumda.

Zamanımın büyük bir kısmı, loop engineering yapmama rağmen bloke olan loop’ları çözmekle ve uzun süren GPT analizleriyle geçiyor.

Peki beni yavaşlatan şeyler neler?

1. Genişleyen kod tabanı

Artık GPT ve Opus çok daha fazla kodu okumak, analiz etmek ve mevcut yapıyla uyumlu implementasyonlar geliştirmek zorunda.

Tek bir uygulamada birkaç dosyayı değiştirmekle, onlarca uygulamanın oluşturduğu bir ekosistemde değişiklik yapmak aynı şey değil.

Bir yerde yaptığınız değişiklik başka bir yerde beklenmedik sonuçlar doğurabiliyor.

2. Büyüyen test maliyeti

Sadece uygulamanın kod tabanı genişlemiyor. Test kodları da uygulama kodlarıyla birlikte büyüyor.

Üstelik entegrasyonlar arttıkça yalnızca unit testler değil, integration ve end-to-end testler de giderek daha önemli hale geliyor.

Yapay zekanın yaptığı her değişikliğin mevcut sistemi bozmadığından emin olmak zorundasınız.

Başlangıçta birkaç saniyede tamamlanan test süreçleri zamanla dakikalar, hatta çok daha uzun süreler almaya başlıyor.

Yapay zekanın implementasyonda kazandırdığı hız, yaptığı işin doğrulanması sırasında tüketiliyor.

3. Platform bileşenlerinin birbirlerine olan bağımlılıkları

Tek başına çalışan bir uygulama geliştirmek nispeten kolay.

Ancak birbirine bağımlı onlarca uygulamadan oluşan bir platform geliştirdiğinizde artık sadece kod yazmıyorsunuz.

Uygulamalar arasındaki sözleşmeleri, veri akışlarını, iş süreçlerini, hata senaryolarını ve sistemin bütünlüğünü yönetmek zorundasınız.

Bir uygulamanın doğru çalışması, platformun doğru çalıştığı anlamına gelmiyor.

4. Yetersiz tanımlanmış gereksinimler

Loop engineering ile yapay zekaya otonom yazılım geliştirtmek mümkün.

Ancak bunun bir ön koşulu var:

Gereksinimlerin, kabul kriterlerinin ve sistem invariantlarının yeterince açık tanımlanmış olması.

Aksi takdirde loop’lar sık sık bloke oluyor.

Yapay zeka eksik bırakılan iş kurallarını kendi varsayımlarıyla tamamlamaya çalışıyor. Bu varsayımlar platformun diğer parçalarıyla çeliştiğinde ise yeni sorunlar ortaya çıkıyor.

Bu noktada yapay zekanın önündeki engel artık kod yazamaması değil, neyi neden yapması gerektiğinin yeterince tanımlanmamış olması.

5. Değişikliklerin etki alanının büyümesi

Başlangıçta bir değişikliğin etkisi birkaç sınıfla sınırlıyken, platform büyüdükçe aynı değişiklik birden fazla servisi, veri modelini, API sözleşmesini ve iş sürecini etkileyebiliyor.

Dolayısıyla artık mesele değişikliği gerçekleştirmek değil, değişikliğin bütün sistem üzerindeki etkisini doğru analiz edebilmek.

Bu da bizi yeniden yazılım mimarisinin en eski problemlerinden birine getiriyor:

Karmaşıklığı nasıl kontrol altında tutacağız?

Burada tarih tekerrür ediyor.

EJB döneminde deployment süreleriyle mücadele ediyorduk.

Mikroservis döneminde dağıtık sistemlerin karmaşıklığıyla mücadele ettik.

Şimdi ise yapay zeka ajanlarının ürettiği kodun, testlerin, bağımlılıkların ve iş süreçlerinin oluşturduğu karmaşıklıkla mücadele ediyoruz.

Araçlar değişti.

Kod üretme kapasitesi olağanüstü arttı.

Ama sistemin bütününe hakim olma problemi ortadan kalkmadı.

Hatta yapay zekanın çok kısa sürede çok büyük miktarda kod üretebilmesi, bu problemin çok daha erken ortaya çıkmasına neden olabiliyor.

Eskiden aylar sonra karşılaştığımız karmaşıklık duvarına artık haftalar içerisinde çarpabiliyoruz.

Buradan çıkardığım önemli bir sonuç var.

Yapay zeka çağında yazılım geliştirmenin darboğazı implementasyondan analize, entegrasyona ve doğrulamaya kayıyor.

Kod üretmek giderek ucuzlarken, üretilen kodun doğru iş süreçlerini gerçekleştirdiğinden ve mevcut ekosistemi bozmadığından emin olmak giderek daha maliyetli hale geliyor.

Bu nedenle geleceğin yazılım mühendisliği yalnızca yapay zekaya daha iyi prompt yazabilmekten ibaret olmayacak.

Gereksinim mühendisliği, domain modelleme, süreç analizi, sistem mimarisi, kabul kriterleri, invariantlar ve doğrulama mekanizmaları çok daha belirleyici hale gelecek.

Hatta önümüzdeki dönemde yazılım mühendisliğinin en önemli çalışma alanlarından birinin, yapay zeka ajanlarının ürettiği yazılımın karmaşıklığını yine yapay zeka yardımıyla kontrol altında tutabilecek yöntemler geliştirmek olacağını düşünüyorum.

Belki de yeni bir yazılım mühendisliği paradigmasının başlangıcındayız, cünkü bugüne kadar geliştirdiğimiz yöntemlerin büyük bölümü, kodu insanların yazdığı ve insanların okuyup anlamak zorunda olduğu bir dünya için tasarlandı.

Şimdi kodu büyük ölçüde makinelerin ürettiği, analiz ettiği ve test ettiği bir dünyaya geçiyoruz.

Bu yeni dünyada aynı mimari ve geliştirme prensiplerinin yeterli olup olmayacağını henüz bilmiyoruz.

Ancak bildiğim bir şey var:

Yazılım mühendisliği bitmedi. Yazılım mühendisliğinin çözmek zorunda olduğu problemler seviye değiştirdi.

Tarih bize bir şey öğrettiyse, o da şudur:

Her teknolojik devrim bazı problemleri çözerken, çözülmesi gereken yeni ve daha karmaşık problemler ortaya çıkarır.

Yapay zeka devrinin de bundan farklı olacağını düşünmek için henüz bir neden göremiyorum.