Hangisi Daha Verimli

Hangisi daha verimli?

1. Frontend programcisi api gereksinimlerini backend programcisina delege ediyor ve IO veri yapilari üzerinde uzlasma saglamalari gerekiyor. Test, entegrasyon vs derken aradan uzun bir zaman geciyor ve api tam istenildigi sekilde calismayabiliyor. Bu beraberinde uzlasma seanslari getiriyor. Frontend programcisi backend ve api development konularinda kendisini tamamen saliyor ve UI harici bir is yapmiyor. Ayni sekilde backend programcisi asil gereksnimlerden bihaber api programlamaya devam ediyor ve gereksinimleri anlama konusunda frontend yazilimcisina bagimli hale geliyor.

2. Tek bir programci hem frontend hem de backend icin gerekli calismayi yapiyor ve ihtiyac duyulan apiyi client driven backend tarafinda olustuyor. Uzlasmak zorunda kaldigi birisi olmadigi icin client icin gerekli tüm apileri ihtiyac dogrultusunda olusturuyor.

Eskiden fullstack denen bir yazilimci tipi vardi. Full denmesine ragmen ekseriyetle frontend kismindan sorumluydu. Gereksinimleri anlama konusunda backend yazilimcisindan bir adim öndeydi, cünkü müsteriye ya da son kullaniciya daha yakindi. Lakin backend konsunda cok zayifti.

Fullstack rolü tamamen tarihe karismistir. Bunun yerine bir backend yazilimcisi her iki tarafida tek basina koordine edebilecek sekilde 2 numarali satirda bahsettigim sekilde sekilde fullstack calisabilir.

EOF (End Of Fun)

Konuyu Bilmiyorlar

Yapay zeka ile gelinen son nokta…

1. En radikal yazilimcilar yazilimi tam anlamiyla birakti ve sadece gereksinimlere ve testlere odaklaniyolar.

2. Is yerinde yapay zeka kullanmasi yasak olanlar gizli gizli kendi bilgisayarlarinda kodu yazdirip, google drive ya da baska bir storage üzerinden bu kodu alip, kopyala, yapistir yapiyorlar. Bunlar aslinda birinci grupta olan yazilimcilar.

3. Yapay zekayi kesfedenler. Onlar ya kisa zamanda 1. ya da 2. gruba terfi edecekler ya da bir ise yaramadigini düsünüp, vazgececekler. Vazgecmelerinin tek sebebi yazilim konusunda temelde yeterli olmamalari.

4. Isittileri kadar konuya vakif olan yazillimcilar. Bunlarin icinden 3. gruba dahil olma potansiyeli olanlar merakli olanlari. Merakli olmayanlar bu isi birakmak zorunda kalacak olanlar.

5. Hicbir seyden haberi olmayanlar. Onlara Cem Yilmaz’in bu skecini birakiyorum

Takım Olayı Bitmiştir

Bilyorum bunlar cok radikal söylemler, ama ben daha önceki yazilimci tecrübelerimi güncel tecrübelerimle kiyasladigim zaman ortaya ckan görüsler bunlar. Gülüp gecebilisiniz. Nasil olsa kisa bir zaman sonra kendiniz deneyimleyeceksiniz. Ben size hizlandirilmis halini anlatiyorum, yani spoiler :)

Simdi söyle bir sürecten geciyorum. Eskiden promptlarimin cok detayli, düsük cümlesiz, net ve acik olmasina dikkat ederdim. Zaman icinde bu dogrudan cümlesel bile olmak zorunda olmayan komutlara ya da kelime gruplarina dönüsmeye basladi. Ben cerceveyi yani contexti ne kadar net ifade edersem, o oranda yapay zeka benim isteklerimi yerine getirebiliyor, yani bunun icin komple cümlelere bile gerek yok. Benim ifadesel netligim ne kadar azalmis olsa bile, context icin gerekli bilgiyi sagladigim sürece yapay zeka benim cok iyi anlayip, isini yapabiliyor.

Simdi bunu eski proje hayatimdaki calisma arkadaslarimla olan iliskilerle kiyasliyorum da… Yahu bazen derdimizi anlatmak ya da anlamak icin göbegimiz catliyordu. Bu anlasma süreci yer yer cok zaman alici bir hal alabiliyordu. Simdi ise birkac kelime bile yeterli ki altinda cok karmasik bir problem olsa bile yapay zeka ne demek istedigimi anliyor ve isini hallediyor.

