Hiç hamur işi yapıp fırına verdiyseniz iyi bilirsiniz.

Arada bir fırının kapağından içeri bakıp hamurun nasıl kabardığını, şekil aldığını görmek çok zevklidir.

İnsan emeklerinin karşılığını canlı canlı görür.

İşte yapay zeka ile ürün geliştirmek de artık fırına yemek vermek gibi bir şey. En azından bana böyle hissettiriyor.

Üstelik yemeği de artık kendiniz hazırlamıyorsunuz.

Star Trek dizisindeki yemek replikatörlerini hatırlayın. Ne yemek istediğinizi söylüyorsunuz, replikatör de onu sizin için hazırlıyor.

Yapay zeka ile ürün geliştirmek de giderek buna benziyor.

Ne istediğinizi tarif ediyorsunuz, fırına veriyorsunuz ve arada bir nasıl şekillendiğini kontrol ediyorsunuz. Loop engineering ile o yazılım replikatörlerini kullanmış oluyorsunuz.

Biraz daha tuz, biraz daha baharat, şurası biraz daha kızarsın derken…

Hop, yemek hazır!

Pardon, ürün hazır. ;-)

Afiyet olsun!

Yapay zeka ile çalışan bir yazılımcıdan bütün ekibin işini yapmasını beklemenin doğru olmadığı fikri savunuluyor.

Galiba siz sektörü tanımıyorsunuz!

Eskiden fullstack developer diye bir rol vardı, hatırlarsınız belki.

Neden böyle bir rol ortaya çıktı?

Çünkü iki kişinin işini bir kişiye yaptırmak istediler. Üstelik o zaman yapay zeka falan da yoktu.

Sektörün temel eğilimi hep aynıdır: Daha az maliyetle daha fazla iş yaptırmak.

Şimdi sektör yeni bir gerçeği keşfediyor:

Yapay zeka ile çalışan tek bir yazılımcı, eskiden bir ekibin yaptığı işlerin büyük bölümünü tek başına üstlenebiliyor.

Siz gerçekten kapitalist piyasa dinamikleriyle çalışan bir sektöre, bunun doğru olmadığını söyleyerek yön verebileceğinizi mi düşünüyorsunuz?

Sektör her zaman ekonomik çıkarlarının peşinden gidecek.

Yarın işverenler, “Artık beş kişilik ekiplere ihtiyacımız yok. Tek kişilik ekipler kuruyoruz.” dediklerinde, bu talebi ya karşılayacaksınız ya da oyun dışında kalma riskiyle karşılaşacaksınız.

İşin ekonomik boyutunu bir kenara bırakalım.

Teknik açıdan baktığımızda da yapay zeka ile çalışan deneyimli yazılımcıların, eskiden bir ekibe ihtiyaç duyulan pek çok işi tek başlarına gerçekleştirebilecek kapasiteye ulaştıklarını görüyoruz.

Gereksinim analizi, mimari tasarım, frontend, backend, test, release, deployment ve operasyon…

Bütün bu alanlarda uzmanlaşmış ajanları yöneten tek bir mühendis düşünün.

Bu mühendisin üretim kapasitesini artık klasik ekip büyüklüğüyle ölçemezsiniz.

Yazılım geliştirmek için mutlaka bir ekip kurmak zorunda olduğumuz dönem sona eriyor.

Yerini yüzlerce yapay zeka ajanını yöneten, tek kişilik yazılım ekipleri alacak.

İster kabul edin ister etmeyin, sektörün ekonomik dinamikleri bu dönüşümü hızlandıracak.

Kurduğum setup içerisinde şu an tek darboğaz GPT.

Oluşturduğum Software Factory bünyesinde, Loop Engineering yaklaşımıyla projelerin nasıl otonom bir şekilde geliştirildiğinden daha önce birçok kez bahsettim.

Loop Engineering için GPT + Opus ikilisini kullanıyorum.

İş bölümü oldukça net:

Opus: Implementasyon ve kod geliştirme

GPT: Analiz, mimari değerlendirme ve code review

