Kodlamada Yapay Zeka: Neden Bazı Yazılımcılar Hâlâ El Yöntemiyle Çalışmayı Tercih Ediyor?

Teknoloji dünyası yapay zekaya karşı hippi bir tutkunluk yaşıyor. Her yeni ürün "geliştirmeyi devrim yapacak" diye duyuruluyor, konferanslar verimlilik mucizesinden bahsediyor ve girişim sunumlarında mutlaka "LLM tarafından güçlendirilmiş" ifadesi geçiyor.

Cazip geliyor, ama herkes için olmayabiliyor.

Artan sayıda yazılımcı yapay zeka rüzgârından bir adım geri atıp temel bir soruyu sormaya başladı: Buna gerçekten ihtiyacımız var mı? Bazı yetenekli mühendislerin neden bu trendin dışında kalmayı seçtiğini ve bu kuşkuculuk bize yazılım geliştirme araçlarını nasıl değerlendirmemiz gerektiğini anlatabiliyor.

Abonelik Modeli Gerçekleri

Başlayalım somut bir noktadan: para.

LLM tabanlı geliştirme araçlarının çoğu aylık veya yıllık ödeme istiyorsa. Karşılığında IDE'nize entegre yapay zeka yardımı alıyorsunuz. Makul geliyor, değil mi? Peki bu, belki de işinizin sadece belli kısımlarında fayda sağlayan bir aracı sürekli tutmak demek oluyor.

Bu gerçeklik birçok yazılımcıyı tekrar eski metin düzenleyicilerine çekiyor. Hesap çok basit: eğer yapay zeka asistanını kodlama işinizin yüzde 10'unda kullanıyorsanız—standart kod şablonları ve hızlı dokümantasyon gibi—aylık ödeme gerçekten değer mi? Aynı işleri yapabilecek, onsuz önceki yıllardır var olan ücretsiz ya da bir kereye mahsus ödenen araçlar var.

Yazılım dünyasını uzun zamandır izleyen eski jenerasyon yazılımcılarının birikimi göz önüne alınmalı. Bilgisayar dilsiz kodlama platformlarının "programlamayı tamamen ortadan kaldıracak" sözünü verdiklerini gördüler. Düşük kod çözümleri pazar payı almış, ama sonunda kendi başlarına teknik borç yaratmışlar. Her "devrim niteliğinde" araç biraz verimlilik getirmiş, ama hiçbiri vaatlerinin oranında olmamış.

Bu şüphecilik yapay zekanın faydasını reddetmek değil. Karmaşıklığı büyük ölçekte çözdüğünü iddia eden bir aracın, aslında yanlış problemi çözmüş olabileceğini kabul etmek demek.

Karmaşıklık Meselesi: Fiyasko mı, Zorunluluk mu?

İşte burada felsefe başlıyor—ve daha ilginç hale geliyor.

IBM'in efsanevi proje yöneticisi Fred Brooks, System/360 mimarisini tasarlayana sonra "Gümüş Kurşun Yok" adlı bir makale yazmıştı. Yapay zeka araçları düşünen her mühendis bunu okumalı. Temel argümanı: bütün karmaşıklıklar eşit değildir.

Tesadüfi karmaşıklık var—kodu yazarken çıkan sürtüşme ve ek iş. Bellek yönetimi. Standart kod bloğu. API bakma. Programlamayı sıkıcı, ama entelektüel olarak zor kılmayan şeyler.

Kaçınılmaz karmaşıklık ise asıl problemi çözmek zorluğu. İş ihtiyaçlarını anlamak. Mimari kararlar almak. Dağıtık sistemlerde durumu yönetmek. Bileşenler arasında beklenmedik etkileşimleri hata ayıklamak. Assembly yazarken olsun, Python yazarken olsun, bu zorluklar yine de vardır.