Sanirim yazilimda takim iside yavas yavas son buluyor. Artik tek bir yazilimci kendi ajanlari ile bir takim olusturacak, gerekmedigi sürece baska yazilimcilarla iletisim bile kurmayacak, cünkü buna zaten gerek yok. Tek isi müsteriyi anlamak ve onun gereksinlerini tatmin eden bir ürün ortaya cikarmaz.

Diyeceksiniz ki entegrasyonlarda mutlaka karsi taraf ile konusmak gerekiyor. Hayir gerekmiyor. Entegrasyonu yazilimcinin yapmasi gerekmiyor. Verin ajana kodu, o gerekli baglantiyi zaten kurar, eger kuramiyorsa Jira’da bir ticket acip, “sunu sunu söyle yapin, yoksa kullanilamiyorum abi” der.

Baska ne kaldi geriye iletisimi gerektiren? Ha su yönetici tayfasi var, her ise burnunu sokmaya merakli. Onlara zaten hicbir zaman gerek yoktu. Ilk onlar shutlanacak.

Bitti!

Test Edenler Kazandı

Ben sahsen “ben programciyim, test yazmam” diyen cok programci gördüm. Bunlardan hala cokca var.

Simdilerde ise bu programcilarin yapay zekanin ürettigi kodu test etmekten baska ellerinde hicbir secenek kalmamis olmasi ne kadar ironik degil mi :)

Test bilgisi, yetisi ve isteklilgi yazilimda her daim iyi yazilimciyi kötüsünden ayiran bir faktör olmustur. Yapay zekanin yazilimdaki hakimiye ile test konseptlarine hakim oanlar yine birkac adim öne gecmislerdir.

Güven İyidir Ama Kontrol Daha Iyidir

Güven iyidir, ama kontrol daha iyidir der almanlar.

Ben yapay zekanin yazdigi koda bakmiyorum, dogru yaptigina güveniyorum. Lakin kontrolü de elden birakmiyorum, ama bunu kodu okuyarak yapmiyorum. Kod okuyarak zaten hatalarin cok kücük bir kismi bulunabilir.

Ben yazilan kodu dolayli olarak kontrol ediyorum. Burada her uygulama özelligi icin onay / kabul kriterleri tanimliyorum. Daha sonra bu kriteleri yansitan given/when/then lerden olusan bir test spec yaziyorum. Akabinde yapay zekaya bunu test koduna cevirmesini söylüyorum. Cikan test kodu uygulamayi bir kara kutu gibi test ediyor ve dolayli olarak kullanilan her kod parcasi test edilmis oluyor.

Bunun sagladigi bir diger avantaj artik kirilgan test kodlari ile ugrasmiyor olmam. Söyle bir örnek vereyim:

@given:
Müsteri login sayfasinda

@When:
Ismini girdiginde

@And:
Sifresini girmediginde

@Then:
Lütfen sifrenizi giriniz hata mesaji gösterilir

Bu bir test spec. Buradan test kodunu yazip, uygulamayi blackbox olarak test etmek yapay zekanin görevi. Ben cok yüksek bir seviyede bir uygulama davranisindan beklentilerimi belirliyorum. Eger uygulama bu davranisi benim beklentilerim dogrultusunda saglayabiliyorsa, ona “aferin, yazdigin, kod calisiyor” diyorum. Testler calismiyorsa, “git suna bir bak” diyorum.

Yazilimci olarak benim artik isim:

– Kod yazmak degil,
– Onay / kabul kriteleri tanimlama,
– Bunlari ihtiva eden specleri yazmak,
– Test sonuclarina bakip, kodun islevselligini degerlendirmek

Gerisi yapay zekanin isi.

Not: %95 oraninda aferini hak ediyor :)

İpek Böceğinden Güzel bir Kelebeğe

Gelen bir soru:

Hocam selam bende bir yazılım geliştiricisiyim ve yapay zekayla kod yazma alanında uzmanlaşmak istiyorum bu konuda bana yardımcı olur musunuz? Ne yapmalıyım nasıl bir yol izlemeyim.hangi aracı kullanmalıyım gibi.suanda codex cli kullaniyorum. Şimdiden teşekkürler

Cevabim:

1. Kendine cok ama cok zor bir proje sec hemen, aylarini ya da yillarini alacak bir

sey olmali, bu bir startup projesinin baslangici olacak senin icin.

