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.

Yapay zeka ile bir proje geliştirirken ilk zamanlarda çok hızlı ilerleyeceksiniz.

Eğer kabul kriterlerini ve sistem invariantlarını doğru tanımladıysanız, bunların karşılığı olan çok sayıda E2E ve diğer otomatik testiniz olacak.

Bu durum zamanla sizi yavaşlatmaya başlayacak, cünkü yapay zeka, yaptığı her değişikliğin sağlamasını yapmak için testleri çalıştırmak zorunda kalacak.

Proje büyüdükçe test sayısı artacak, sistemin parçaları arasındaki bağımlılıklar çoğalacak ve en küçük değişikliğin bile mevcut işleyişi bozmadığından emin olmak giderek daha fazla zaman alacak.

Başlangıçta zamanının büyük bölümünü implementasyona ayıran yapay zeka, ilerleyen aşamalarda zamanının önemli bir kısmını doğrulamaya ayırmaya başlayacak.

İşte bu noktada yeni bir darboğazla karşılaşacaksınız.

Artık sorun yapay zekanın ne kadar hızlı kod yazabildiği değil, yazdığı kodun mevcut sistemin bütünlüğünü bozmadan çalıştığını ne kadar hızlı doğrulayabildiği olacak.

Bu yüzden test mimarisi, testlerin paralel çalıştırılması, değişiklikten etkilenen testlerin belirlenmesi ve doğrulama süreçlerinin optimizasyonu giderek daha fazla önem kazanacak.

Kod yazmak ucuzlarken, kodun doğruluğundan emin olmanın maliyeti artıyor.

Ve bence bundan sonraki asıl mühendislik mücadelesi burada yaşanacak.

Bilgi üretmek ile bilginin doğruluğunu sınamak aynı şey değildir. Bu yüzden buradaki epistemolojik ayrımı incelememiz gerekiyor.

Yapay zeka ne değildir?

Kesin bilgi kaynağı.

Bilgi söz konusu olduğunda yapay zeka nasıl kullanılmalıdır?

Bir sağlama ve sorgulama aracı olarak.

Yapay zekayı temel bilgi kaynağı olarak kabul ettiğinizde, gömleğinizin ilk düğmesini yanlış iliklemek gibi bir hata yapabilirsiniz.

İlk düğme yanlış iliklendiğinde, sonraki bütün düğmeleri kendi içinde tutarlı biçimde ilikleşeniz bile sonuç yanlış olacaktır.

Bilgi de böyledir.

Yanlış bir temel üzerine kurduğunuz düşünce sisteminin bütün çıkarımları mantıklı ve tutarlı görünebilir.

Hatta yapay zekaya yaptırdığınız sağlamalar bile doğru sonuçlar veriyor gibi görünebilir.

Ancak başlangıçtaki temel yanlışsa, üzerine inşa ettiğiniz bütün düşünce binası sallanır.

Tutarlılık, doğruluğun kanıtı değildir.

Yapay zekadan aldığınız cevapları değil, o cevapların dayandığı temelleri sorgulayın.

Küçük bir örnek vereyim.

Yeğenim ile müzik dersi sınavına çalışıyoruz. GPT’den notaların nerede olduğuna dair yardım istedik. Kaç sefer uğraşmasına rağmen değişik oktavlardaki notları porte üzerinde doğru yerlere yerleştiremedi. Ben dışardan referans bir nota düzeni bularak sağlamasını yapmak zorunda kaldım. Her defasında uyarmama rağmen, haklısın yanlış olmuş deyip, tekrar edip durdu. Ben eğer onun verdiği ilk sürümü doğru kabul etseydim, yeğenimin imtihandan aldığı notu siz düşünün. Sonunda GPT’yi kapatıp, klasik öğrenme yöntemleri ve kaynakları üzerinden devam ettik.

Dört yetişkin şahıs düşünün.

Birincisi yapay zeka araçları ile henüz temas etmedi.

İkinci şahıs ücretsiz yapay zeka araçları ile sadece laklak yapıyor, resim çizdiriyor.

Üçüncü şahıs ücretli yapay zeka araçlarından yararlanıyor ve günlük işlerini yapay zeka ajanları ile otomatize etmeye başlamış.

Dördüncü şahıs üçüncü şahsın yaptığı işlerin yanında yapay zeka araçları ile vibe coding yapıyor ve kendisi için çalışır uygulamalar geliştirmeye başlamış.

– Birinci şahıs: izleyici

– İkinci şahıs tüketici

– Üçüncü şahıs: operatör

– Dördüncü şahıs: üretici

Beşinci bir tip daha var: Sistem tasarımcısı

