Benim yazilima bakis ve yazilimi uygulayis tarzimi tamamen extreme programming (https://pratikprogramci.com/wp-content/downloads/pratik-agile-ozcan-acar.pdf) sekillendirdi.

Extreme Programming ile test güdümlü yazilimin ve refactoring yapma kabiliyetinin bir yazilim icin ve onu sekillendirme sürecinde ne anlama geldiklerini bu sekilde ögrendim.

Yazilimda cevik olmanin temelinde uygulamayi bir hamur gibi yogurabilme yetisi yatiyor (https://kurumsaljava.com/2012/04/05/cevikligin-boylesi/). Her yeni müsteri gereksinimi ile uygulanin hamur gibi yogrulmasi yani yeni bir sekle sokulmasi zorunlu. Bunu sadece refactoring yönetimi ile yapabiliriz. Refactoring de sadece ve sadece yeterli ve kapsama alani genis testler varsa mümkün.

Genel olarak beni kodun yapisal durumu ilgilendirmiyor. Clean code, tasarim sablonlari, tasarim presipleri…. ne uygularsaniz uygulayin, en kutsal ve yüce kodu bile yazsaniz, testleriniz yoksa refactoring yapamazsiniz yani uygulamayi yeni müsteri gereksinimlerini tatmin edecek hale sokamazsiniz, yani uygulamayi hamur gibi yoguramazsinz.

Yazilimcilara yillarca kodu nasil edebi bir eser gibi yazacagi anlatildi, ama bu madalyonun sadece bir tarafiydi. Scrum ile diger tarafini gösterir gibi yaptilar, ama hicbir zaman kodun gercek anlamda nasil hamur gibi yogrulacagi konusuna deginmediler, cünkü bunun nasil yapildigina dair fikirleri yoktu. Scrum yukari, scrum asagi derken cevik oldugunu düsünen ekipler, cevik yazilim yaptiklarini düsünerek, yazilim ürünleri gelistirdiler ve her defasinda uygulama ellerinde patladigi icin duvara tosladilar. Hicbir zaman da bu neden oluyor diye sorgulamadan devam ettiler, cünkü scrum ile herkes cevikti.

Artik bunlarin hepsi mazide kaldi.

Yazlim tarihinde ilk kez hicbir teknik yönteme (clean code, tdd, solid, srp, dip..) ihtiyac olmadan bir uygulamayi hamur gibi müsteri istekleri dogrultusunda yogurmak mümkün. Bunun icin sadece dogru promptlar gerekiyor.

Yazilimdaki en can alici yöntem olan refactoring yöntemine gerekli deger verilmedigi icin bugüne kadar gelistirilen her uygulama tas gibi kaskati olmak zorunda kaldi. Teknik borclarin birikmesi durumu her daim daha da kötülestirdi, ama yine de gerekli refactoring calismalari yapmak yerine, bu hep ötelendi.

Artik bunun icin mazeret kalmadi. Bir uygulamayi gerekiyorsa komple silip, yeniden tasarlamak, yeniden müsteri gereksinimlerini ihtiyava edecek sekilde yogurmak birkac prompt setine bakar.

Artik mevcu clean code degil, clean prompt.

OpenAI modellerinde haftalık limitler var ve yeni modeller Sol ve Astra ile birkaç gün içinde harcanacak token kalmıyor.

Bu sorunu aşmak için ben 3 pro hesabı ile çalışıyorum. Bunun yanı sıra görev tipine göre değişik model türleri kullanmaya başladım. Buradaki amaç fazla token yakmadan basit işleri ucuz modellere yaptırabilmek.

Buna rağmen her zaman Codex ile çalışırken bu haftalık limitlere takılıyorum.

Fable ve Opus’a kıyasla Gpt modelleri daha iyi kod yazamıyor. Ama analiz konudunda onlardan daha iyiler. Bu yüzden Codex’i analiz ve review için kullanıyorum. Kodu ise Fable ve Opus yazıyor.

Claude code ile yazılım geliştirmek çok daha rahat, çünkü orada saatlik limitler sizi sınırlayabiliyor ve en geç birkaç saat sonra devam edebiliyorsunuz.

Bu sebeple Claude code ile yazılım yapmak çok daha rahat ve verimli. Bunu analiz ve review konularında Codex ile birleştirince, çok verimli ve otonom yazılım yapabilen bir çalışma ortamı ortaya çıkıyor.

Yapay zeka ile çalışırken feature branch bazlı mı yoksa trunk based mi yani sadece develop ya da main branch içinde mi çalışılmalı?

Önce ben nasıl çalışıyorum, ona değineyim.

Ben trunk based calışıyorum. Birden fazla opus develop branch üzerinde değişik feature setleri üzerinde çalışıyorlar. Arada bir test ve derleme problemleri çıksada, birbirlerini bekleyip, devam edebiliyorlar.

Buna karşıllık her uygulama özelliği için bir feature branch oluşturmak mümkün. Bu şekilde işler birbirlerinden izole bir şekilde yürüyebilir.

Bu durumda şöyle bir sıkıntı oluşuyor. Uzun süre açık kalan feature branchların develop ile merge edilmeleri zorlaşabilir. Buradaki en büyük etken yapay zeka araçlarının çok kısa zamanda çok kod yazıyor olmaları. Sadece birgün sonra bile feature branchı merge etmek imkansız hale gelebilir.

Trunk based calışıldığında böyle bir sorun olmuyor. Ayrıca kod tek bir branch içinde olduğu için birbirinden bağımsız çalışan opus ve onun ajanları yeni gelen kodu bağlama (context) entegre edip, ona göre adapte olabiliyorlar.

Burada en sağlıklı gidişat bir proje için trunk üzerinde sadece bir opus çalıştırma şeklinde olacaktır. Bu şekilde hiçbir kolizyon oluşmaz.

Bu yüzden hızlı büyüyen bir projede yapay zeka araçlarının hızlı bir şekilde yeni koda adapte olmaları için trunk based calışmak en mantıklı seçenek gibi görünüyor.

Bir dashboard uı uygulaması geliştiriyorum uzun zamandır. Bilgisayar ekranında geliştirdiğim için responsive olup, olmadığı ile çok ilgilenmemiştim.

UI tamamlanınca cep telefonumdan bir bakayım dedim. Bakmaz olaydım ;-)

Yüzlerce arayüzün olduğu bir projeden bahsediyorum. Hepsinde diagramlar, tablolar, sıralı veriler vs.

Sadece üç prompt ile hepsinin responsive hale dönüşmesini sağladım.

Yüzlerce dosya değişikliğe uğramış.

Ben şimdi bunları nasıl review edebilirim ki?

Edemem! Bunun için vaktim ve mental kapasitem yok.

Bunun yerine cypres testlerime, entegrarsyon testlerime ve diğer uı testlerine güveniyorum.

Bu bir nevi refactoring. 

Refactoring nedir?

Refactoring dış davranışı değiştirmeden, iç implementasyonu değiştirmektir.

Ben dış davranışı test edebildiğim ve bu benim beklentilerimi karşıladığı sürece, içerde ne dolap döndüğü önem taşımamaktadır.

Artık şimdi bir responsive arayüzüm var.

Konu hep yapay zeka ne kadar yapmalı, kod yazmalı mıyım, kod okumalı mıyım noktasına geliyor.

Bu ikisine de artık gerek yok, zaten artık mümkün de değiller.

Bizim yazılımcılar olarak çıktıları deterministik bir şekilde kontrol edebileceğimiz yapılara ihtiyacımız var. Gerisini yapay zeka halletmeli ki biz de asıl problem için vakit bulabilelim. Bu “müşteri ne istiyor” sorusudur!

İki şey biz yazılımcılar için bitti:

1. Kod yazmak
2. Kod review yapmak

Birincisini deterministik olmayan ama yine de kod üretme konusunda deterministik olarak sınıflandırabileceğimiz yapay zeka araçları ile çözdük.

İkincisi için de deterministik olan araçlar oluşturmamız ve kullanmamız gerekiyor, çünkü yazılımcıların yapay zeka tarafından oluşturulan kodu ne okumaya zamanları var ne de herşeyi anlama kapasiteleri.

Bu araçları zaten yıllardır kullanıyorduk. Bazıları:

Semgrep, ÇodeQL, SonarQube, EŞLint, Checkstyle, Fındbugs, ArchUnit, Pact, E2E testing.

Kod yazma ve kod review yapma zorunluluklarımız bitti diye yazılımın teknik kısmından uzaklaşmamız doğru olmaz. Gidişata yön verebilmek için gerektiği zaman kodun içine girip, neler olduğunu anlayabilmemiz ve gerektiği şekilde yönlendirme yapabilmemiz gerekiyor.

Bu bağlamda yazılım mühendisliğinin teknik kısmı ortadan kalkmıyor; yalnızca şekil değiştiriyor.

Yeni görevimiz her satırı elle yazmak veya okumak değil; sistemden beklediğimiz davranışları açıkça tanımlamak, bunları deterministik araçlarla doğrulamak ve sonuçlarını doğru yorumlamak olacak.

Geleceğin iyi yazılımcısı en fazla kod yazan ya da okuyan kişi değil; doğru soruları sorabilen, bu soruları otomatik kontroller hâline getirebilen ve gerektiğinde sistemin derinliklerine inerek yön verebilen kişi olacak.

Kısacası kod üretiminden sistem mühendisliğine geçiyoruz.

Clean code, KİSS, YAGNI, SRP vb gibi kod yazma teknik ve prensiplerine son tutunmalar devam ediyor.

Artık kodun reusable olması gerekmediği konusunda yaptığım paylaşıma gelen yorumlardan bunu anlıyorum.

Kod hakkında benim takip ettiğim tek bir teknik yöntem var: uygulamanın kendisi ya da onu oluşturan uygulama özellikleri istediğim davranışı sergiliyorlar mı?

Yani ben sadece uygulama davranışlarını test ediyorum.

Bunun eski programlama dünyasındaki karşılığı acceptance testing, yani onay kabul testleri.

Onay kabul testleri uygulama ve uygulama özelliklerini blackbox olarak test eder.

Uygulama bir kara kutudur ve içinde ne olduğu bilinmez. Bu kara kutunun giriş, çıkış noktaları vardır ve testler bu giriş çıkış noktaları üzerinden bu kara kutu ile alışveriş yaparlar. Eğer belli girdiler doğrultusunda beklenen çıktılar alınıyorsa, o zaman onay kabul kriterleri çalışıyor demektir yani uygulamadan beklenen davranış alınmıştır.

Tüm bu durum bir fonksiyona indirgenebilir: f(a) = b;

f() kara kutu olan uygulamanın kendisi, f(a) test ettiğim uygulama özelliğidir. A değerini verdiğimde, kara kutu b çıktığını bana vermek zorundadır. Benim uygulamadan beklenttim bu yöndedir. Bu her zaman a değeri için b çıktısı olmak zorundadır. Eğer a için c geliyorsa, testler hatalıdır ve beklentilerim karşılanmamaktadır.

Sadece bir fonksiyona (f()) indirgediğimiz bir uygulama içinde çalışan kodun clean, srp, dip gibi tasarım prensiplerine uygun, reusable ya da extendable olması hiç mi hiç önem taşımamaktadır. Bu eskiden geçerliydi, çünkü orada deterministik kod ortaya çıkarma özelliği sınırlıydı. Kodu insanlar yazıyordu ve insanlar bolca hatalı kod yazıyordu. Yapay zeka ile bu durum ortadan kalkmıştır. Yapay zeka beklentileri karşılayacak f() fonksiyonunu nokta atışı yazma kabiliyetlerine sahip.

Derlenen ve makina koduna dönüşen koda baksaydınız, bahsi geçen teknik ve prensiplerin nasıl ayaklar altına alındığını ve aslında bunların sadece insanların gidişata hakim olmak içn gerekli zihinsel modeli oluşturmak için oluştulmuş araçlar olduğunu görürdünüz, çünkü insan zihni bu kadar karmaşık yapılara hükmedecek özellikte değil. O yüzden kontrollü ilerleyebilmesi için bu mekanizmaları oluşturmak ve kullanmak zorunda. 

Yazdıklarım, kodun iç yapısının tamamen önemsiz olduğu anlamına gelmez. Güvenlik, performans, gözlemlenebilirlik ve değişiklik maliyeti hâlâ gerçektir. Fakat artık her ihtimale karşı “clean”, reusable ve extendable kod üretmek zorunda değiliz. İhtiyaç doğduğunda kodu yeniden üretebilir veya dönüştürebiliriz.

100, 200 token sonra ne okuduğunu bile anlamakta zorlanan insan zihni için clean code gerekiyor, milyonlarca tokeni aynı anda işleyebilen bir yapay zeka için bu gerekli değil.

Kodu kutssallaştırmayı bırakmamız gerekiyor. Başka bir devirde yaşadığımızı kabul edelim.

Belki de artık kodun nasıl göründüğünü daha az, müşterinin ne istediğini ve uygulamanın gerçekten o davranışı üretip üretmediğini daha fazla konuşmalıyız.

Yazılım dünyasına en büyük zararı veren şeylerden birisi reuse yani tekrar kullanım ilkesidir.

Her zaman “aman bir kere yazın, her yerde kullanın” dendi.

SRP – Single Responsibility Principle ın en büyük düşmanıdır.

Her projede mutlaka bir commons, core ya da sharedlibs isminde bir dizin vardır. Bir yerlerden bir commons-lib import edersiniz, çünkü içinde her şey vardır. 

Ufak bir değişikli olduğunda, her kullanıcı kırılır. SRP!

Benim de bu tekrar kullanım mevzusundan çok dilim yanmıştır. Neler yapmadık ki! 

Yapay zeka ile ben tekrar kullanılan uygulama parçalarından tamamen vazgeçtim, çünkü başıma daha çok iş açıyorlar. Ne gerek var!

Oluşturduğum platform içindeki 4-5 web bazlı uygulamada blog özelliği var. Hiç birinde ortak kullanmadım, her defasında tekrardan yazdırdım. Aslında bir kere yazdırdım, sonra “şuradan kopyala” dedim.

Ne gerek var ortak koda. Ortak blog komponenti kullanmaya kalksam, her bir kullanıcısına sıkı bir korzet giydirmiş olacağım. İstediğim şekilde değişiklik yapamayacağım.

Oysa neden ortak kullanım teşvik edilirdi? Maaliyeti düşürmek için.

Buna gerek kalmadı.

Hiçbir şeyi ortak kullanmayın arkadaşlar. Başınıza iş alırsınız ;-)