2. Codex i birak, onun yerine github copilot cli kur ve claude opus 4.6 kulanmaya basla, claude code da olur.

3. Hayattaki tek önceligin o proje olmali. Geriye kalan herseyi göz arti et, gece gündüz bu isle mesgul olur.

4. Yazilimi tamamen ona birak, bunun icin cok iyi bir yazilimci olman gerekiyor. Eger iyi bir yazilimci degilsen, yazdiklarimi unut ve önce iyi bir yazilimci ol.

5. Müsteri gereksinimlerine odaklan. Müsteri ne istiyor sorusunu kendine sor. Burada müsteri sensin yani yapay zeka senin isteklerini implemente edecek

6. Gereksinimleri yapay zeka yardimi ile analiz et. Ona detayli analiz yapmasini söyle ve tüm sorularini cevapla.

7. Ortaya cikan analiz dokümanini iyice oku ve anlamaya calis. Senin isteklerinle örtüsüyor mu? Ikisini esitleyene kadar gereksinim analizine devam et.

8. Gereksinimleri kücük parcalara böl ve yapmasi icin yapay zekaya ver. Cikan kodu ilk zamanlar kontrol edebilirsin. Ama ilk kod örneklerini ve mimariyi kendin olustur. Yapay zeka bunu kopyalayacaktir. Daha sonra kodla hic ilgilenme, yapay zeka yazip, dursun, sen sadece gereksinimlere odaklan.

9. Ciktiyi kontrol etmek icin onay kabul kriterleri ihtiya eden test specleri hazirla (given/when/then). Daha sonra yapay zekaya bu speclerden test kodu olusturmasini söyle. Böylece uygulamanin davranislarini test edeceksin ve kodu test etmene ya da anlamana gerek kalmayacak.

10. 6 ay icinde eski yazilimci kimligin tamamen sönmüs olacak. Simdi aynaya baktiginda karsinda müsteriyi anlayan, onun gereksinimlerine odaklanan ve onun istedigini masanin üzerine koyan yapay zeka hükümdari birisini göreceksin. Tebrik ederim, yapay zeka cagi icin gereklli transformasyonu sagladin. Ipek böceginden güzel bir kelebege dönüstün.

11. Kendine bundan sonra hangi ünvani vermek istedigine kendin karar ver.

Bakış Perspektifimizi Temelden Değiştirme Vakti

Artik yapay zeka destegi ile yapilan yazilimlari tam anlamiyla blackbox olarak görebiliriz.

Eskinden birim testleri yazarak uygulamayi whitebox iceriden test etme egilimi vardi. Bu cok anlamli sonuclar veren bir aktivite degildi, cünkü fake entegrasyonlar yapilarak test etmeye calismak bir hayal dünyasi kurmak ve beklentileri kontrol etmek gibi birseydi.

Bunun yerine onay/kabul testleri ile blackbox olan bir uygulamayi test etmek daha verimli sonuclar vermektedir. Bunun icin onay/kabul kriterlerinin tanimlanmis olmasi gerekliligi mevcuttur.

Kod birimlerini izole bir sekilde test etmek yerine bütün uygulama davranislarini test etmek daha güvenilir sonuclar almamizi saglamaktadir. Onay/kabul testlerinde kodun nasil olusturuldugu dikkate alinmaz, sadece uygulama davranislari test edilir.

Iste bizim bunu artik fabrika ayari olarak kabul etmemiz ve bu sekilde yapay zeka ürünü uygulamalari test etmemiz gerekiyor. Kodun yapisi artik önemli olmamali. O kod zaten referans mimari ve kod örnekleri ile programcinin tayin ettigi yönde implemente ediliyor olacak. Yani kod clean ya da baska birsey, hic önemli degil. O kod zaten belli bir standartta olacak.

Koddan artik basiminizi kaldirdigimizda yani bu kod nasil olmali fetisizminden kurtuldugumuzda, daha önemli bir soru ile mesgul olma firsati bulacagiz. Bu soru: “Bu müsterinin gereksinimi tatmin ediyor mu?”

Burada mind ve focus shifti görebiliyor musunuz? Bu bizleri yazilimci olarak cok baska ve bir o kadar da gerekli bir seviyeye cekiyor. Müsteri ne ister ve yaptiklarim müsteriyi tatmin etti mi sorularinin cevabini aramak bir programcinin asli görevidir, kodun siir gibi yazilip, yazilmadigi degil.