Opus Max 20x üyeliğiyle bu setup içerisinde 2-3 projeyi paralel olarak 7/24, kesintisiz geliştirmek mümkün. Üstelik haftalık ve saatlik kullanım limitlerim dolmuyor.

Lakin GPT tarafında durum farklı.

Özellikle Sol ve Astra modellerinin gelmesiyle birlikte haftalık kullanım kontenjanım artık iki gün bile yetmemeye başladı.

Bu yüzden haftalık rate limit engeline takılmamak için üç ayrı Pro hesabı kullanıyorum. Sürekli hesap değiştirmek zorunda kalıyorum.

İşin ilginç tarafı şu:

Artık yazılım üretim kapasitemi sınırlayan faktör ne yazılımcı sayısı ne de kod geliştirme hızı. Yapay zeka modellerinin kullanım limitleri.

Software Factory’nin üretim kapasitesi, kullandığım modellerin inference kapasitesine ve erişim kotalarına bağımlı hale gelmiş durumda.

Yazılım mühendisliğinde darboğazın nereden nereye taşındığına bakar mısınız? ;-)

Gerçekler artık şu şekilde:

Software Engineer ünvanı artık sadece yazılım geliştirme yetkinliğini ifade etmiyor.

Bir Software Engineer’ın aşağıdaki rolleri de üstlenebilecek yetkinliğe sahip olması gerekiyor:

– Requirements Engineer

– Software Architect

– Test / QA Engineer

– Security Engineer

– Release and Deployment Engineer

– DevOps Engineer

– Performance Engineer

– Site Reliability Engineer (SRE)

Bir yazılımcının bütün bu işleri bizzat yapması gerekmiyor, ancak yapay zekanın yaptığı işleri değerlendirebilecek ve sonuçlarının sorumluluğunu üstlenebilecek yetkinliğe sahip olması gerekiyor.

Neden Vibe Coding Engineer diye bir mühendislik disiplini yok?

Çünkü artık kod yazmıyoruz ;-)

Kod yazmak, yazılım mühendisliğinin sadece bir parçasıydı. Yapay zeka bu kısmı büyük ölçüde üstlenmiş durumda.

Vibecoder’lara selamlarımla. 

Bu işin çocuk oyuncağı olduğunu düşünmeye devem edeebilirler.

Yapay zeka sizi gereksinim analisti olmaya zorluyor.

Zamanla gereksinimleri ne kadar net ifade etmeniz gerektiğini anlıyorsunuz, çünkü yapay zekanın ürettiği çıktılar her zaman beklentilerinizle örtüşmüyor.

Bu noktada kendinize şu soruyu sormaya başlıyorsunuz: “Ben ne istediğimi nasıl daha iyi anlatabilirim?”

Bu soru sizi daha detaylı, daha sistematik ve daha analitik düşünmeye zorluyor.

Eskiden yazılımcıların gereksinim analizi konusunda ciddi eksikleri vardı. Büyük projelerde genellikle bir Requirements Engineer bulunurdu. Gereksinimler bu uzmanlar tarafından analiz edilir, detaylandırılır ve yazılımcılara hazır iş paketleri olarak sunulurdu.

Yani yazılımcılardan gereksinimleri keşfetmeleri değil, kendilerine verilen gereksinimleri implemente etmeleri beklenirdi.

Şimdi ise durum değişiyor.

Yapay zeka ile çalışan bir yazılımcı, öncelikle bir Requirements Engineer olmak zorunda.

Ne istediğini, neden istediğini, sistemin nasıl davranması gerektiğini ve hangi koşullarda ne yapacağını tarif edebilmesi gerekiyor.

Ardından bir Software Architect oluyor. Sistemin mimarisini, bileşenlerini, aralarındaki ilişkileri ve teknik sınırları belirliyor.

Sonra bir Test Engineer oluyor. Ortaya çıkan ürünün gereksinimleri karşılayıp karşılamadığını, beklenen davranışları sergileyip sergilemediğini doğruluyor.

Akabinde bir Release Engineer oluyor. Ürünün sürümlenmesini, paketlenmesini ve dağıtıma hazırlanmasını yönetiyor.