Modern programlama dilleri ve çatıları zaten tesadüfi karmaşıklığa karşı büyük ilerleme sağlamışlar. Artık makine kodu yazmıyoruz. Quicksort'u yeniden yazıp durmuyoruz. Paket yöneticilerimiz, linterlarımız ve test çatılarımız sıkıcı işlerin bütün kategorilerini otomatik hallediyorlar.

İşte zor gerçek: yapay zeka kodlama asistanları esas olarak zaten büyük ölçüde çözdüğümüz tesadüfi karmaşıklıkla uğraşıyor.

Bir yapay zeka modelinden REST API uç noktası ya da birim testi yazmasını istediğinde, zaten iyi bilinmiş ve belgelenmiş bir problemi çözmesini istiyorsunuz. Günümüz yazılım geliştirmesinin gerçek darboğazı yazı hızı ya da söz dizimi hatırlama değil. Neyin yapılacağını anlamak ve doğru mimari seçimler yapmak.

Soyutlama Kulesinin Tuzağı

Bir yazılımcı olarak üzerinde durduğunuz yığını düşün. Python'da yazdığın her satır kod milyonlarca işlemi birden fazla sistem içinde tetikleyebilir. Soyutlama katmanlarının üstünde duruyorsun: yüksek seviye diller derlenmiş bytecode'a, çalışma zamanı yorumlayıcıları, işletim sistemi çağrıları, CPU komutları, silikon içindeki kuantum etkileri.

Yapay zeka kodlama düşünün bu kulenin üzerine yeni bir katman eklemek—programlama eylemini tamamen otomatikleştirmek. Yapay zeka sistemleri teoride görevler verilebilir ve kendi başlarına uygulayabilirdi, programcıyı denklemden çıkararak.

Ama her ek soyutlama katmanı yeni hata modları yaratır. Kule derininde bir şey ters giderse, altında neler olup bittiğini anlaman lazım. En etkili hata ayıklama çoğu zaman nerede sorunun çıktığını anlamak için kulenin alt seviyelerine inmek gerektirir.

Senin yazmadığın kodu yapay zeka üretme, amaçlanla gerçek uygulama arasına yeni bir soyutlama katmanı koymak demek. Hatalar ortaya çıktığında (ve çıkacak), yapay zekanın ne yaptığını ters mühendislik yaparak problemi anlamalısın. Bu verimlilik kazancı değil. Otomasyon görünümlü bakım yükü.

Deneyim Antidotu

Bu konunun rahatsız edici bir kuşaksal boyutu var.

Teknoloji endüstrisi son yirmi yılda genci ve hızlılığı kutlarken, beş yıllık deneyimi "senior seviye" saymışlar. Bu arada gerçekten onlarca yıl kod yazan yazılımcılar sadece kod yazmanın ötesinde kurumsal bilgi taşıyorlar. Başarısızlıkları görmüşler. Riski anlarlar. Geçen "devrim niteliğindeki" gelişmenin tam olmadığını hatırlarlar.

Bütün bunlar genç yazılımcıları ya da yapay zeka heyecanını küçümsemek değil. Ama birden fazla teknoloji döngüsünde kod yazmış birisinin perspektifinin gerçek değeri var. Java, Ruby, Node.js, blockchain, serverless computing hype döngülerini yaşayan biri, bir sonraki büyük şeye karşı sağlıklı bir kuşkuculuk geliştiriyor.

Bu kuşkuculuk ilerlemeye karşı değil. Hype'a karşı.

Sonuç

Yapay zeka kodlama asistanlarına kuşkuyla yaklaşan yazılımcısınız, bu aslında sağlıklı bir düşüncedir. Araçların gerçekten nerelerde değer kattığını ve nerelerde komplekslik eklediğini sorguladığın anlamı. Bu içgüdüye güven. Sıkıcı işlerde yapay zeka asistanlarını kullan. Gerçek probleme yakın kalman gereken yerlerde atla.

Yazılım geliştirmenin geleceği yazılımcıları denklemden çıkarmak değil. Sadece insanların iyi yapabildiği işlerden distraksiyonları çıkarmak.