Artik yazilima bakis perspektifimizi temelden degistirme vakti gelmistir. Ironik olan bu degisimin kendiliginden gelmemis, yapay zeka tarafindan zorlanmis olmasidir. Eger yapay zeka tarafindan bu kadar zorbalanmamis olsaydik, bir bakis acisi degisimi hic bir zaman gelmeyecekti belki de. Iyi ki zorbalandik.

Ama kod yazmak önemli diyenlere son söz olarak sunlari aktarmak istiyorum. Projelerde senior olan tecrübeli programcilara bir bakin. Onlar zamanlarinin cok kücük bir kismini kod yazarak gecirirler ve cogu zaman sistem tasarimi, müsteri iliskileri, entegrasyon gibi konularla ugrasirlar. Kod yazmak yazilimin cok kücük bir kismi ve artik bu isi yapma zorunlulugumuz ortadan kalkti ve biz bosa düsen bu mental kapasitemizi yazilimi gercek anlamini teskil eden islere ayirabiliriz.

Bu bir hype, gelip, gecici diyorsaniz, sunu eklememe izin verin. Eski usül kod yazma devri gelip, gecmistir. Bu gercegi cok hizli bir sekilde icsellestirip, asil isimize odanlanmamiz gerekiyor. Asil isimiz her daim müsteriyi memnun etmekti, siir gibi kod yazmak degil!

Hiçbir Şey Artık Eskisi Gibi Olamaz!

Artik yazdigi koda bakmiyorum bile, cünkü benim stilimi ve olusturdugum mimariyi kopyaliyor. Onun yazdigi kodu benim yazdigim koddan ayirt etmek bile zor.

Iyi bir is ayrimi yaptik: ben gereksinimlere odaklaniyorum, o gerisini hallediyor.

Bu benim icin kötü mü ya da yazilimci yeteneklerimin körelmesine mi neden oluyor? Evet :) Atin ölümü arpadan olsun. Buraya kadarmis!

Bundan sonrasi nasil ilerleyecek? Ben sürekli token kontenjanimin azalmasi ile dertlenecegim, karmasik bir problemin ortasindayken sunucu baglantisi kopup, yapay zeka isi yarida biraktiginda yüregim agzima gelecek, tekrar online olmasi icin dua edecegim, yani onun varligina muhtac bir hale geldim.

Bagimlisi miyim? Hayir, ama is cikarmam gerekiyor. Onun calismasi lazim, yoksa tas devrine geriye dönerim.

Artik isik hizinda hayal bile edemeyecegim türde ürünler ortaya cikariyorum. Eskiden yillar alacak platform ve ekosistemler icin simdilerde haftalar ya da aylar yeterli. Bunun bedelini yazilimci yetilerimi kaybederek ödüyorum, ama umrumda degil. Aldiklarim kaybettiklerimden cok cok daha fazla.

Onsuz bir yazilim hayati düsünemiyorum. Eger birgün bu araci elimizden almaya kalkarlarsa, o zaman hapi yuttuk iste!

En gec iki nesil sonra hic kimse bir satir kod bile yazamayacak hale gelecek. Kullanilmayan kaslarin kaybolmasi gibi bu yetide kaybolacak. Hangi programci C++ ya da Java da yazdigi kodun bytecode ya da makina koduna dönüsmüs haline bakiyor ve bunu anliyor? Ayni sey bu dillerde kod yazmanin basina da geliyor yavas yavas. Hic kimse kod Java mi, C# mi bakmayacak bile, baksa bile anlamayacak, cünkü hic ögrenmemis olacak. Programcilik zanaati icin vahim ama yazilim ve soyutlama seviyesi olarak cag atlamak bu. Yasasin.

Bunu durdurmak artik imkansiz, cünkü cok sey cok hizli ve kisa zamanda degisti. Eskisi gibi olamam artik. Olmak da istemiyorum. Bana ne döngü, invariant, volatile ya da threadlerden. Canim cikmiyor muydu zaten deneme yanilma ile (debug yaparak) birseyleri kodlamaya calismak. Hangi kod parcasi ilk yazildigi hali ile calisti ki?

Simdi sadece ol diyorum, oluyor. Bu kadar!

Not: Programci olmak kadar güzel bir sey yok!

Yapay Yeka Neden Daha İyi Programcı Ya da Mevcut Programcılar Neden Yetersiz?

Ikisini kiyaslayarak ilerleyelim..

