“Vibe coding” terimi mevcut durumu tanimlamak icin artik yetersizdir.

Genc yazilimcilar artik vibe coding yapmiyorlar, usta cirak iliskisi icinde gerekli tüm temel ve üst bilgiyi hocalarindan (AI) ögreniyorlar.

Bizim dönemimizde eksik olan usta-cirak iliskisi artik olusmus durumda. Genc yazilimcilari bu nimetten faydalanmalari yerine uyarmak anlamsiz. Yaptiklari vibe coding degil, yeni düzenin ögrenme süreci ve bu sürecin sonunda kendilerini iyi yetistirmis olacaklar.

Neden bu kadar genc yazilimcilara güveniyorum? Cünkü bir yazilimci meraklidir. Merakli olmayan birisi yazilimci olamaz. Bu merak onlari yapay zeka tarafindan olusturulan kodun nasil calistigini anlamaya istecek ve bu sekilde ögrenecekler. Imtihan icin kopya hazirlayan ögrencileri düsünün. Onlarin kopya cekme tesebbüsleri zaten gereken seyleri ögrenmelerini sagladi.

Bu sürece yeni bir isim konmasi gerekiyor. Genc yazilimcilara sadece vibe coding yapiyorlar demek artik dogru degil.

Peki vibe coding nedir? Hicbir yazilimci egitimi ve altyapisi olmayan ve daha önce kod yazmamis birisinin yapay zekaya kod yazdirip, programci oldugunu düsünmeye baslamasidir. Burada kisa vadece prototip ve mvp tarzi ürünler cikabilir lakin sürdürülebilirligi yoktur, cünkü yazilim sadece kod yazmaktan ibaret degildir ve ustalik gerektirir.

Sizce junior programcilar icin vibe coding yerine hangi terimi kullanabiliriz? Önerilerinizi bekliyorum.

Yazilim camiasindaki güncel gelismeler Alice harikarlar diyarinda gibi hissettiriyor.

Artik iki dünya olustu: analog yazilim, dijital yazilim.

Benim gibi uzun yillardan beri yazilim yapanlar analog yazilim dünyasinda yetistiler.

Bugün yazilima yeni basliyanlar, dijital yazilim dünyasinin parcasi olarak yetisecekler. Onlarin mevcut yapilara adapte olmalari cok daha kolay.

Birkac ay öncesine kadar “vibe coding” in yeni baslayanlar icin uygun bir yöntem olmadigi fikrine sahiptim. Bu fikrim son günlerde degismis durumda!

Genc arkadaslar: hic vakit kaybetmeyin ve vibe coding yapmaya baslayin. Sizler dijital native olarak bu yeni yazilim dünyasina dogdunuz ve orada yetiseceksiniz. Yaninizda artik tam tesekküllü ve dünyanin en donanimli yazilimci ustasi oturuyor. Size yazilimin nasil yapilacagini en kisa sürede ögretecek. Sürekli ona kod yazdirin ve anlamadiginiz yerleri sorun. Bizim yillar boyu calisarak ögrendigimiz konulari siz isik hizinda ögreniyor olacaksiniz.

5 yil icinde cok daha iyi programcilarin yetistigini görecegiz.

Bir girisimci olarak yazilim ekibimde yapay zeka ile calisma süreclerine hakim junior yazilimcilara öncelik verecegim. Onlarin yetistirilmesi ve konuya hakimiyetleri cok daha kolay olacak.

Senior programcilar analog yazilimdan dijital yazilima gecis sürecinde avantajli konumdalar eger bu degisimi kabul edip, yeni süreclere adapta olabilirlerse.

1990 yilinda kod yazmaya baslamis ve son 30 yildir profesyonel yazilimci olarak calisan birisi olarak sunun altini cizerek söylemek isterim:

“Yazilim konusunda ben bundan daha heyecanli bir gelisme yasamadim”

Benim 20 sene imperatif program kod yazdiktan sonra fonksiyonel proglamaya gecisim cok zor olmustu. Beynimin en son hücresi bile imperatif düsünmeyi yeglerken, artik bunu baska türlü yapiyoruz demek yeterli olmuyor. Insanin bu kemiklesmis düsünce sablonlarini asmasi cok zor.