Son olarak bir DevOps Engineer oluyor. Ürünü canlıya alıyor, çalışmasını izliyor ve operasyonel sürekliliğini sağlıyor.

Dikkat ederseniz bütün bu süreçte yazılımcının kod yazmasından neredeyse hiç bahsetmedim, çünkü kodu artık büyük ölçüde yapay zeka yazıyor.

Ancak yapay zekanın neyi, nasıl ve neden yapacağını belirleyen kişi hala yazılımcı.

Eskiden yazılımcı, yazılım geliştirme sürecinin bir halkasıydı. Şimdi ise bütün zinciri yönetmek zorunda.

Artık yalnızca kod yazmayı bilmek yeterli değil. Yazılım mühendisliğinin tamamını anlamak gerekiyor.

Bu sebeple eskiden sadece kod yazan ama başka bir şeye karışmak istemeyen yazılımcıların kariyeri noktalanmıştır. Buna karşın interdisiplin çalışabilen mühendislere ihtiyaç daha da artacak.

Eğer kendinize yapay zeka çağında gelişmelere nasıl adapte edebilirim sorusunu soruyorsanız bu yazıda geçen mühendislik alanlarına naçizane odakllanmanızı tavsiye ederdim.  Ya tüm zincire hakimsiniz ya da oyun dışı kalırsınız.

Artık yazılım mühendisliğini gerçek anlamda bir bütün olarak yaşabileceğimiz bir safhaya geldik. Bu çok güzel bir haber, lakin bu her mühendislik alanında derinleşmeye gerektiriyor. Bunu zaten yıllarca yapmış olan senior developer’lar 10-0 öndeler.

Daha önce de bahsetmiştim. Ajanların parladığı tek alan kod yazmak değil.

Canlı ortamların yönetimi için yapay zeka ajanları biçilmiş kaftan. DevOps süreçlerinin çok büyük bir bölümünü, hatta zamanla neredeyse tamamını ajanlara devretmek mümkün.

Bu amaçla Agentic Operations Center (AOC) adını verdiğim bir altyapı kurgulamaya başladım.

Bir uygulama düşünün. Bu uygulama bünyesinde aşağıdaki çalışma alanları tanımlı:

– Altyapı: Sunucular, CPU, RAM, disk ve diğer sistem kaynakları.

– Uygulamalar: Canlı ortamda çalışan servisler ve uygulamalar.

– Veritabanları: Performans, erişilebilirlik, bakım ve optimizasyon.

– Sürüm ve Deployment: Release, artifact ve deployment yönetimi.

– Güvenlik: Güvenlik açıklarının, tehditlerin ve anormal aktivitelerin tespiti.

– Incident Management: Sorunların tespiti, analizi, önceliklendirilmesi ve giderilmesi.

Her çalışma alanında görevleri ve sorumlulukları önceden belirlenmiş bir veya birden fazla ajan tanımlamak mümkün.

İkinci aşamada bu ajanların canlı ortama deploy edilmesi geliyor.

Bunun için canlı ortamda ajan koordinasyonunu, onboarding süreçlerini ve görev dağılımını yöneten merkezi bir uygulama bulunuyor.

Bu uygulama üzerinden yeni ajanların işbaşı yapmasını sağlamak, mevcut ajanlara görev vermek, çalışmalarını takip etmek ve hangi ajanın nerede, ne zaman, hangi işlemi gerçekleştirdiğini görmek mümkün olacak.

Yani bir nevi yapay zeka ajanlarından oluşan otonom bir operasyon ekibi kuruyoruz.

Üstelik bu ajanlar yalnızca sistemleri izlemekle kalmayacak. Sorunları analiz edecek, birbirleriyle koordineli çalışacak ve kendilerine tanınan yetkiler çerçevesinde gerekli müdahaleleri de gerçekleştirebilecekler.

Sistem henüz fikir ve tasarım aşamasında. Ancak birkaç gün içerisinde çalışan ilk versiyonunu ortaya çıkarmayı hedefliyorum.