Yapay zeka milyarlaca parametrelik islem kapasitesi ile daha kolay bir mental model olusturabilir. Bir progracinin konuyu algilamasi ve buradan yola cikarak mental model olusturmasi cok zaman alir. Bu model cok eksiktir ve problemin her yönünü dikkat almis degildir. Bircok programci mental model olusturmak icin gerekli soyutlama yetisini tam olarak gelistirememislerdir.

Yapay zeka saniyeler icinde kod tabani icinde tarama yaparak, hem kodu anlar hem de metal modele eklentiler yaparak, zenginlestirir. Programcinin tanimadigi bir kod tabanini inceleyerek mental modele ulasmasi cok güctür, cogu zaman büyük resmin sadece bir kesitini görür ve o kesit üzerinde fikir yürütür ve mental model olusturur.

Yapay zeka paralel ajanlar yardimi ile cok karmasik bir problemi basite indirmek zorunda kalmadan islem yapabilir, cünkü genis tabanli parametrik islem kapasitesi bu karmasayi her yönü ile yönetebilir. Programci karmasik oldugununu düsündügü bir problemi böl ve yönet yöntemi ile cözmeye calisir. Nesneye yönelik programlamada oldugu gibi mevcut bir problemi en kücük parcalarina bölerek, duruma hakimiyet saglamak yeterli degildir. Bu lineer düsünce tarzi sadece bütünün parcaarina odaklanirken, aralarindaki iliski, durum ve interaksiyonu tamamen göz ardi eder ki asil karmasa buradan kaynaklanir.

Yapay zeka cok hizli ögrenirken, programcinin bilgi, yetenek ve becerilerini gelistirmesi zaman alir, cünkü cok uzun bir zaman ayni seyleri yapma egilimi gösterir.

Not: programcilar kötüdür demiyorum, sadece beseri olduklarindan yetersizlerdir. Bunu dengelemek icin daha fazla zeka fayda etmez. Dogal olarak lineer düsünmeye megil ettiginden, karmasik problemleri cözmekte cok zorlanir. Sabana kosulmus bir atin ya da öküzün tarlayi sürmekteki yetersizligi ne ise, programcinin da kod yazarak, karmasaya hükmetmeye calismasi odur.

Yapay zeka ile artik saban devri kapanmistir. Yapay zeka traktördür, direksiyonunda oturan da programci. Hangisi olmayi tercih edersiniz?

Neden Okumalıyız!

Günümüz yazilimcisinin hayatta kalma mücadelesini destekleyecek tek aktivite, soft skillerini gelistirmesidir. Bunun basinda iletisim geliyor. Iletisim icin de genis bir kelime hazinesi ve ifade gücü gerekli.

Kelime hazinesi nasil genisletilir ve iletisim becerisi nasil kazanilir?

Öncelikle sunu bilmek gerekiyor; düsünce ve hayal dünyasi kelime hazinesinin büyüklügü ile dogrudan orantili.

Sadece yeni kelime ögrenerek, iletisimi güclendirmek mümkün degil. Kelime hazinesinin ve dolayli olarak ifade gücünün artmasi icin hayata dair anlam cikarici iceriklerin tüketilmesi gerekiyor. Bunlarin basinda dogal olarak edebiyat ve felsefe geliyor.

Felsefeye yönelebilmek icin öncelikle edebiyat duragina ugramak lazim. Siir, roman ve benzeri icerikler anlam olusturma, hakikatleri kavrama ve anlam arama cabalarini sekillendirir nitelikdedirler.

Burada özellilkle Tolstoi, Dostoyevski, Gogol gibi yazarlar öne cikiyor. Yazdiklari hikayeler insanlarin zor sartlar altinda yasadiklari dönemlerde geciyor. Örnegin Gogol’un Paltosunu okuyan birisi, aslinda ne kadar büyük bir zenginlik icinde yasadiginin hemen farkina variyor. Ya da Tolstoi’un “Insan neyle yasar” hikayesi zor durumda olanlara yardim etmenin ve gercekleri yasayarak görmenin ne kadar önemli olduguna vurgu yapiyor. Bu tür icerikler hem insanin sükretmesini, hem kendisine ceki düzen vermesini hem de zihninde yeni anlamlarin olusmasini sagliyor ve bu dogrudan ifade gücüne yansiyor.