Beşinci şahıs yalnızca uygulama geliştirmiyor. Birbirine bağlı uygulamaları, ajanları ve iş süreçlerini bir araya getirerek otonom çalışan sistemler oluşturuyor. Gereksinimleri, süreçleri, istisnaları ve başarı kriterlerini tanımlıyor.

Siz hangisisiniz?

Yapay zeka çağında hangisi ayakta kalacak?

Yapay zeka ile standalone bir uygulama geliştirmek birkaç günlük bir çalışma gerektirebilir.

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

Aynı işi Prompt Engineering ile yapmaya kalkarsanız, birkaç günlük çalışma rahatlıkla bir haftalık tam zamanlı uğraşa dönüşebilir.

Loop Engineering ile her türlü uygulamanın otonom olarak geliştirilebileceğini düşünebilirsiniz. Ancak durum ne yazık ki öyle değil.

Eğer birbirine bağımlı birden fazla uygulama geliştiriyorsanız, işin içine süreçler de giriyor. Bu noktadan itibaren artık tek bir uygulama değil, bir ekosistem ya da platform geliştiriyorsunuz ve bu ekosistemin içindeki süreçlerin en ince ayrıntısına kadar tanımlanmış olması gerekiyor.

“Bunu istiyorum, hadi yap!” demek artık yeterli olmuyor.

Üstelik detaylı tanımlama da tek başına yeterli değil.

Karmaşık bir uygulama ekosisteminin birbirine bağımlı parçalarını oluşturmak, Loop Engineering kullansanız bile haftalar alabiliyor.

Gerekli analiz ve tasarım çalışmaları önceden yapılmadığında loop çok sık aralıklarla bloke oluyor ve sizin müdahale etmeniz gerekiyor. Bu da otonom geliştirme yaklaşımının en önemli avantajını, yani insan müdahalesini en aza indirme hedefini ortadan kaldırıyor.

Özetle:

Küçük uygulamalar (örneğin bir Todo App) geliştirmek için çok fazla mühendislik çalışmasına ihtiyacınız yok. Nasıl bir uygulama istediğinizi söylemeniz ve Vibe Coding yapmanız çoğu zaman yeterli.

Ancak karmaşık uygulama ekosistemlerinde bu çalışma tarzı sürdürülebilir değil.

Burada gerçek yazılım mühendisliği devreye girmek zorunda.

Gereksinim analizi, yazılım mimarisi, süreç modelleme, uygulamalar arası bağımlılıkların yönetimi ve entegrasyon mimarisinin oluşturulması ciddi tecrübe gerektiren işler.

Yapay zeka kod yazma problemini büyük ölçüde çözdü. Ancak neyin, neden, nasıl ve hangi sırayla geliştirilmesi gerektiği problemini ortadan kaldırmadı.

Hatta tam tersine, yazılım mühendisliğinin bu tarafını hiç olmadığı kadar önemli hale getirdi, cünkü otonom yazılım geliştirme, mühendisliğin ortadan kalkması değil, mühendisliğin kod yazımından önce yapılmasıdır.

Yeni bir projeye başladığınızda en büyük sorunlardan biri, projenin lokalde çalışan bir versiyonunu oluşturmaktır. Bunun için kodu, testleri ve dokümantasyonu okumanız, takıldığınız yerlerde çalışma arkadaşlarınıza danışmanız gerekir.

Bunların artık neden gerekli olmadığını kendi yaşadığım bir örnekle açıklayayım.

Altı ay önce Go ile bir Remote Device Management sistemi geliştirdim. Daha doğrusu ben değil, Opus geliştirdi. :)

Altı aydır dönüp bu projeyle hiç ilgilenmedim. Neler yaptığımı bile zar zor hatırlıyorum. Biraz dokümantasyon hazırlamışım. Onları okudum ve kabaca ne yapmam gerektiğine dair bir fikir oluştu. Ama bu bilgiler hala lokalde çalışan bir sistem kurmam için yeterli değildi.

GPT’ye sadece “kokalde çalışan bir sistem istiyorum” demem yeterli oldu.

Şu anda dashboard UI lokalde çalışıyor. Agent’ın derlenmesi ve Android üzerinde çalıştırılması aşamalarını da geçtik. Kısa bir süre sonra Android cihazının ekranına bağlanıp cihazı yönetebileceğim. Üstelik bütün bunları kod okumadan, testleri incelemeden, dokümantasyona gömülmeden ve kimseye soru sormadan yaptım.

Kısaca özetleyecek olursak:

İnsan unutuyor ama yapay zeka unutmuyor.