Bir sonraki yazımda detaylarını sizlerle paylaşacağım.

Peki, DevOps mühendislerine ne olacak?

Bana kalırsa DevOps rolü ciddi bir dönüşüm geçirecek.

Bugün DevOps mühendislerinin gerçekleştirdiği operasyonel işlerin önemli bir kısmını gelecekte ajanlar üstlenecek.

DevOps mühendisleri ise doğrudan operasyonları gerçekleştirmek yerine, bu operasyonları yürüten ajan sistemlerini tasarlayan, geliştiren, yöneten ve denetleyen kişilere dönüşecekler.

Yani DevOps ortadan kalkmayacak. DevOps’un operasyonel iş gücü insanlardan ajanlara kayacak.

Eskiden bir uygulamanın nasıl olması gerektiğini anlamak için gerçek anlamda bir araştırma yapmak, müşteriye detaylı sorular sormak, gereksinimleri çıkarmak, mockup ve prototipler hazırlamak, ardından mimariyi oluşturmak gerekiyordu.

Simdi yapay zekaya istediğiniz şeyin bir resmini vermeniz bile yeterli olabiliyor. Detaylara haftalarca kafa patlatmadan, “Şöyle bir şey istiyorum” diyorsunuz ve kısa süre içinde çalışan bir karşılığını görebiliyorsunuz.

Burada aslında çok daha hızlı bir şekilde müşterinin isteklerini aynalayan bir çözüme ulaşmanın yolu açılıyor.

Müşteri “Bu olmamış” dese bile artık bu eskisi kadar büyük bir problem değil. Çünkü gerekli değişiklikleri çok hızlı bir şekilde yapıp yeni versiyonu tekrar müşterinin önüne koyabiliyorsunuz.

Bir anlamda gereksinim analizi ürün geliştirmeden önce yapılan bir aşama olmaktan çıkıp, ürünün kendisi üzerinden yapılan sürekli bir keşif sürecine dönüşüyor.

İşin vahametini göstermek için bir analoji aktarayım.

Kalp cerrahlarını düşünün.

Şimdi de herkesin yapay zeka aracılığıyla kalp ameliyatı yapabileceğine inandığını ve gerçekten ameliyat yapmaya başladığını düşünün.

Yazılım geliştirmek, özellikle büyük ve kritik sistemlerde, her zaman açık kalp ameliyatı yapmak gibiydi.

Bir cerrahin insan vücuduna müdahale edebilecek seviyeye gelmesi yıllar süren eğitim, gözetim ve pratik gerektirirken; yazılım dünyasında yeni mezun olmuş birisinin kurumsalda ise başlayıp birkaç hafta sonra binlerce insanın kullandığı sistemlerin kodunu değiştirmesi son derece normal karşılanıyordu.

Ama şimdi ölçek değişti.

Vibe coding yapanların projelere ne kadar büyük zarar verebileceklerini artık siz düşünün.

Çok acil bir şekilde bu mesleğe yeni başlayanların adam akıllı bir eğitim sürecinden geçirilmeleri ve zarar vermeden çalışabilecek seviyeye getirilmeleri gerekiyor.

Yapay zeka dönemini daha tam olarak idrak edememiş olanlara neden sadece deneyimli bir yazılımcının ön kişinin işini artık tek başına yapabileceğini hatırlatalım.

Evet, eskiden bir yazılım ürününü çıkarmak için frontend, backend, test, product owner, devops gibi rolleri üstlenen insanlara ihtiyacınız vardı. Yani bu işleri çoğu zaman 5-10 kişilik ekipler yapmak zorundaydı.

Şimdi bu 5-10 kişilik ekibin yaptıklarına bir göz atalım.

Neden bu kadar kişiye ihtiyaç vardı? Projeler neden aylar, hatta yıllar sürerdi?

Çünkü yapılması gereken muazzam miktarda manuel iş vardı. Sonra bunların hepsinin birbiriyle koordinasyonu gerekirdi. Toplantı, sprint, sürüm, deployment, müşteri istekleri derken iş uzayıp giderdi ve birçok elden geçerdi. 