Anlam ve hakikat arayisi insani dogrudan felsefeye yönlendiriyor. Mevcudiyeti sorgulamak, hakikatleri anlamaya calismak, ölüm gercegi daha cok okumaya yönlendiriyor ve bu dolayli olarak kelime hazinesine ve ifade gücüne olumlu olarak yansiyor.

Okuyun arkadaslar. Okumak iyidir!

Kod Yazmak Hamalllıkmış

Yillarca kod yazarak hamallik yapmisiz. Bu yüzden yazilim teknikleri, metotlari vs gelisememis, ayni seyleri tekrar tekrar pisirip, önümüze koymuslar, biz yazilimcilar da hype dan hype a kosup, durmusuz, buna da yazilim demisiz.

Ben teknik nedenlerle problem yasamayan bir yazilim projesi görmedim. Her zaman sorun yazilimcinin kendisi olmustur. Verdigi yanlis kararlar, bilgi yetersizligi, over-engineering yapmasi vs gibi konular teknik borcu her daim artirmis ve projeleri isin icinden cikilamaz bir hale sokmustur.

Ucak kazalarinin %70 inden fazlasinin nedeni pilotaj hatalaridir. Yazilim projelerinde bu durum %90 ve üzeri ile yazilimcilarin kendilerine aittir.

Simdi yapay zeka destegi ile full insansiz yazilim yapilabildigi icin bu hata oranlari büyük oranda düsecek ve yazilim projeleri daha basarili sonuclar vermeye baslayacak.

Yazlimcilar isimiz bitte diye üzülmesinler. Hamalliktan sistemin olusumunu ve gidisatini belirleyen ve takip eden sahislara terfi ettiler.

Yeni Dönemin Programcilari

Yazilimda esas olan kurgu ve akistir. Genel hatlari ile verileri bagimliliklari ile birlikte kurgulayamazsaniz ve birbirleri ile olan iliskilerde veri akisini düzenleyemezseniz, uygulama ya istenileni yapamaz ya da sig bir sekilde yapabilir.

Bu temel prensipleri yapay zeka araclarini kullaniyor olsaniz bile degistiremezsiniz. Kisaca neyin nasil yapilmasi gerektigi hakkinda detayli bilginiz ya da fikriniz yoksa, sizi yapay zeka araclari bile kurtaramaz.

Buradan cikarilmasi gereken baska bir sonuc da, yapay zeka araclarini bilgisayar mühendisleri, yazilim mühendisleri ve yazilim konusunda tecrübeli insanlar haricinde kimsenin yazilim ile ilgi konularda verimli kullanamayacagidir.

Bu sebeple yazilim bitmemistir sadece baska bir seviye evrilmistir. O seviyenin calisanlari da eski düzende bu ise hakim olan yazilimcilardir. Diger tayfa zaten isin zorlugunu gördükce ve bu hype sona ermeye basladiginda cok baska islerle (bir sonraki hype) ugrasiyor olacaklar ve bu yazilim olmayacak.

Yapay Zeka ve Context Türleri

Yapay zeka araclari ile calisirken üc türlü context var:

1. Yapay zekanin kullandigi ve promptlar ile olusturulan context
2. Yazilimcinin birden fazla ajani paralelde ayni is üzerinde calisabilmeleri icin kendi zihninde olusturmak zorunda oldugu zihin contexti.
3. Beynin (lislemcinin) paralel calisabimek icin kulllandigi context ve onun icindeki context switch

Bahsettigim ikinci context sadece paralelde birden fazla ajanla calismak zorunda kaldigimda ne kadar SINIRLI oldugunu gördügüm bir yapi. Insan zihni multitasking icin yapilmamis. Birden fazla feature üzerinde paralel olaral degisik ajanlari koordine etmeye calistigimda, ajanlar arasi gidip gelmeler oldugu icin bu zihin contexti islemcideki (beynim) context switchlerden dolayi zor idare edilir hale geliyor.

Bu sebeple kullanmayi ögrendigim en saglikli yöntem önce prompt araciligi ile client tarafinin implemente edilmesini saglamak ve client ihtiyaclari dogrultusunda backend tarafindaki degisikllikleri yapmak. Bu sekilde zihin icindeki context akisi hep tek yönlü oluyor ve karisiklik olusmuyor. Ama birbirinden farkli iki feature üzerinde caliyorsam, bir noktadan sonra context switch nedeni ile gidisati saglikli bir sekide ayristirmam cok zorlasiyor.

Benim cikardigim sonuc su sekilde:

– Yapay zeka destekli calisildiginda bir feature icin genel bir plan olusturulmali.
– Bu plana sadik kalarak kücük kullanici hikayeleri (user story) olusturulmali.
– Her kullanici hikaye mümkün olan semantik (teknik degil) parcalara bölünmeli.
– Eger client tarafi varsa, oradan implementasyona baslanmali.
– Client gereksinimleri dogrultusunda backend implemente edilmeli.
– Backend kodu icin yapay zekadan entegrarasyon testleri yazmasi istenmeli.
– Ortaya cikan özelligi test etmek icin onay kabul kriterlerini ihtiva eden (user story ye eklenmis olmalari gerekir) onay kabul (acceptance test) testi yazilmali. Bu testi kesinlikle yapay zeka yazmamali. Burada bir test spec yazilarak, test kodun yapay zeka tarafindan olusturulmasi saglanabilr.
– Ayni anda sadece bir özellik üzerinde calisilmali.

Karmasik bir yazilim ürününü “aksam PRD verdim, sabah kalktigimda ürün hazirdi” vari implemente etmeniz imkansiz. Profesyonel yaklasim yüksek derecede organizasyon ve interaksiyon gerektiriyor. Bu isi otomatize etmeniz imkansiz, cünkü ifade ettiginiz gereksinimlerin yapay zeka tarafindan tam anlamiyla anlasildigindan emin olmaniz imkansiz. Buradaki ana sorun yine yazilimcinin hayal ve ifade kapasitesi.

AI Driven Development

Yapay zeka araclarini tam anlamiyla verimli kullandiginiz nasil anlarsiniz?

Flow olustugunda…

Ben örnegin bir kanatta ajanlarla bir flutter ve web uygulamasini gelistirirken, diger kanatta bunlarin ihtiyac duygugu apileri. backend icin baska ajanlarla olusturuyorum. Bu iki dünya arasinda gidis, gelisler bir flow hissi olustuyor yani dogal bir akis olmaya basliyor. Siz sadece yazilimci olarak gereksinimlere odaklaniyorsunuz ve bu perspektiften ajanlara yön vermeye basliyorsunuz. Onlarda size itaat ederek, ihtiyac duydugunuz yapilari dakikalar icinde olusturuyorlar.

Iste bu akiskan ilerleme hissi olusuyorsa, siz artik yapay zeka güdümlü (AIDD – AI Driven Development) yazilim yapiyorsunuz demektir.

Deterministik Yeti

Müsterinin gereksinimlerini tatmin etmek amaciyla yapay zekay kullanimina hakimiyet icin gerekli iki yeti:

– Müsteri gereksinimlerini kavramak
– Yapay zeka destegi olmasaydi bile bunlari uctan uca tek basina implemente edebilip, canliya alabilecek teknik yeterlilige sahip olmak.

Ilki ne yapilmasi gerektigini ve yapay zekanin nasil yönlendirilmesi gerektigi hususuna isaret ederken, ikincisi hayal ürünü olan ve hicten ortaya cikmis bir ürünü hayat vererek, onu müsterinin hizmetine sunabilmektir.

Yapay zeka ile calismak deterministik bir fonksiyon kullanimi gibidir. Yukarda belirttigim iki sabit ve degismez parametreyi bu fonksiyona her verisinizde, beklediginiz ciktiyi alirsiniz, yani bu iki deterministik parametre, deterministik sonuc üretir. Simdi neden vibe coding ile hicbir yere varilamayacaginin teknik sebebini biliyorsunuz.

Yapay Zeka Ile Uctan Uca Yazilim

Yapay zeka konusunda kemiklesmis, bilgi sahibi olmadan fikir beyan edisler artmis durumda. Burada konuyu biraz daha aydinlatabilmek icin kendi düsüncelerimi ve bu konudaki tecrübelerimi paylasmak istiyorum.