Çok uzun bir süredir yapay zekâ desteğiyle bir proje üzerinde çalışıyorum.

Düne kadar dünyam Codex, Claude Code, Opus/Fable, GPT Sol ve Astra’dan oluşuyordu. Sadece gereksinimler ve onların çalışır hâle gelmeleri benim için önemliydi.

Dün bu dünyayı bırakıp uygulamaların canlıya alınması için gerekli ortamı oluşturmaya başladım.

Orası bambaşka bir dünya.

Birden kullandığım araçlar ve problemlere yaklaşma tarzım değişti. Yapay zekâ orada da bana gerekli desteği sağlıyor.

Kod tarafında bir gereksinimin doğru uygulanıp uygulanmadığını konuşurken birkaç saat sonra yüksek erişilebilirlik, load balancing, replikasyon, yedekleme, DNS, SSL, monitoring ve felaket senaryoları üzerine düşünmeye başladım.

Aynı proje üzerinde çalışıyordum ama artık tamamen farklı bir disiplinin içindeydim.

Yapay zekânın asıl gücünün yalnızca daha hızlı kod yazdırmak olmadığını burada bir kez daha gördüm. Asıl güç, normalde birbirinden ayrı uzmanlıklar gerektiren dünyalar arasında geçiş yapabilmekte.