Dolayısıyla klasik yazılım geliştirme metodolojilerinin önemli bir kısmı aslında sadece yazılım geliştirmek için değil, insanlar arasındaki bu koordinasyon problemini yönetebilmek için ortaya çıktı.

Şimdi denklemin temel parametrelerinden biri değişiyor.

Bir yazılımcının yanında artık kod yazabilen, test oluşturabilen, kod tabanını analiz edebilen, dokümantasyon hazırlayabilen, bug araştırabilen, refactoring yapabilen ve altyapı scriptleri oluşturabilen yapay zeka ajanları var.

Deneyimli bir yazılımcı artık tek başına eskiden on kişilik bir ekibin yaptığı işi yapabilir, daha doğrusu ekibin yerine ajanların geçmesini ve onların yönetimini sağlayabilir.

Daha önceki bir yazımda 200K maaş için adaydan beklentilerdile getirdim.

Çoğu gelen yorumda “koyunun altında buzağı arıyorsun, hiç kimsede bu kadar yetenek bir arada olamaz” dendi.

Şunun altını çizeyim. Bu hiçbir şey değil. Yapay zeka bu hızda ilerlemeye devam ettiğinde, adaylardan beklenen yetenek ve tecrübelerde o hızla artacak.

Artık ajanların neredeyse kendi başlalarına sistem kurabilecekleri safhaya gelmiş durumdayız. Yazılımcı olarak diskalilfiye olmamak için bu hızlı gidişata ayak uydurmamız gerekiyor.

Extreme Programming gibi çevik süreçlerdeki ana çalışma prensiplerinden biri, müşteriye kısa aralıklarla ürünün ne durumda olduğunu gösteren çalışan prototipler sunmaktı.

Bunun için bir ya da iki haftalık sprint’ler planlanır, bu zaman zarfında seçilen user story’ler ürünün parçası haline dönüştürülürdü.

Peki neden bir ya da iki hafta?

Çünkü yazılım geliştirmek zaman alan ve maliyetli bir işti.

Analiz yapılması, kodun yazılması, test edilmesi, code review’dan geçmesi, entegre edilmesi ve müşterinin deneyebileceği bir ortama deploy edilmesi gerekiyordu.

Yapay zeka bu sürelerin tamamını dramatik biçimde aşağıya çekiyor.

Bir user story’nin implementasyonu artık günler değil saatler sürebilir. Testleri aynı anda üretilebilir. Review ajanlar tarafından paralel yapılabilir. Cİ/CD ve deployment otomasyonu ile birkaç dakika sonra çalışan sistem müşterinin önüne konulabilir.

Bu durumda 1-2 haftalık sprint kavramının da sorgulanması gerekiyor.

Çünkü sprint aslında feedback loop’un uzunluğuydu.

Yapay zeka ile feedback loop kısaldıkça sprint de küçülmek zorunda.

User Story → Implementasyon → Test → Deploy → Feedback

Bu döngünün iki hafta sürmesi gerekmiyorsa neden iki haftalık sprint yapalım? Bu iki hafta müşteriden kopmak anlamına gelir. Bu zaman zarfında zaten istenilen ürünü oluşturmuş olabiliriz.

Bence sprint kavramını tamamen ortadan kaldırmak lazım.

Müşteri ve yazılımcı arasında artık realtime bir ilişki söz konusu.

Yazılımcı müşterinin istediği değişiklikleri hemen implemente edebilir ve akabinden bunları müşteriye gösterip, geri bildirim alabilir. Akabinde döngü yine başlar.

Çevik süreçler tamamen geri bildirim (feedback cycle) üzerine kurgulanmıştı. Pair programming, TDD, CI vb yöntemlerin hepsi hızlı bir şekilde geri bildirim almak için vardı. 

Şimdi bunlara gerek kalmadan gerçek zamanlı geri bildirim döngüleri oluşturabiliyoruz.

Bu yüzden geliştirme sürecinin temel zaman birimi “sprint” değil, feedback loop olmalı.