Yapay zeka baglaminda günümüzde senior (10+ yil tecrübe) olan programcilarin da buna benzer bir problem ile karsi karsiya olduklarini düsünüyorum.

Vibe coding yapan ama yapay zeka araclarini kullanmayi ögrenmis junior programcilarin bahsi gecen eski dönem programcilarini solladiklarini görebiliriz.

Bu sebeple degisime karsi koymadan hizli bir sekilde adapte olmak gerekiyor. Aksi taktirde programciliktan ekmek yemek artik mümkün olmayabilir. Bunun ilk ibareleri uzun yillar programcilik yapmis senior programcilarin sektör degistirme ya da yönetim kademesine gecmeleri ile kendisini gösterecektir.

Code generation konusunda nereden nereye geldik…

• Üniversite yillarinda CASE araclari ile UML modelleri hazirlar ve tüm interface, dto ve entity gibi siniflarin otomatik olarak olusturulmasini saglardik.
• Corba ve IDL ile servis arayüzlerini (interface) tanimlardik, ORB üzerinden remote object ile iletisim icin gerekli lokal proxy stub kodu otomatik olusturulurdu.
• 2000 öncesi EJB döneminde local ya da remote interface siniflari olustururduk, implementasyonlarini EJB compiler/container kendisi yazip, kostururdu.
• AOP (Aspect Oriented Programming) ile aspektler yazardik, gerekli baglantilari olusturmak icin aop derleyicisi kod olusturdu ve derledi.
• Spring ile tüm konfigürasyonu xml dosyalarinda olustururduk, proxy implementasyonlarini ve enjeksiyonu Spring IOC container yapardi. Daha sonra anotasyonlar kullanmaya basladik, arka planda gerekli kod yine build ya da runtime icinde olusturulurdu.
• Mapstruct ile entity – dto mapping icin gerekli kodu yazmaya gerek kalmadi.
• Lombok ile tüm get/set metotlarindan kurtulduk.

Kodu generate ettirmek icin kod yazarken, simdilerde kod yazmadan gen ai ile tüm kodun olusmasini seyrediyoruz.

Bundan sonra ne gelecek?

Makina kodu yazmanin ne kadar zor oldugunu hatirlayalim. Assembly ile programcilikta büyük bir sicrama yasandi. Bu da yetmedi ve Fortran, C ve Java gibi diller ile daha yüksek bir soyutluk seviyesine cikildi.

Böyle bir sürecin aynisi yapay zeka kullanimi icin yasanabilir. Artik yapay zekanin ürettigi koda hakim olamayan programcilar icin yeni araclar gelistirilecek. Onlar yardimi ile yapay zeka kullanimi daha da soyutlanacak ve kontrol edilebilir hale gelecek.

Sistemsel olarak imperatif programlama ile yapay zekaya kodu nasil yazilacagini söylemek ayni seyler. Bu detaylarda kaybolmak anlamina geliyor. Oysaki deklaratif tarzda ne yapilacagini söylememiz yeterli. Gerisini kullandigimiz programlama dili, arac ya da yapay zeka halletmeli. Gelecekte daha cok imperatif araclar kullanarak kod yaziyor olacagiz.

Ben günlük islerimde IntelliJ / Android Studio ve Copilot Claude Sonnet 4.5 yapay zeka modelini kullaniyorum.

Zaman icinde kendim icin yapay zeka öncesinden cok farkli bir calisma modeli gelistirdim. Bu bir nevi yapay zeka kullanim klavuzu. Yapay zeka araclari gelistirildi lakin bunlarla nasil programci olarak calismamiz gerektigine dair bize bir kullanim klavuzu verilmedi. Herkes kendi basina bunlari kesfetmek zorunda. Bu konuya katki amaciyla kendi tecrübelerimi paylasmak istedim. Hep birlikte belki genel kapsamli bir calisma ve kullanim klavuvuzu gelistirebiliriz. Bu yazim benim icin bir nevi “programming best practices with ai” görevini görecek.