Daha doğrusu, insanın unuttuğu bilgiyi yapay zeka mevcut sistemden yeniden çıkarabiliyor. Artık bir projeye hakim olmak için önce bütün kodu anlamak zorunda değiliz. Ne yapmak istediğimizi bilmemiz yeterli olabiliyor.

Klasik yazılım geliştirme metotları ve araçları birer birer patlamaya başladı.

Anthropic, Git kullanımından kendi geliştirdiği Scion isimli kaynak kod yönetim sistemine geçmeye başlamış.

Neden?

Günde 30.000’den fazla merge yapan, on binlerce yapay zeka ajanının eş zamanlı çalıştığı bir ortamda Git artık ihtiyaçları karşılamakta zorlanıyor.

Aslında burada çok daha büyük bir dönüşüme şahit oluyoruz.

Bugün kullandığımız yazılım geliştirme araçlarının ve metotlarının neredeyse tamamı insanlar için tasarlandı.

Git, IDE, pull request, code review, sprint, Scrum…

Bunların hepsi insanların kod yazdığı, birbirlerinin kodlarını incelediği ve sınırlı bir üretim kapasitesine sahip olduğu bir dünyanın ürünleri.

Şimdi ise yazılımı insanlar değil, giderek daha fazla yapay zeka ajanları üretiyor.

İnsanlar için tasarlanmış araçlarla, insanlardan binlerce kat daha hızlı çalışabilen ajanları yönetmeye çalışıyoruz.

Doğal olarak bu araçlar ve yöntemler birer birer darboğaza dönüşmeye başlıyor.

Bence önümüzdeki dönemde yalnızca yazılım geliştirme yöntemlerinin değil, yazılım mühendisliğinin bütün araç ekosisteminin yeniden şekillendiğini göreceğiz, cünkü mesele artık mevcut araçları yapay zekaya uyarlamak değil.

Yapay zekanın çalışma biçimine uygun yeni bir yazılım mühendisliği inşa etmek.

Git bunun ilk örneklerinden biri. Sonuncusu olmayacak.

Benim anlamadığım bir şey var!

Yazılımcıların asıl görevi neydi?

Kod yazmak mı?

Hayır! Kod yazmak bir eylem, amaç değil. Amaç, bu eylem aracılığıyla bir ürün ortaya çıkarmak.

Yazılımcıların asıl görevi, istenilen ürünü geliştirmektir. Bundan daha merkezi bir görevleri hiçbir zaman olmadı.

Peki günümüz yazılımcıları yapay zeka ile gelen değişim karşısında neden bu kadar zorlanıyor?

Ürün geliştirmek hiçbir zaman bugünkü kadar kolay olmamıştı.

Buna sevinmemiz gerekmez mi?

Sorun şu ki yıllarca kullandığımız araçları mesleğimizin amacıyla karıştırdık.

Kod yazmayı o kadar merkeze koyduk ki kod yazmadan ürün geliştirilebileceği gerçeğini kabullenmekte zorlanıyoruz.

Oysa değişen şey mesleğimizin amacı değil, o amaca ulaşmak için kullandığımız yöntemler.

Artık mesele ne kadar iyi kod yazabildiğiniz değil, ne kadar iyi ürün geliştirebildiğiniz.

Bence yazılım mühendisliği tarihinde bundan daha heyecan verici bir dönem yaşanmadı.

Eskiden hata bulmak için kod içinde debug yapardık.

En son ne zaman debugger kullandığımı hatırlamıyorum.

Debug yapmak benim için hiçbir zaman iyi bir alışkanlık değildi, çünkü çoğu zaman sistemin nasıl çalıştığına dair zihinsel modeldeki eksikliklere işaret ederdi.

Yapay zeka ile birlikte debugging de bambaşka bir boyuta taşındı.

Artık kodun içinde breakpoint’ler koyup, değişkenlerin değerlerini inceleyerek hatanın kaynağını aramıyorum.

Gördüğüm hatayı yapay zekaya bildiriyorum. O da kodu analiz ediyor, hatanın kaynağını tespit ediyor ve gerekli düzeltmeleri yapıyor.

Benim rolüm ise yapılan düzeltmenin gerçekten problemi çözüp çözmediğini ve sistemin beklenen davranışlarını koruyup korumadığını doğrulamak.

Yani debugging ortadan kalkmadı. Sadece işi yapan değişti.

Eskiden hatanın nerede olduğunu bulmaya çalışırdık. Şimdi hatanın ne olduğunu doğru tarif etmeye çalışıyoruz.

Kod seviyesindeki debugging’den davranış seviyesindeki debugging’e geçiyoruz.

Otuz yıla yakın yazılımcı kariyerimde iki büyük kırılma yaşadım.