Bu alanlarda yapay zekâ öncesinde de çalıştım. Fakat şimdi yapay zekâ desteğiyle yapılması gerekenleri çok daha hızlı hallederek ilerleyebiliyorum.

Ama burada bana yine yön veren bu alanda daha önce edindiğim tecrübelerim. Bu tecrübeler doğrultusunda nokta atışı yapay zeka yönlendirmesi yapabiliyorum. 

Aslında daha önce edinilmiş bilgi ve tecrübe önemini kaybetmemiş oluyor. Aksine daha önemli hale geliyor, çünkü ortaya çıkan çözümü değerlendirmem ve revize etmem gerekebiliyor. Bunu sadece daha önceki tecrübe ve bilgimle sağlayabiliyorum. Burada yapay zeka benim daha hızlı hareket etmemi sağlamış oluyor.

Bence yapay zekânın gerçek etkisi de burada ortaya çıkıyor:

İnsanın yerine geçmiyor.

İnsanın farklı disiplinler arasında çok daha hızlı hareket edebilmesini sağlıyor.

En güçlü Anthropic modelleri bile kendi başlarına bırakıldıklarında vibe coding yapmaktan öteye gidemiyorlar.

Yalnızca bu modellerle yazılım geliştiren deneyimli yazılımcılar bile vibe coding yapıyor olabilirler. Çünkü bu modeller kod yazmaya odaklanmış durumdalar ve gereksinimleri derinlemesine analiz ederek eksiksiz bir şekilde koda dönüştürme konusunda yeterli değiller.