Yeni Soyutluk Seviyesi:
Eskiden programci olarak mimari, nesneye yönelik programlama, tasarim sablonlari gibi konularla istigal ederek, program gelistirirdik. Simdilerde daha yüksek bir soyutluk seviyesinde, yapay zeka ile gelen prompt engineering, context, mcp, token ve agent gibi yeni terminoloji, yöntem ve araclari kullanarak program yaziyoruz. Bu ister istemez program yazma tekniklerimizi, aliskanliklarimizi ve soyutlama yetimizi dogrudan etkiliyor. Burada atabilecegimiz en dogru adim soguk suya atlamak yani biran önce bu yeniliklere adapte olup, gerektigi sekilde hareket edebilmek olacaktir.

Dogru Model:
Ben gpt 5 ve türevleri ile cok saglikli sonuc alamadim. Gemini türü modelleri de denedim. Lakin Claude Sonnet 4.5 ile en iyi sonuclari aldim. Bu konuda herkesin LLM secimi yapilan isin baglamina göre degisecektir. Dogru modelin calisma verimliligini artirir, yanlis model ile calismak günün sonunda hicbir sey basaramamislik hissi birakabilir.

Copilot Ayarlari:
Copilot icin proje workspace icinde copilot-instructions.md isimli dosyada yapay zekanin islem yapmadan önce dikkate almasi gereken hususlari listeledim. Burada metotlarin nasil yapilandirilmasi gerektiginden, UI tasarimi, kullanilacak catilar, kod stili ve testlere kadar bircok konuda yapay zekaya yardim edici bilgiler vermek mümkün. Buradaki amac ciktinin daha deterministik ve belli bir yapida olmasini saglamak.

Prompt Mühendisligi:
Bir yazilim mühendisi artik bir prompt mühendisine dönüsmek zorunda. Ben bu tabiri cok hos bulmuyorum, lakin programcinin artik kendi anadilinde, gelistirilmesini istedigi uygulamanin nasil olmasi gerektigine dair en ince detaya kadar bunu net bir sekilde ifade edebilir ve kagida dökebilir hale gelmesi gerektigi zorunlulugunun oldugunu düsünüyorum. Yapay zeka ile interaksiyonda destan yazmaya gerek yok. Prompt ne kadar sade ise, o oranda ciktinin beklentileri karsiladigini gördüm. Buradaki en önemli nokta context olarak ifade edilen kapsama alaninin iyi tanimlanmis ve dogru verilerle doldurulmus olmasidir. Ben örnegin copilot ile calisirken her prompt icin gerekli siniflari, görselleri ve belgeleri context icinde tanimliyorum. Bu sekilde copilot ve dolayli olarak Claude Sonnet benim prompt icinde ifade ettiklerimi workspace icinde yer alan icerikle daha iyi eslestirip, yapilmasi gerekenleri tespit ettikten sonra, hayata gecirebiliyor.

Kisaca ne kadar prompt, o kadar köfte!

Prompt History:
Ben workspace icinde prompt.md isminde bir dosyada, kullandigim tüm promptlari tutuyorum. Aslinda güncel prompt icin aklima gelen ilk düsünceleri bu dosyaya eklemeye basliyorum. Ilk düzeltmelerden sonra promptu en güncel hali ile copilota veriyorum. Zaman icinde bu bir nevi dokümentasyona dönüsüyor ve günler sonra tekrar yazdiklarima göz atarak, nasil buraya geldigime dair saglam bir fikre sahip olabiliyorum. Bazen copilot ile olusan kodu revert / rollback yapiyorum. Bu gibi durumlarda da ayni promptu history dosyasinda lokalize ederek, yeniden kullanma sansim oluyor.

Architecture First:
Hicbir ön hazirlik yapmadan copilota kod yazdirmanin ismi vide coding. Bunun nereye varacagi malum. Bu sebeple yeni bir uygulamaya basladigimda kesinlikle yapay zeka araci kullanmiyorum. Uygulamanin temellerini kendi bilgi, tecrübem ve düsüncelerim dogrultunda elimle atmam gerekiyor. Bu sekilde ilk mimari ve katmansal yapi ortaya cikiyor. Akabinde yapay zeka olusan yapiyi kendi isinde kopyalarak, gerekli kod parcalarini olusturmasi daha kolay hale geliyor.