Ben yapay zeka araclarina hakimiyetin bastan sona ve uctan uca projeler gelistirildiginde olusmaya basladigini tecrübe ettim. Gecen seninin aralik ayindan itibaren Claude Sonet 4.5 i kesfetmem ile yazilimi tamamen yapay zekay birakmis durumdayim. Üzerinde calistigim proje cok genis kapsamli bir platform. Bir platforma dösünebilmesinde en büyük etken yine yapay zeka oldu, cünkü eskinden zamansizliktan dolayi hic baslayamayacagim alt projeleri kisa sürede yapay zeka yardimi ile tamamlayarak, istedigim platformu olusturmam daha kolay bir hale geldi. Bu proje bünyesinde en uctan (web, mobil) en dibe (backend) kadar her türlü yazilimi yapay zeka ile birlikte yapiyoruz. Bunun söyle bir avantaji var. Client neye ihtiyaci oldugunu beyan etmesiyle birlikte ben paralelde baska bir ajan ile backend kismndaki gerekli degisiklikleri yapiyorum. Yani backend icinde kafama göre birseyler implemente etmiyorum ya da ettirmiyorum. Olusan kodun tamamini client talep ediyor. Uctan uca bu sekilde hareket ediyor olmak yapay zekanin dogru kullanimini kolaylastiriyor, cünkü ben tamamen gereksinimlere odaklaniyorum ve yapay zekayi yönlendirmem yeterli oluyor.

Eger yapay zeka ile calisma yöntemini tam anlamiyla kavramak ve benimsemek istiyorsaniz, uctan uca bir proje yapmak zorundasiniz. Hello world vari backend api olusturmak ya da bir websayfasi tasarlatmak ile yapay zeka araclarinin özlerinde nelere kabil olduklarini anlamak imkansiz. Yapay zeka araclarinin iyi kullanan bir yazilimcinin yaptigi sey aslinda gereksinimlere odaklanmak ve teknik olarak yapay zekayi gütmektir. Gerisi zaten corap sökügü gibi gelir.

Sona Kalanlari Köpekler Isirir

Yazilimcilar yapay zeka konusunda bu aralar üc gruba ayrilmis duruma:

– Ilk deneyimini yaptiktan sonra bir ise yaramadigini düsünenler
– Hic ilk tecrübesi olmayanlar
– Yazillimi tamamen yapay zekaya devredenler

Ilk iki kesim genelde yapay zeka hakkinda yapilan olumlu yorumlara kendi olmayan tecrübeleri isiginda karsi koyuyurlar, yani ücüncü kesim bunlari ikna etmekle mesgul.

Soru su:

Bir devrim tamamlandiginda, dogru tarafta olmayanlarin basina ne gelir?

Almanca’da bir deyim var: “die letzten beißen die Hunde” (sona kalanlari köpekler isirir).

Nacizane, sona kalmayin derim.

Yapay Zekanin Maliyeti

Gecen ay Github Copilot icin 173 dolar ödeme yapmisim. Sürekli Claude Opus 4.6 kullandim. Yazilan kod 5 kisilik senior bir ekibin belki 2 ayda cikacagi türdendi. Bir senior yazilimcinin tüm giderleri ile maliyeti 200K TL civarinda. Bu durumda 2 milyon TL gider karsisinda 173 dolar duruyor. Bir girisimci icin bundan daha güzel bir gider azaltma kalemi , ama bir yazilimci icin bundan daha hüzünlü bir tablo olamaz, cünkü 5 kisilik bir senior ekibin calisma dinamigi, ruhu, pratigi ve eglencesinin parcasi olmanin karsiligini para ile ölcmek imkansiz.

Yeni düzen bu. Ne yapacagiz? Alisacagiz.

Prompt Engineering

Herkes prompt yazarken sade ve detayli bir dilin yeterli oldugunu düsünüyor. Prompt yazarken kullanilan dil ilk etapta cok önemli degil, yani gramatiksel kusursuz cümlelerin yazilmasi gerekmiyor. Daha önemli olan sey baglam yani context. Context yapilacak is hakkinda plain text haricinde resim, url, kod, video, teknik terimler vs gibi yapilacak ise isaret eden yapilar ihtiya etmek zorunda.

LLM’i karanlik odada duran bir cisim gibi düsünün. Size dogru sonuclar verebilmesi icin o odayi aydinlatmaniz gerekiyor. Bu sadece context üzerinden ve onun nasil yapilandirildigi ile ilgili bir durum. Ona siir okuyarak nereye varabilecegimiz asikar. Ama devrik cümlelerle bile yarim yamalak teknik cerceveyi tanimlamak yeterli olabilir.

Bu yüzden prompt engineering denilen seyi en iyi yine yazilimcilar yaparlar, cünkü yapilan isi teknik olarak en iyi onlar ifade edebilirler. Vibe coding yapanlari üzdügüm icin tekrar kusuruma bakmasinlar. Yazilimci kimligine bürünemeden ürün cikarmaya calismak abesle istigaldir.