Bunlardan ilki imperatif programlamadan fonksiyonel programlamaya geçişti. Çok uzun süre imperatif kod yazmaya alışmış bir beyin, fonksiyonel programlamaya kolay adapte olamıyor. O dönemde çok zorlandığımı hatırlıyorum.

İkinci büyük kırılmayı ise üç sene önce yapay zeka ile tanıştığımda yaşadım. İlginç olan, bu sefer hiç zorlandığımı hatırlamıyorum.

Bunun nedenini düşündüm ve şöyle bir sonuca vardım:

İlk kırılmada düşünme biçimimi değiştirmek zorundaydım. İkinci kırılmada ise zaten sahip olduğum düşünme biçimini doğrudan kullanmaya başladım.

İmperatif programlamadan fonksiyonel programlamaya geçerken beynimi yeni bir programlama paradigmasına adapte etmek zorundaydım. Yıllarca edindiğim alışkanlıklar, yeni düşünme biçiminin önünde engel oluşturuyordu.

Yapay zekaya geçişte ise tam tersi bir durum yaşadım.

Artık algoritmaları adım adım ifade etmek zorunda değildim. Ne istediğimi, neden istediğimi, hangi koşulların sağlanması gerektiğini ve hangi sınırların aşılmaması gerektiğini anlatmam yeterliydi.

Aslında başka bir yazılımcıya iş verirken de böyle davranıyordum. Ona değişkenleri, döngüleri ve koşulları tarif etmiyordum. Problemi ve beklentilerimi anlatıyordum.

Yapay zeka ile de aynı şeyi yapmaya başladım.

Bir başka önemli nokta ise soyutlama seviyesi.

Otuz yıla yakın yazılım geliştirmiş biri olarak zaten uzun zamandır problemleri yalnızca kod seviyesinde düşünmüyordum. Mimari, gereksinimler, iş süreçleri ve sistem davranışları düşünce dünyamın önemli bir bölümünü oluşturuyordu.

Yapay zeka, bu düşünme biçimine doğrudan karşılık gelen bir araç sundu.

Yani yapay zekaya geçiş benim için yeni bir düşünme biçimi öğrenmekten ziyade, zaten sahip olduğum düşünme biçimini kullanabileceğim bir ortama geçmek anlamına geliyordu.

Burada çok ilginç bir paradoks var.

Fonksiyonel programlamaya geçerken beynimi makinenin anlayabileceği farklı bir modele adapte etmek zorundaydım.

Yapay zekaya geçerken ise makine benim düşünme ve ifade biçimime adapte olmaya başladı.

Birincisinde insan makineye yaklaşıyordu.

İkincisinde makine insana yaklaşıyor.

Sanırım yapay zekaya geçişte hiç zorlanmamamın temel nedeni bu.

İlk defa yazılım geliştirmek için bir programlama dilinin düşünme biçimine adapte olmak zorunda kalmadım.

Bu sefer teknoloji benim düşünme biçimime adapte oldu.

Aynen gelen bir yorumu paylaşıyorum. Sonra problemin ne olduğunu açıklamaya çalışacağım.

“ancak ai tarafindan cok kez yanlis sonuc olduguna emin oldugum cevaplar aldim eminmisin dedigimde haklisin deyip yeni bir kod verdi.. ya da verdigi koddaki guvenlik aciklari saymakla bitmez.”

Öncelikle şunu belirtelim:

Bu şekilde yapay zeka ile yazılım geliştirilmez.

Karşınızda deterministik olmayan bir yapı var. Tabii ki zaman zaman kafasına göre bir şeyler anlatacak. Tabii ki size sürekli “Haklısınız!” diyecek. Bunlar yapay zekanın bilinen davranış biçimleri.

Burada üç temel noktaya dikkat etmek gerekiyor.

Birincisi: Yapay zekayı sürekli sorgulayarak, “Emin misin?” diye sorarak doğru sonuçlara ulaşamazsınız. Çünkü verdiği cevapların doğruluğunu kendisinin teyit etmesi güvenilir bir doğrulama yöntemi değildir.

İkincisi: Yapay zeka için kontrol ve denetim mekanizmalarının oluşturulması gerekiyor.

Bu mekanizmaların önemli bir kısmını analiz yeteneği güçlü başka bir yapay zeka modeliyle oluşturabilirsiniz. Her model hem analiz hem de yazılım geliştirme konusunda aynı derecede başarılı olmayabiliyor.

Bir model gereksinimleri analiz eder, başka bir model uygulamayı geliştirir, üçüncü bir model de ortaya çıkan sonucu bağımsız olarak denetler.