Building Blocks & Subprompting:
Ben bir uygulama özelligini (feature) yapay zekaya bir prompt ile yaptirmaya calismiyorum. Bu cok iyi sonuclar veren bir yöntem olmadi benim icin. Bunun yerine uygulama özelligini kücük parcaciklara bölerek, her parca icin bir prompt yaziyorum. Burada öncelik her zaman uygulama özelliginin temelini olusturan domain siniflari, veri tabani yapisi, repository ve servis siniflari gibi yapilari ortaya cikartacak temel promptlar araciligi ile uygulama özelliginin temellerini atabilmek. Temeller insa edildikten sonra yeni promplar ile kat cikilmasi yani istenilen türde bir uygulama özelliginin programlanmasi kolaylasiyor.

Gereksiz Muhabbet:
Copilot ile gereksiz yere “iyi yaptin aferin” yada “tesekkür ederim” gibi seyler yazarak sohbet etmiyorum. Bu tür geri bildirimlerin programci olarak size hicbir faydasi yok. Yapay zeka bu sebeple gereksiz yere enerji sarf eder ve siz de en kötüsü faydasiz bir islem icin token harcamis olursunuz.

Sürekli Commit:
LLM ile calismak klasik programlama mantigina aykiri bir durum. Programcilik mantik geregi deterministik ve yer yer idempotent olmak zorunda. Lakin ben ayni promptun ayni sonucu verdigine hic sahit olmadim. LLM’ler deterministik yapilar degil, istatistiksel yapilar, yani cikan sonuclar da ne yazik ki istatistiksel olabilirlik hesaplamalarina dayaniyor yani deterministik olamiyorlar.

Bunu bildigim icin her prompt öncesinde son yapilanlari korumak amaciyla git commit ile tüm degisiklikleri saglama aliyorum. Prompt sonrasinda olusan program parcalari hosuma gitmiyorsa, rollback ile cikis noktama geri dönüyorum ve promptu yeniden sekillendirip, devam ediyorum. Sonuc hosuma gittigi taktirde code review yaparak tekrar bir commit aliyorum ve bir sonraki prompta geciyorum.

Olmadiysa Rollback:
Biraz önce bahsettigim gibi LLM ciktilari deterministik degil. Bunun yani sira prompt ve context yetersiz kaldigi icin cikti istenilen türde olmayabilir. Bu durumda kodu degistirmek yerine rollback yaparak, sifirdan basliyorum. Kodu degistirmek ve calistirmaya calismak cok zaman kaybina sebep olabilir. Bu yüzden sifirdan baslayabilek her daim daha iyi bir opsiyondur.

Regresion Testing:
Eger promptlar ile test yazmiyorsaniz ya da yazdirmiyorsaniz, gecmis olsun. Er ya da gec kullandiginiz LLM daha önce yaptigi degisiklikleri ezecek ve calisir durumda olan program parcalari calismaz hale gelecektir. Buna programcilar arasinda regresyon – geriye gitme denir. Bunun icin özel bir test kategorisi bile vardir: regresyon testleri.

Ne kadar yapay zeka da dense, LLM bir yapay zeka olmakdan isik yili kadar uzak. Bu yüzden genis kapsamli degisikliklerde uygulamanin bazi bölümlerinde istenmeyen degisiklikler vücut bulmus olabilir. Bunlari tespit etmenin tek yolu, otomatik calisan testlerdir.

LLM’i sürekli refactoring yapan bir makina gibi görmek gerekiyor. Her prompt potansiyel bir refactoring. LLM istedigi sekilde kodu yogurur. Bunun mutlaka ve mutlaka yan etkileri olacaktir. Bunlari tespit etmenin tek yolu test yapmaktir.

Saglam bir test seti olmayan programcinin promptlar ile gelistiridigi bir uygulama canliya alindiginda en iyi ihtimalle deterministik olmayan davranislar sergileyebilirken, en kötü ihtimalle calismaz hale gelebilir. Bu sebeple her prompt mutlaka gerekli test setinin olusmasini mecbur kilmalidir.