Bunu dengelemenin benim açımdan tek bir yolu var: Gerekli analiz ve review işlemlerini başka bir modele yaptırmak.

Ama hangi modele?

Yapay zekâ ile geliştirdiğim ürünlerde yalnızca Anthropic modellerini kullanıyor olsaydım, bu ürünler eksik ve hatalı olurlardı.

Benim için kodun yapay zekâ tarafından yazılıyor olması çok önemli. Ama bundan daha önemlisi, dile getirdiğim gereksinimlerin ne oranda implemente edildiği. Ne yazık ki bu konuda Anthropic modellerinden tam randıman alamıyorum.

Bu sebeple gereksinim analizi yapmak, çalıştığım Anthropic modelini gütmek için gerekli loop, plan ve promptları oluşturmak ve implementasyon detaylarını review etmek için GPT Sol ve Astra’yı kullanıyorum.

GPT bu sürecin içinde olmasaydı, ortaya çıkan uygulama benim belirlediğim gereksinimleri tam olarak karşılamayabilirdi.

GPT modellerinin analiz kabiliyeti, vibe coding yerine gereksinim odaklı çalışmayı

ve uygulamanın bu gereksinimleri karşılayacak şekilde geliştirilmesini sağlıyor.

Yapay zekâ, içinde her türlü aracın bulunduğu büyük bir alet kutusu gibidir.