10+ yıl tecrübeli ve artık “dinozor” olarak görülen yazılımcılar ile çok az yazılım tecrübesi olan yazılımcıları aynı kefeye koymaya başlamışlar.

Kod yazmanın ya da yazdırmanın yeterli olduğunu düşünüyorlar.

Yapay zekanın kod yazıyor olması iki jenerasyon arasındaki farkı öyle kolay kolay kapatamaz.

10+ yıl tecrübeli bir senior yazılımcının ne anlama geldiğini bilmiyorlar sanırım.

Açıklayalım.

Yazılım da diğer meslekler gibi çıraklık, kalfalık ve ustalık safhaları ihtiva eder.

Yeni mezun birisi çıraktır. Bu çıraklık birkaç sene sürer. Sonra işi kavradıysa kalfa olur. Kalfalık döneminde artık kendi başına birçok işi yapabilir, fakat hala yıllar boyunca farklı sistemler, problemler ve başarısızlıklar görmesi gerekir.

10+ seneye gelindiğinde, eğer yazılımcı kendisini gerçekten geliştirebildiyse ustalaşmıştır.

Usta yazılımcının farkı daha hızlı kod yazması değildir. Hatta bazen daha az kod yazar.

Fark şudur:

Çırak kendisine verilen problemi çözer.

Kalfa çözümün nasıl implemente edileceğini bilir.

Usta ise önce o problemin gerçekten çözülmesi gereken problem olup olmadığını sorgular.

Çırak kodu görür.

Kalfa uygulamayı görür.

Usta sistemi görür.

Şimdi bu seviyedeki bir yazılımcının eline yapay zeka araçlarını verin ve sadece oturup, neler yapabildiğini seyredin. Çok hızlı bir şekilde senior developer ne anlama gelir, size göstersin.

Bir sonraki patlama CI/CD pipeline’larında yaşanacak.

Yapay zeka deli gibi kod yazıyor. Ama koddan belki daha hızlı test yazıyor.

Bunun sonucu kontrolsüz bir test enflasyonu.

Ben şu anda bu problemle bizzat savaşıyorum. Bir backend sürümünün test, release ve deployment süresi 90 dakikaya dayanmış durumda.

Asıl problem test sayısı da değil.

Bu testlerin önemli bir bölümü sistemin davranışını değil, implementasyonunu test ediyor. Yani bir işlemin kod içinde hangi adımlarla gerçekleştirildiğini tek tek doğruluyor.

Bunun uzun vadede değeri düşük. Çünkü implementasyon, sistemin o anki modelinin yalnızca bir temsilidir ve değişebilir.

Implementasyon değiştiğinde bu testlerin de değişmesi gerekir. Değişmediğinde ise binlerce test her entegrasyonda ve her sürümde aynı implementasyon detaylarını tekrar tekrar doğrular. Test sayısı büyür ama sağladığı güven aynı oranda büyümez.

Yapay zeka çağında test stratejisinin de değişmesi gerekiyor.

Ben çözümü giderek daha fazla iki noktaya odaklanmakta görüyorum:

Kabul kriterleri ve sistem invariantları.

Yani:

“Bu metot şu üç fonksiyonu şu sırayla çağırıyor mu?” yerine,

“Bu işlem tamamlandığında sistemde doğru sonuç ortaya çıkıyor mu?”

ve:

“Sistemin hiçbir koşulda bozmaması gereken kurallar hala geçerli mi?”

Bu yaklaşımla test sayısı drastik şekilde azaltılabilirken sistemin gerçek davranışı ve dogruluk seviyesi korunabilir.

Yapay zeka çağında hedef maksimum test coverage olmamalı. Hedef, minimum test maliyetiyle maksimum davranışsal güven olmalı.

Aksi takdirde yapay zekanin kod üretim hızının bedelini CI/CD pipeline’larında ödeyeceğiz.

Bu tempo devam ederse bugün 90 dakika süren bir release yarın saatler, daha sonra günler sürebilir.

Kod üretimindeki darboğazı kaldırırken yeni darboğazı CI/CD tarafında yaratıyoruz.