Continuous Review:
LLM ciktisi bir kodun programci tarafindan iki sebeple gözden gecirilmesi yani code review yapilmasi gerekmektedir.

Ilk sebep kodun ne kadar gecerli oldugunun kontrolüdür. Kod genel gecerli kurallara uymadigi icin yeniden yapilandirilabilir. Bunun icin mutlaka bir code review yapilmasi zorunludur.

Ikinci sebep benim icin daha önemli bir sebep. Ben LLM ciktisi kodu okuyarak cok sey ögreniyorum. LLM tarafindan olusturulan kodun, bu gezegen üstünde yayasan tüm programcilarin acik kaynak olarak github ve co üzerinde tuttuklari kodlarin damitilmis hali oldugunu düsünecek olursak, her ciktidan cok sey ögrenmenin ne kadar enfes olacagi asikardir.

Her dönemi kendine has (bknz. Kant – Zeitgeist) bir ruhu, yasam ve calisma sekli var. Programcilar olarak yeni bir döneme girdik. Hizli adapte olanlar ayakta kalirken, digerlerine ne olacak bilinmez.

Özcan Acar
EOF (End Of Fun)

Kendi bindikleri dalı kestiklerini anladıkları için çark etmeye başladılar.

Yapay zeka yazılımcıyı ortadan kaldıramaz. Yazımcılar yapay zeka araçlarını çok iyi kullanır hale gelecekler. Senior olanlar junior olanların gelişimine odaklanarak usta pozisyonuna geçecekler. Çırak olan junior yazılımcılar ustalarından ve yapay zekadan bu işin nasıl yapıldığını öğrenip, kendileri de zamanı geldiğinde usta konumuna yükselecekler. Bu şekilde şimdiye kadar var olmayan usta-çırak ilişkisi oluşturulmuş olacak.

Sadece mevcut bilgi ve tecrübe seviyesini ölçmeye yönelik yazılımcı mülakatları sona erecek.

Artık adaylardan copilot gibi yapay zeka araçları ile sunulan bir fikir için çok hızlı ve çalışır bir protip (MVP) oluşturmaları istenecek. Birkaç saatlik bir zaman diliminde fikirden, çalışan ürüne kadar tüm yazılım yelpazesi ve adayın bu süreçte nelere hakim olduğu kontrol edilecek.

Böylece usta-çırak ilişkisi ile yetiştirilmeyen yazılımcılar için bunun önü açılmış oluyor.

Nasıl bir kalp cerrahi asistan doktor olarak yıllarca bir kalp operasyonunun pratik ve teorik eğitimini ustalarından alıyorsa, yazılımcıların da böyle bir ilişki içinde yetkinlik kazanmaları gerekir hale gelecek. Bunun olmadığı bir ortamda yetişen tüm yazılımcılar vibecoding ile mülakatta istenenleri yapabilir anca ne yaptıklarını açıklayamayacak halde olacaklar.

Artan yazılım talebi ile yazılımcılar bu işin kendi kendilerine öğrenmeye bırakılamayacak kadar kritik unsur haline geliyorlar. Yazılım bir zanaattır ve ustası tarafından öğretilmek zorunda.

Bknz: https://kurumsaljava.com/2012/05/08/programcilik-sanat-mi-zanaat-mi/

Yazılımda çevik olmanın tek yöntemi test yazmaktır. Yazılım projelerinin zaman içinde yeniden yapılandırılamayarak telef olmalarının tek sebebi test eksikliğidir.

Bknz: https://kurumsaljava.com/2012/04/05/cevikligin-boylesi/

Artık test yazmamak için hiçbir mazuriyet kalmamıştır. Claude Sonet 4.5 yeni bir API için 20 ye yakın entegrasyon testini 5 dakikanın altında olusurdu. O testleri yazmak günler ya da haftalar alabilir.

Test yazmamanın ana sebebi yani maliyetli olması nedeni artık ortadan kalkmıştır.

Çevik süreçlerinin oturamamasının da ana sebebi refactoring yapma kabiliyetinin geliştirilememesi idi.

Bu taktirde XP gibi çevik süreçlerin tekrar bir rönesans yaşaması söz konusu.