Tecrübeli bir yazılımcı, yapmak istediği iş için doğru aracı seçer ve kullanır.

Buna karşılık yapay zekâyı bir çekiç olarak görenler, karşılaştıkları her problemi çivi sanmaya başlarlar.

Asıl mesele, aleti kullanabilmekten önce hangi problemin hangi araçla çözülebileceğini bilmektir.

Ustayla normal ölümlüyü birbirinden ayıran da budur.

Prompt engineering ile bir yazılımcının aynı anda sağlıklı biçimde yönetebileceği feature sayısı çoğu zaman üçü (3) geçmez. Bunun üzerine çıkıldığında context switch yazılımcının zihnini felç etmeye başlar.

Üstelik sorun yalnızca feature sayısı değildir. Yapay zekâ dakikalar içinde yüzlerce dosyayı değiştirebilir. Bu hız karşısında yazılımcının bütün kodu incelemesi, testleri değerlendirmesi ve her değişikliğin yan etkisini takip etmesi artık mümkün değildir.

Bu noktada yazılımcının görevi kodu satır satır kontrol etmekten çıkar; sistemin doğru yönde ilerleyip ilerlemediğini doğrulamaya dönüşür. Fakat bunun için ne yaptırmak istediğini baştan kesin biçimde tanımlaması gerekir. Çünkü sağlamayı yalnızca üretilen kod üzerinden değil; kabul kriterleri, testler, invariant’lar ve çalışan sistemin çıktıları üzerinden yapabilir.

Benim vardığım sonuç şu:

Loop engineering kullanmadan, loop planlarını nokta atışı hazırlamadan yalnızca prompt engineering ile uygulama geliştirmeye çalışan yazılımcı, yapay zekâ çağındaki darboğazın bizzat kendisidir.

Yapay zekâ kod üretimini hızlandırdı. Fakat yazılımcı hâlâ prompt yazıyor, ajanların açık loop’larını zihninde tutuyor ve ortaya çıkan değişiklikleri tek tek anlamaya çalışıyorsa eski çalışma modelini yalnızca daha yüksek hızda sürdürüyor demektir.

Yeni darboğaz kod yazmak değil; aynı anda yürüyen işleri anlamlandırmak, sınırlandırmak ve doğrulamaktır.

Eskiden kod yazarken en büyük bottleneck neydi?

Yazılımcı.

Şimdilerde yapay zekâ kod yazarken en büyük bottleneck ne?

Yine yazılımcı.

Çünkü bir yazılımcı onlarca ajanı aynı anda orkestre edemez. İki farklı feature üzerinde çalışan iki ajanı takip etmek bile ciddi bir context switch maliyeti oluşturur.

Her ajanın ne yaptığını anlamak, verdiği kararları kontrol etmek, ürettiği kodu doğrulamak ve diğer değişikliklerle çakışmadığından emin olmak gerekir.

Yapay zekâ kod üretimini hızlandırdı. Fakat insanın:

• dikkat kapasitesini,
• karar verme hızını,
• sistemi zihninde taşıma yeteneğini,
• doğrulama kapasitesini
• aynı ölçüde artırmadı.

Bu nedenle darboğaz ortadan kalkmadı; yalnızca yer değiştirdi.

Eskiden darboğaz, kodu yazabilmekti.

Bugün darboğaz, üretilen kod hakkında yeterince hızlı ve doğru karar verebilmek.

Bir ajanın bir saatte ürettiği kodu anlamak ve doğrulamak için yazılımcının iki saate ihtiyacı varsa, ajanın daha hızlı kod yazması sistemi hızlandırmaz. Sadece incelenmeyi bekleyen daha büyük bir çıktı kuyruğu oluşturur.

Dolayısıyla geleceğin problemi daha fazla ajan çalıştırmak değil; insanın sınırlı dikkatini tüketmeden ajanları koordine edebilecek yeni bir mühendislik katmanı oluşturmaktır.

Yazılımcı artık yalnızca kodun üreticisi değil. Niyetin kaynağı, kararların sahibi ve doğruluğun son hakemidir.

Yapay zekâ çağında kıt olan şey kod değil; insan dikkati ve mühendislik muhakemesidir.

Bir zihin düşünün. Sayısal düşünmeye yatkın ve mantık güdümlü. Matematik ve benzeri alanlarda oldukça iyi. Mühendislik eğitimi alıyor ve yıllarca yazılım geliştiriyor.

Böyle bir beyin, dünyaya teknik bir perspektiften bakmaya; her şeyi ölçmeye, karşılaştırmaya ve sınıflandırmaya koşullandırılmıştır.

Şimdi bu beynin yapay bir beyinle karşılaştığını düşünelim.

Bu yapay beyin, sözünü ettiğimiz gerçek beyinden bazı işleri daha hızlı ve daha iyi yapabiliyor. Örnek olarak kod yazmayı ele alalım. Yapay beyin, gerçek beyinden daha iyi kod yazıyor olsun.

Gerçek beynin buna tepkisi ne olur?

Lütfen cevap vermeden önce onun teknik koşullanmasını unutmayın.

Önce yapay beyni test eder. Yazdığı kodda hata arar. Yapamadığı şeyleri tespit etmeye çalışır. Başarısız olduğu örnekleri toplar. Onu bir kategoriye yerleştirmek ve sınırlarını çizmek ister.

Bunu yaptıktan sonra başka bir kulvarda yoluna devam etmesi gerekir, çünkü eski kulvarda yapay beyin ile rekabet edemeyeceğini idrak etmiştir. Yeni kulvarı bir üst soyutlama seviyesidir.

Bunu nasıl yapabilir? Perspektifini değiştirerek. 