Yapay zeka ile çalışırken dikkat edilmesi gereken en önemli hususlardan birisi, onun birçok söylem ve eyleminin altında varsayımların yatmasıdır.

İsteklerinizi yeterince keskin ifade etmezseniz, size kanatları olan ama uçamayan bir uçak teslim edebilir. 

Uçak örneğinden devam edelim.

Varsayımları ortadan kaldırmak için sadece “bir uçak yap” demek yetmez. “Bu uçak tamamlandığında uçabilmelidir” demeniz gerekir.

İşte varsayımlara karşı kullanabileceğiniz en güçlü panzehirlerden ikisi:

Onay/kabul kriterleri ve ınvariantlar.

Bu ikili ile gereksinimleri teknik anlamda formalize etmek mümkün hale gelir.

Bunun üç önemli sonucu vardır:

– Ajanlara ne yapmaları gerektiğini net olarak söylersiniz.

– Ajanların hareket alanına net sınırlar çizersiniz.

– İşin ne zaman gerçekten tamamlandığını objektif olarak ölçebilirsiniz.

Üçüncü madde özellikle önemli.

Çünkü “kod yazıldı”, “özellik implemente edildi” ya da “uygulama çalışıyor” birer tamamlanma kriteri değildir.

Uçağın kanatlarının olması, motorunun çalışması ve pistte ilerleyebilmesi de yeterli değildir. Uçak uçmuyorsa, uçak tamamlanmamıştır.

Kabul kriterleri bize neyin gerçekleşmesi gerektiğini, ınvariantlar ise ne olursa olsun hangi kuralların ihlal edilemeyeceğini söyler.

Böylece yapay zekaya sadece ne üretmesi gerektiğini değil, ürettiği şeyin hangi koşullarda doğru kabul edileceğini de tarif etmiş oluruz.

Yapay zeka çağında gereksinim yazmak artık yalnızca ne istediğimizi anlatmak değildir. Doğru olanın sınırlarını tarif etmektir.

Aksi taktirde yapay zeka ile sadece sohbet etmiş olursunuz.

Gelelim yazılım mühendislerinin her daim sınavı olmuş şu zihinsel model oluşturma işine.

Zihinsel modelin sadece kod bağlamında oluşabileceğine, koddan kopmakla birlikte bunun artık mümkün olmadığına dair garip bir inanış var.

Yapay zekaya her şeyi devir ve delege ettiğimizde, yapılan iş hakkında zihinsel model oluşturmanın artık bir illüzyon olduğunu söylemlerini duymaya başladım.

Genelde bu söylemlerin arkasında çok uzun yıllar kod yazmış ve bu işi kutsallaştırmış yazılımcıların olduğunu düşünüyorum. Artık kod yazmadığımıza göre onların en güçlü dayanakları ve parladıkları alan ortadan kalkmış durumda: kod yazma yetisi.

Neden yapay zekanın, kod yazmasak bile eskisine kıyasla daha zengin zihinsel modeller oluşturmamıza katkı sağladığını açıklayayım.

Öncelikle üzerinde çalıştığımız bir işin gerçek bir zihinsel modeli ile kodun zihinsel modelini birbirinden ayırmamız gerekiyor. İkisi aynı şey değil. Kodun ne yaptığını bilmek, onun çalışma şeklini içselleştirmek, nasıl eklemeler yapabileceğini bilmek koda bağımlı olan zihin modelidir. Bu yüzden kod okumuyorsak, artık zihinsel model oluşturamayız demek yanlıştır. Sadece kod için gerekli zihinsel modeli oluşturamayabiliriz kaldı ki açıp kodu okumadan ve nasıl bir yapıda olduğunu anlamaktan bizi kimse alıkoymuyor. İsteyen kod tabanlı zihinsel modeli hemen oluşturabiilr.

Kod sistemin kendisi değil; sistemin belirli bir teknolojiyle yapılmış temsilidir. Hatta yapay zeka öncesinde çoğu zaman zihinsel modelimizi kod üzerinden kurmak zorundaydık, çünkü sisteme açılan ana pencere koddu.