Üçüncüsü: Deterministik olmayan bir yapıdan deterministik beklentilerinizi karşılayan çıktılar almak istiyorsanız, çalışma çerçevesini ve beklentilerinizi çok net ifade etmeniz gerekiyor.

Bunun için iki önemli aracımız var:

Onay/kabul kriterleri: Uygulamanın hangi koşullarda doğru çalıştığını tanımlar.

İnvariantlar: Sistemin hangi koşullarda olursa olsun ihlal etmemesi gereken kuralları tanımlar.

Kabul kriterleri olmadan uygulamanın beklenen davranışları sergilediğinden, invariantlar olmadan da sistemin temel kurallara uygun çalıştığından emin olamazsınız.

Ancak bunları tanımlamak da tek başına yeterli değildir. Bu kuralların otomatik olarak doğrulanabildiği mekanizmalar oluşturmanız gerekir. Özellikle güvenlik söz konusu olduğunda bağımsız kontroller de şarttır.

Asıl problem yapay zekanın yanlış kod üretmesi değil, yanlış kodun doğruymuş gibi kabul edilmesine izin veren geliştirme yöntemidir.

Yapay zekaya güvenerek yazılım geliştirilmez. Yapay zekanın ürettiklerini doğrulayabilen bir sistem kurarak yazılım geliştirilir.

Emin mısın diye soran birisi ne yazık ki ne yaptığının farkında bile değildir.

Dikkat ettiyseniz, yapay zekanın yazılımcılar tarafından kabullenilme oranı son altı ayda dramatik bir şekilde arttı.

Eskiden “Yapay zeka kod yazamaz!” deniliyordu. Şimdi ise “Yapay zeka ile kod yazmak mesele değil, asıl mesele onu yönetebilmek!” deniliyor.

Kabulleniş, gerçeklerin her zaman en az 3-6 ay gerisinden geliyor.

Burada çok büyük bir sıkıntı görüyorum.

Çünkü yapay zekanın gelişim hızı ile yazılımcıların bu gelişimi kabullenme hızı arasında giderek büyüyen bir uçurum var.

Eğer bu gidişata yeterince hızlı adapte olunamazsa, bazı şeyler için artık çok geç olabilir.

Örneğin, tecrübeli bir senior developer altı aylık bir zaman diliminde yapay zekayı çok iyi kullanan, onunla uçtan uca ürün geliştirebilen bir yazılımcıya dönüşebilir.

Ama aynı altı ayı, bazı gerçekleri kabullenmekte zorlandığı için kaybederse, kariyerini ciddi anlamda riske atabilir.

Çünkü o altı ay boyunca sadece yapay zeka gelişmiyor. Onu kabullenmiş ve kullanmaya başlamış diğer yazılımcılar da gelişiyor.

Aradaki fark her geçen gün biraz daha açılıyor.

Asıl tehlike yapay zekanın yazılımcıların yerini alması değil, bazı yazılımcıların değişimi kabullenene kadar diğerlerinin çoktan yeni bir seviyeye ulaşmış olması.

Bu yüzden bugün kaybedilen altı ay, yarın altı aylık çalışmayla telafi edilemeyebilir.

Kod yazmak için IDE, yapay zeka ajanlarıyla etkileşime girmek için CLI kullanmak artık gereksiz.

Kod yazmıyoruz. O halde neden bir kod editörü kullanalım?

Ajanlarla sürekli etkileşime girmek de zaman kaybından başka bir şey değil. 30 farklı CLI penceresinde 30 ajanı yönetmeye çalışmak ölçeklenebilir bir yöntem değil.

Yapay zekaya işleri devrediyoruz ama bu sefer de ajanları yönetmek için bilgisayar başına mahkûm oluyoruz.

Geriye ne kalıyor?

– Dark Software Factory

– Loop Engineering

Dark Software Factory, yazılım üretim sürecinin insan müdahalesine ihtiyaç duymadan çalışmasını sağlayan yapı.

Loop Engineering ise bu yapının içinde ajanların iş paketlerini tamamlayana, kabul kriterlerini karşılayana ve sistem invariantlarını sağlayana kadar otonom çalışmasını sağlayan yöntem.

Bu ikisi bir araya geldiğinde IDE’ye, CLI’ye veya ajanlarla sürekli etkileşime girmeye ihtiyaç kalmıyor.

Biz ürünü tanımlıyoruz, kabul kriterlerini ve sınırlarını belirliyoruz. Gerisini yazılım fabrikası hallediyor.

Amacımız yapay zeka ajanlarıyla daha verimli çalışmak değil, onlarla çalışmak zorunda kalmamaktır.