Asıl problem bu perspektif değişimini yapabilmektir. Yıllarca teknik düşünme tarzına koşullanmış bir beynin perspektif değiştirmesi kolay bir şey değildir. Ama bu koşullar altında zaruridir.

Yıllarca yazılımcılar yazılım geliştirme süreçlerine teknik perspektiften baktılar. Neden bunu yapıyoruz sorusunu sormak yerine nasıl bunu yapabiliriz sorusuna odaklandılar. Şimdi nasıl sorunu daha iyi cevaplayan bir mekanizma mevcut: yapay zeka. Bu durumda geriye sadece ne ve neden soruları kalıyor.

Bu iki soru müşterinin gereksinimlerine işaret eder. Teknik perspektiften, müşteri perspektifine geçmek ve onun gereksinimlerini doğru soruları sorarak, anlamak yazılımcının kendi pozisyonunu koruması için atması gereken ilk adımdır. Zaten teknik perspektif ile nasıl sorusuna aldığı cevabı ölçebilecek konumdadır. Perspektifsel dönüşümü yaparak bir taşla iki kuş vurmuş olur.

İşte bu iki perspektifin birleşimi, yapay zekâ çağının yazılım mühendisini ortaya çıkaracaktır: Müşterinin dünyasını anlayabilecek kadar perspektif sahibi, yapay zekânın ürettiği çözümü değerlendirebilecek kadar teknik donanımlı bir mühendis.

Tipik bir vibecoder şu şekilde çalışır:

Problem → AI → Çözüm

Yapay zeka her problemi doğru çözme potansiyeline sahip değil. Bazen bir sorunun etrafında döndüğünü ve doğru çözümü üretemediğini görmek mümkün.

Bu sebeple basit işler için vibecoder belki istediği çözüme ulaşabilir, ama teknik anlamda çözüm geliştirme odaklı çalışmadığı ve bu konuyu tamamen yapay zekaya bıraktığı için kısa sürede karmaşık bir uygulamada çıkmaz sokağa girecektir.

Burada gerçek bir yazılım mühendisi ile vibecoder arasındaki farkı görebilmek mümkün, çünkü yazılım mühendisi şu şekilde düşünür:

Problem → Mühendisin zihinsel modeli → Olası çözümler → AI → Uygulama / doğrulama

Bunu bir adım öteye taşımak da mümkün. Yazılım mühendisi yapay zekanın takılıp, kaldığı, sürekli etrafında döndüğü ama çözüm bulamadığı problemler için de gerekli çözüm senaryolarını düşünebilir ve yapay zekayı bu yönde itebilir. Vibecoderin bu aklıma bile gelmez, çünkü teknik altyapısı buna izin vermez.

Bu konuya neden açıklık getirmeye çalışıyorum?

Ben yapay zeka konusunda ilk paylaşımlarımı 2 sene önce yapmaya başladığımda, gelen yorumların çok büyük bir kısmı bunun bir hype olduğu ve gelip, geçişi olacağı yönündeydi.

Şimdi gelen yorumlara bakıyorum. Çoğu kişi için durum çok net: yazılım mühendisliği bitmiştir ve herşeyi artık yapay zeka yapabilir.

Ben bu şahısların bu radikal sonuca tecrübeleri ile geldiklerini düşünmüyorum. Bu tür bir fikir, olup bitenlere dair yazılanlardan çok etkilenen ama kişisel olarak bu konuda geniş çaplı tecrübesi olmayan kişilere ait olabilir.

Gerçek anlamda yazılım ve yapay zeka araçlarına hakim birisi bu şahıslara ait söylemlerin zırva olduğunu bilir ve dikkate bile almaz. Asıl sorun bu değil. Asıl sorun, bu şahısların ürettikleri saçmalıkların yazılım sektörüne girmeye çalışan genç yazılımcı ve yazılım mühendislerinin kafasını karıştırma potansiyelidir.

Ekononik çalkantıları bir kenara bırakacak olursak, işini iyi yapan insanlar her daim hayatlarını idame ettirmek için gerekli kazancı sağlamışlardır. Nihayı amaç her daim yaptığın işte ileri seviye olmaktır. Bunu sağlayanların işsiz kalması söz konusu olamaz.