Örneğin bir e-ticaret sistemini anlamak için OrderService sınıfındaki 600 satır kodu zihninizde tutmanız gerekmez. Öyle bir sınıftaki ıf, for, interface, repository, DTO ve SQL sorguları oluşturmamız gereken zihinsel modelin belirli bir teknoloji kullanılarak hayata geçirilmiş halidir. 

Ama bundan daha önemli bir üst zihinsel model vardır, o da bu sınıfın aslında işletme mantığı ve gereksinimler çerçevesinden baktığımızda ne yapması gerektiğidir, örneğin sipariş hangi durumlara sahip, stok ne zaman rezerve edilir, sistem ınvariantları nelerdir vb.

Biz yıllarca ikisini birbirine karıştırdık. Çünkü başka çaremiz yoktu.

Bir sistemin nasıl çalıştığını anlamak istiyorsanız kodu açmanız gerekiyordu. Metotları takip ediyor, sınıflar arasında geziyor, debugger çalıştırıyor, SQL sorgularına bakıyor ve bütün bunlardan kafanızın içinde sistemin nasıl çalıştığına dair bir model oluşturmaya çalışıyordunuz.

Yani kod zihinsel model değildi. Kod, zihinsel modele ulaşmak için kullandığımız araçtı.

Şimdi o araç değişiyor.

Yapay zeka bana 50.000 satırlık kod tabanını satır satır okutmak yerine şunu anlatabilir:

“Bir sipariş oluşturulduğunda sistemde tam olarak neler oluyor?”

Eskiden zihinsel modeli koddan çıkarmaya çalışıyorduk.

Şimdi yapay zeka kodu okuyup bize sistemin modelini çıkarabiliyor.

Aradaki fark muazzam.

Üstelik burada çok önemli başka bir avantaj ortaya çıkıyor.

İnsan kod okurken lokal düşünmeye çok yatkındır.

Bir sınıfı açar. Bir metoda girer. Oradan başka bir metoda geçer. Repository’ye iner. Bir event bulur. Başka servise gider. Bir süre sonra ağacın dalları arasında dolaşmaya başlar.

Yapay zeka ise doğru kullanıldığında bunun tersini yapabilir.

On binlerce satırı tarayıp bize yukarıdan bakabileceğimiz bir harita çıkarabilir.

Yani zihinsel modelimiz küçülmez.

Soyutlama seviyesi yükselir.

Kod detaylarıını değil zihnimde sistemin davranışını tutmak isterim. Özellikle sistemin sahip olduğu invariantlara bakarak bir satır kod okumadan sistem hakkında mükemmel bir zihinsel model oluşturabilirim.

Zaten kod okuyarak oluşturduğumuz zihinsel model çoğu zaman sandığımız kadar iyi değildi. Çünkü insanın okuyabileceği kod miktarı sınırlı. Genelde zihnimizde oluşturabildiğimiz model sistemin sadece küçük bir kısmıydı, çünkü büyük resmi görmek her zaman ya mümkün degildi ya da yazılımcının entellektüel kapasitesi yeterli değildi.

Yapay zeka burada ilk defa bize çok daha geniş bir perspektif sunuyor. Koca bir sistemi birkaç prompt ile analiz ettirip, anında bir zihin modeli yaratabilirim. Bir insanın haftalar boyunca farklı kaynaklardan toplamaya çalışacağı bağlamı, aynı problem üzerinde bir araya getirebilirim.

Bu durumda zihinsel model nasıl fakirleşmiş oluyor?

Tam tersi söz konusu.

Kod seviyesindeki zihinsel modelden sistem seviyesindeki zihinsel modele geçiyoruz.

Eskiden iyi yazılımcıyı diğerlerinden ayıran şeylerden biri kodu okuyabilme ve kod üzerinden sistemin zihinsel modelini oluşturabilme yeteneğiydi. Şimdi başka bir yetenek öne çıkıyor:

Sisteme doğru soruları sorabilmek.

Koddan uzaklaşıyoruz ama sistemden uzaklaşmıyoruz.

Aksine:

Koddan uzaklaştıkça sisteme yaklaşma imkanımız doğuyor.