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)