Yapay zeka ile degisen calisma tarzimi örnek olabilmesi acisindan sizinle paylasmak istiyorum.

Artik IntelliJ / Android Studio uygulamalarini yapay zekanin yaptigi degisiklikleri takip etmek icin kullaniyorum. Cogu zaman commit penceresindeyim ve üzerinde degisiklik yapilan ya da yeni eklenen dosyalari, ne yapildigini anlamak icin editörde acarak, inceliyorum.

Bir prompt ile aldigim netice tatmin edici ise, hemen bir commit ile workspace i temizliyorum, cünkü bir sonraki prompt hataliysa ve geri alinmasi gerekiyorsa, mevcut calisan koddan ayirt edilemeyecegi icin tehlikeli bir durum olusuyor. Bunun önüne gecmek ve yapilan islemleri birbirlerinden temiz bir sekilde ayirt edebilmek icin sikca commit yapiyorum. Feature tamamlandiginda git squash ile tek bir commite cevirip, pushluyorum.

Yapay zeka ile interaksiyonum sadece konsol üzerinden gerceklesiyor. Claude code cli kulaniyorum. Her uygulama katmani icin ayri bir workspace kullaniyorum ve her katman icin bir cli calisiyor.

Chatgpt desktop / web uygulama gelistirmek icin kullandigim ikinci yapay zeka araci. Onu gereksinim analizi icin kullaniyorum. Oradan cikan analizleri Fable 5 ile paylasip, implementasyonu yaptiriyorum.

Artik kod ve test yazmiyorum. Fable 5 in entegrasyon testleri ve birim testleri yazmasini istiyorum. Bunlara güvenmedigim icin onay / kabul testleri icin onay/kabul kriterlerini ihtiva eden specler hazirliyorum. Fable 5 bunlardan test kodu olusturup, kosturabiliyor. Böylece uygulamanin blackbox olarak test edilmesi ve onay/kabul kriterlerinin tatmin edilmis olmalari test baglaminda yeterli oluyor.

Yeni bir projeye basladigimda öncelikli bir programlama dil secimim olmuyor. Genelde Java, Typescript, Dart gibi dilleri kullaniyorum. Lakin calistigim alana göre bu degisiklik gösterebiliyor. Örnegin remote control amaciyla cihazlar üzerinde calisan agent uygulamalari icin Go dilini kullanmistim. Artik poligot olan ben degilim, yapay zekanin kendisi.

Bir problem ile karsilastigimda sorunu kendim cözmeye calismiyorum, debug yapmak gibi. Burada yine yapay zekaya gerekli talimatlari, loglari, olusan veri setini vererek, problemi analiz etmesini ve cözmesini istiyorum.

Yapay zekanin yaptigi her analiz sonunda cözümü ihtiva eden bir dosya olusturmasini istiyorum. Bu dosyalar belli bir dizinde toplaniyor ve kodun ve uygulamanin hafizasi haline dönüsüyor.

Yeni bir uygulama gelistirmek istedigimde, önce ilk modülleri elden programlayip, referans olacak mimari, modüler yapi ve teknik cerceveyi olustuyorum. Yapay zeka devreye girdiginde bu yapilari birebir kopyalamaya basliyor. Bu sekilde mimariyi ve kod yapisini belli bir cercevede tutmak mümkün oluyor.

Tamamen biraktigim aliskanliklarim:

– Kod / test yazmak

– Ide icinde ya da gradle ile testleri kosturmak

– Test driven development yapmak

– Debug yapmak

– Refactoring yapmak

Ben artik tamamen AI first güdümlü calisiyorum. Bu benim isin teknik tarafina degil, gereksinim analizi kismina odaklanmami mümkün kiliyor.

Kodun yapisina ve kalitesine dolayli olarak, olusturdugum cerceve dahilinde etki etmis oluyorum. Bu yüzden yapay zekanin olusturdugu kod hakkinda endisem olmuyor. Özetle kodun kalitesi, yapisi ve ne durumda oldugu konulari ile ilgilenmiyorum. Beni ilgilendiren tek sey onay / kabul kriterlerinin uygulama bünyesinde dogru bir sekilde vücut bulmus olmalari. Olusan uygulama benim icin bir blackbox ve icinde ne dolaplar döndügü, benim istedigim sekilde calistigi sürece beni hic ilgilendirmiyor.

Soru net olarak şu: 

LLM’ler programlamanın özünü mü değiştiyor yoksa bir sonraki soyutluk katmanına hazırlık mı?

Enformatik tarihine baktığınızda, bu sorunun cevabını net olarak görüyoruz. 

Bugünkü çalışma modeli:

Müşteri -> Gereksinim -> Programcı -> Prompt -> LLM -> Kod

Bir üstteki soyutluk seviyesi

Müşteri -> AI -> Ürün

Yanı ne olacak? Yeni soyutlama ya da sentez yapıldığında, alt katmanların üstü örtülür ve görünmez hale gelirler, çünkü onlara gerek kalmamıştır. 

Programcılık diye bir meslek kalmayacak. Doğal dili anlayan yapay zeka müşterisi ile küçük bir sohbet sonrasında istediği ürünü ortaya koyacak.

Şimdi kısa bir yazılım tarihine göz atalım.

Bit ve bytelar ile başlayan şey daha sonra makina kodu, assembly, c, java, çatılar, dsl, no-code ve llm olarak devam etti. Biz şu anda bu zincirin en tepesinde duruyoruz. Yani programcılığa en soyut seviyeden bakıyoruz.

Her seviye bizim program yazış tarzımız üzerinde etkili oldu. Çalışma tarzımız değişti, ama değişmeyen bir öz var. Kod yazıyoruz ama onun da şekli, şemali değişiyor. Yani kod yazmak işin özü değil. Değişmeyen o öz ne?

Programlama aslında kod yazmak değil, niyet ifade etmektir.

Kod yazma işini LLM’e bırakmak, işin özünden uzaklaştığımız anlamına gelmez. Aksine LLM bizi bu öze daha da yakınlaştırdı, çünkü artık alis harikalar diyarında vari istediğimiz herşeyi yapabilir hale geldik. Niyetimizi bir prompt ile çok daha net ifade etme şansımız var. Bir DSL (domain specific language) olan prompt insanın mantık ve doğasına en yakın olan bir yapı ve o bahsettiğim özde kalmanın en kolay yolu.

O yüzden asıl mesele kod yazmak mı yazmamak mı değil, işin özünden devam etmek mi, etmemek mi dir.

Not: Benim yazılarım daha çok işin epistemoloji tarafına dönüyor olacak. Szin için sıkıcı olmaya başladı ise, haber verin, bu konuda yazmayı bırakacağım :)

Yazlilm bir ontoloji olmaktan cikip, yapay zeka ile epistemoloji olma yoluna girdi. Teknoloji ve varligini konusurken (nasil programlanir, nasil calisir, framework nedir vs), onun yerine birdenbire bilinc nedir (skynet), LLM caginda bilmek nedir, uzmanlik nedir gibi konulari konusuyoruz artik.

Bu gecis artik ne yazik ki kolay degil. Bu yazimda teknolojik fay hatlarindan bahsetmistim:

Bu artik teknollojik bir fay hatti degil, baska bir yasam formuna evrilme. Bu konudaki düsüncelerimi sonraki yazilarimda aciklamaya devam edecegim.

Kusuruma bakmayin arkadaslar, ama büyük bir degisim icindeyiz yazilim camiasi olarak ve topyekün teknolojinin arkadasindaki epistemolojik sorulara yönelmemiz gerekiyor, cünkü mevzu artik teknoloji, onun kullanimi ve bu konuda ne kadar iyi oldugunuz degil. Cevap bulmamiz gereken sorular var. Bunlar:

– Uzmanlik nedir?

– Ben artik bir programci olarak kalabilir miyim?

– Rolüm ne olacak?

– Alan bilgisi mi önemlidir, kod bilgi mi?

– Yapay zeka caginda programci olarak nerede olacagim?

Ben sürekli bu konulara deginiyorum, deginmeye devam edecegim, cünkü bir cisim yaklasiyor ve kendim icin gecerli olmasa da sektör adin hazirlik yapmak gerekiyor. Nacizane tavsiyem mümkün mertebe hizli bir sekilde bu konularda fikir yürütmeye baslamak olurdu.

Artik kod yazmamiza gerek yok. Son 10 paylasimima bakarsaniz, yazdiklarimin ana temasi bu noktaya isaret etmektedir. Örnek olarak derleyicileri verdim. Bu konuyu biraz daha irdelemek istiyorum.

Bir derleyici ve bir LLM ayni seyler degiller, ama prensiplte cok benzer calisiyorlar. Ortak özellikleri ve farkliliklarina programci perspektifinden inceleyelim.

Programcinin yazilim konusundaki rolünün baska bir alana kaydigi konusunda hemfikir oldugumuzu düsünüyorum. Bu artik hic kod yazmamayi ya da cok az. kod yazmayi gerektiren bir degisim. Bana göre artik kod yazmaya gerek yok. Bazilarina göre var.

Derleyici-LLM analojisini yakindan inceleyim. LLM öncesi mekanizma su sekilde isliyordu: Programci -> Java kodu -> Derleyici -> Makina kodu. LLM’ler ile bu su sekilde degisti: Programci -> Prompt -> LLM -> Java Code -> Derleyici -> Makina kodu. Buna göre LLM artik yeni derleyici seviyesi.

Hem derleyici hem de LLM örneginde soyutluk seviyesi degisti. Derleyiciler ile makina kodu yazma zorunlulugu ortadan kalkti. Yani programcilar artik makina kodu yazmaz oldular. Bunun icin bir yüksek seviyeye gecerek, isteklerine Java ya da C gibi yüksek bir dilde ifade etmeye basladilar. Ayni sey yapay zeka kullaniminda da gerceklesti. Soyutluk seviyesi Java ya da C ile kod yazmaktan, ne yapilacagini LLM’lere söyleme seviyesine gecti.

Enformatik tarihi aslinda sürekli soyutluk seviyesinin yükselmesinin toplamidir.

Örnegin 1960 larin bir Assembler programcisi günümüz programcisina büyük bir ihtimalle sunu söylerdi: “siz modern programcilar artik programlama yapmiyorsunuz. Sadece mantigi tarif ediyorsunuz”.

1980 lerin bir C programcisi sunu söylerdi: “Java programcilari donanimdan bihaber.”

Günümüzde ise LLM’ler ile artik kod yazmiyoruz. Yapisal olarak bunlarin hepsi ayni kapiya cikiyor.

Tekrar derleyiciye dönelim. LLM ile derleyici arasindaki en önemli fark, derleyicilerin kod derlerken semantik bir garanti vermeleridir. Bu yüzden ciktilari deterministiktir ve hep ayni sonuclari verirler. Ama bir LLM icin bunu söylemek mümkün degildir. LLM bir sonraki token’in ne oldugunu hesaplar ve bu istatistiksel hesaplama her defasinda baska bir sonuc verebilir. Bu yüzden LLM bünyesinde formal bir dogrulama mantigi yoktur. Sonuc deterministik degildir. Ayni prompt degisik kod üretebilir. Ama cikan iki degisik sonuc yine de dogru olabilir. bu kismi biraz acalim.

Bir Java programcisi hayal edelim. Bu programcidan bir Spring boot uygulamasi gelistirmesini isteyelim. Bu programci 3 ay arayla ayni uygulamayi iki sefer sifirdan programlasin. Sizce bir derleyici gibi ayni kodu yazabilir mi? Ama emin olabileceginiz sey ne olacaktir? Uygulama cok degisik yapilandirilmis olsa bile, istedigimiz sekilde calisiyor olacaktir. LLM de zaten ayni seyi yapmaktadir. Her seferinde ayni prompt ile baska bir kodun ortaya cikmasi sorun teskil etmemektedir. Önemli olan semantik transformasyondur. Semantik anlamda kod benzer yapida oldugu sürecek, sonuc istedigimiz sekilde olacaktir.

Günümüzde LLM’lere karsi kullanilan deterministik olmadiklari argümani gecerli bir argüman degildir. Calisan bir kod icin LLM’in deterministik olmayisi önem arz etmemektedir. Ona kalirsa bir programci da deterministik degildir, ama her deneyisinde calisan bir kod üretebilmektedir.

Yine de derleyici ve LLM arasinda mutlak bir farklilik vardir. Derleyici kendi isini yapabilmesi icin kodun sekillendirilmis olmasi gerekmektedir. Yani derleyici cözüm üretemez. Ama LLM ona verilen bir prompt ile bir cözüm üretebilmektedir. Bu yüzden LLM sadece bir derleyici degildir, bir programci gibi cözüm gelistiren birseydir.

Bir feature implementasyonu öncesinde, ait oldugu alana ve hangi özelliklere sahip olmasi gerektigini daha iyi anlayabilmek icin gereksinim analizi ile basliyorum. Bunun gercek muhattabi aslinda müsteri. Lakin ben belli bir piyasa icin bir ürün gelistiriyorum ve bir müsteriye dogrudan erisimim olmadigi icin piyasa arastirmasi, ürün kiyaslamasi ve yapay zeka yardimi ile gereksinim analizi yaparak ilerlemek zorundayim.

Burada zaman icinde bir calisma sablonu olustu. Onu sizinle paylasmak istiyorum.

Claude modelleri teknik analiz konusunda cok iyiler. Özellikle mevcut kodu inceleme ve gerekli degisikliklerin nasil yapilmasi gerektigine dair nokta atisi analizler yapiyorlar. Lakin bir alana ait gereksinim analizinde Chatgpt’nin daha iyi oldugunu fark ettim. Onunla karsilikli dialog halinde bir konu üzerinde calismak cok daha kolay. Bu yüzden tüm gereksinim analizini onunla yapiyorum ve cikan analizi Fable 5 ile paylasiyorum. Eger gereksinim tam anlamiyla ve detayli olarak analiz edildi ise, Fable 5 bu analizi cok hizli bir sekilde, otonom olarak eksiksiz olarak koda dönüstürebiliyor.

Implementasyon sonunda olusan kodu Chatgpt ile paylasarak, kodun yapilan analizi ne kadar tatmin ettigini soruyorum. Bu sekilde ping-pong vari feature implementasyonu tamamliyorum.

Uzun bir zaman önce su an üzerinde calistigim ürünü gelistirmeye basladim. Ilk zamanlarda Github Copilot IntelliJ plugini ile auto complete yaparak ilerledim. O zamanlar bugünkü anlamda agentik bir yazilim modeli mümkün degildi.

Modeller iyilesmeye basladiktan sonra, takriben 1.5 sene önce Claude Sonnet 4.5 ile yazilimi tamamen yapay zekaya devreme sürecim basladi. Bu modellerin yetersiz kalmaya basladigini anladiktan sonra Opus 4.5 e gectim ve cok hizli bir sekilde üzerinde calistigim uygulamayi gelistirmeye devam ettim.

Gecen senenin agustos ayinda Opus 4.6 kullanmaya basladim. Bu bendeki yazilim konusundaki fikirsel kirilimin baslangici oldu. O noktadan itibaren isik hizi ile gelistirmeye devam ettim. Normal sartlarda aylar ya da yillarimi alacak olan modülleri sadece haftalar icinde hayata gecirmek mümkün hale geldi. Zamanim olmadigi icin ürüne dahil etmek istemedigim ve gelistirilmeleri karmasik ürünleri bile pipelinea alarak, devam ettim.

Cok uzun bir süre Github Copilot CLI ile calistim. 3-4 ay öncesine kadar hersey hizli bir sekilde ilerlerken, degisen kullanim ve fiyat politikalari ile bu araci kullanamaz hale geldim. Uzun bir süre buna dayanmaya calistim. Paramla rezil oldum. Haftalar süren rate limitler yedim. Opus 4.7 gelmesi ve Opus 4.6 nin devre disi birakilmasi ile isler daha da kötülesmeye ve ilk baslardaki heyacanim kaybolmaya basladi.

Iki hafta önce Copilot kullanmayi sonlandirdim ve Claude code ve max20 aboneligine gectim. Opus 4.8 ile orada tanistim ve Opus 4.6 dan cok daha iyi bir deneyim yasamaya basladim.

Bugün itibarei ile Fable 5 kullanmaya basladim ve ilk feature implementasyonunu yaptirdim. Gercekten de tadindan yenmiyor. Bu hizla düsündügümden daha kisa bir zamanda ürünü tamamlamis olacagim.

Ben bu satirlari yazerken Fable arka planda yeni bir feature implemente ediyor :)

Artik kod yazmaya gerek kalmadi söylemlerime sürekli dolayli ya da dogrudan itirazlar geliyor. Yani bir yerlerde mutlaka lazim olacaktir, biz yazmaya hazir olalim minvalinde söylemler genelde.

Hayir, kod yazmaya gerek kalmadi! Nedenini aciklayayim.

Ben ilk kod yazmama deneyimlerime Opus ve Sonnet 4.5 ile basladim. Sonnet bu konuda cok basarili degildi ve ben cogu yeri elden tamamlamak zorunda kaliyordum. Daha sonra Opus 4.5 gectim ve durum da daha da kod yazmamaya dogru gitti. Opus 4.6 ile durum tamamen degisti ve ben neredeyse %95 lere geldim kod yazmama isinde. Akabinde Opus 4.7 hayal kirikligi yaratsa da %90 larin üzerinde kodun yazilma isini ona biraktim. Simdi Opus 4.8 ile calisiyorum ve bu oran %100. Ilk promptu 4-5 gün önce verdim ve o günden sonra 1 satir kod yazmadim ve bu böyle devam ediyor.

Cogu programci kendisini kod yazmak üzerinden tanimladigi icin, LLM’ler ile kod yazmama olayi onlara bir tehtid gibi geliyor ve icgüdüsel olarak karsi koyuyorlar. Lakin durum cok farkli bir yere geldi, söyle bir örnek üzerinden aciklayayim. Artik hic kimse bir derleyicinin ürettigi assembler koduna bakip, bu olmamis, ben daha iyi yaparim demiyor. Herkes artik gözü kapali derleyicilere güveniyor. Iste yeni cagin derleyicileri LLM’ler.

Kod yazmak yazilimcilik mesleginin zaten cok kücük bir bölümü idi. Ana mesele her daim müsteriyi anlamak ve onun istedigi ürünü ortaya koyabilmektir. Bunu kod yazarak degil, cok büyük oranda cerceveyi tayin ederek yapiyoruz. Bu belli olduktan sonra, oturup kodu yazmak artik marifet degil. Artik bu sikinti da ortadan kalktigina göre, artik tamamen müsteri ve onun gereksinimlerine odaklanabiliriz.

Tüm yazilimi yapay zekaya birakmis birisi olarak, yetilerimin körelmemesi icin ne yapiyorum? Hicbir sey!

Yillar harcayarak kazandiginiz o yetiler kullanmadiniz diye kaybolmazlar. Bisiklet sürmesini ögrenmis birisi her daim o bisikleti sürecek yetiye sahiptir.

Yapay zekayi verimli kullanan bir yazilimci (senior) algoritmalari, veri yapilarini, mimarileri zaten bilen, kullanan, o konular hakkinda yeni gelismeleri takip eden birisidir. Kendisi artik algoritma yazmiyor olsa bile, algoritma okuyabilir, mimari olusturabilir vs.

Zaten ters mantik su degil mi? Ben neden artik algoritma yazma yetimi korumaliyim ki? Bunu benden cok daha iyi yapan bir arac var elimde, o yapsin! Ben zaten yaptiklarini okuyabilmek, anlayabilmek, degerlendirebilmek, cöpe atip, yeniden yaptirabilme yetisine sahibim. Neden ben daha iyi algoritma yazma cabasi icinde olmaliyim? Olmamaliyim!

Ayni zamanda hem cok iyi bir programci hem de cok iyi bir yapay zeka araci kullanicisi olmaniza gerek yok. Iyi programcilik vasfini artik yapay zekaya birakma zamani geldi. Siz yapay zeka kullanirken daha iyi bir programci olmaliyim fikrini tasimaya devam ediyorsaniz, kapasitenizin cok büyük bir kismini dogru yerde kullanmiyorsunuz demektir. Kullanmayacaginiz yetilere yatirim yapmak yanlistir. Bunun yerine bir metamorfik dönüsüm icinde yapay zekaya her alanda hükmetmek icin gerekli tüm yetileri kazanma savasi vermek daha mantiklidir. Gerekli yetiler artik iyi kod yazmak, algoritma kurmak, mimari olustmak degildir. Yeni yetiler gereksinim analizi, müsterinin isteklerini anlamak, yapay zekayi yönlendirmektir. Bu konularda uzmanlasmaniz gerekiyor. Digerlerini artik araclar cok daha iyi yapiyor. Orada gelistirebileceginiz kas kalmadi. Teknik konulara cok calisarak hipertrofinin size birseyler katmasini beklemeniz anlamsiz bir cabadir.

Bundan böyle bir satir kod yazmayacak birisinin iyi bir programci kalmasi fikri cöptür. Tabi ben burada yeni yetisen programcilardan bahsetmiyorum. Temeli saglam senior pogramcilar icin gecerli söylediklerim. Onlarin zaten dogalari geregi herseyi merak ettiklerinden, zevk aldiklari alanlarda (algoritma, mimari vs) kendilerini gelistirmeye devam ederler, cünkü bunu zorunluluk olarak degil, eglence olarak görürler. Benim bahsettigim konu daha ziyade, “illa A, B , C yetileriinin körelmemesi gerekir, onlar üzerine calis” deyiminin zirva olmasidir.

Marifet gereklilikleri görüp, onu tatmin edebilecek yeni yapiya dönüsmektir, aksi taktirde insan oldugu yerde sayar ya da biraz bundan biraz ondan yapar, ama tam anlamiyla calistigi alana hakim olamaz.

Bir ipek böcegini düsünün, ne demek istedigimi daha net anlayacaksiniz. Bir kelebek ayni zamanda bir kelebek, bir ipek böcegi ya da ipek güvesi degildir. Bir kelebek kelebektir, ama gectigi o sürecleri kendi icinde tasir. Kelebek artik ucmaya odaklanir, koza örmeye degil. Yapay zeka ile calismak isteyen bir senior programci da artik iyi bir programci olma derdinden vazgecmek zorundadir., cünkü artik programci degildir.

Siz hic iki yapay zekayi birbirine kirdirdiniz mi? Cok eglenceli.

Kirdirma biraz egzejere bir örnek oldu. Daha ziyade birbirlerinin saglamasini yapma diyelim buna.

Bir örnek üzerinden inceleyelim.

Prompt hazirladim ve bir feature icin Opus calismaya basladi. Isi netlestirmesi icin AskUserQuestion ismini tasiyan bir araci kullanmasini istiyorum. Bu durumda Opus varsiyamlar yapmak yerine bana sorular sorarak, analizinde ilerliyor.

Sordugu sorularin cevabini biliyorum. Sorulari bazen dogrudan cevaplamak yerine, bu sorulari ChatGpt’ye yöneltiyorum. Eger ayni fikirdeyse, sorun yok, ama farkli bir fikir ortaya cikiyorsa, bu sefer ondan aldigim bilgileri Opus’a veriyorum ve onun fikirini aliyorum. Eger temelde bir fikir ayriligi varsa, birbirerini yiyorlar tabi, ama bu cok ender olan bir durum. Aklin yolu bir oldugu icin cok hizli bir sekilde uzlasiyorlar.

Almanca’da bir deyim var: der klügere gibt immer nach -> akilli olan daha esnek davranir. Acaba bunu yapay zeka düstur edinmis olabilir mi? Cünkü cogu zaman ayni fikirde olmalari biraz garip, cünkü birbirlerinden haberleri yok, ayni kod baze üzerinde calismiyorlar, sadece fikirsel olarak tartisiyorlar. Bilemeyiz ;-)

Simdi yine reklam yapmaya basladi denecek, ama yine de söylemek zorundayim:

Opus 4.8’e hemen gecip, bütün yazilim sürecini ona devretmeyen

– Mevzuyu hala anlamamistir

– Hicbir AI tool tecrübesi yoktur

– Baska araclar (codex gibi) ile kötü tecrübesi olmustur ve AI olayini rafa kaldirmistir, cünkü daha iyisini kendisi yapabiliyordur

– Is yerindeki güvenlik politikalari (ona, biz de ne oldugunu anlayamadik henüz politikalari diyelim) yüzünden AI araclarini kullanamiyordur.

Eger sonuncu söz konusu ise, o isten hemen ayrilir, maas, muusa bakmadan yapay zekanin full entegre kullanildigi bir ise gecerdim. Ayni is yerinde daha yillarca kalarak, bu nimetlerden tamamen bihaber kalma ihtimali cok yüksek. Bindiginiz dali kesmek üzeresiniz.

Yazilimin Opus 4.8 ve henüz bizim görmedigimiz el altindaki modeller ile artik belli olan tek bir yöne dogru gidiyor: full automated autonom implementation by ghosts.

Bu terimi ben uydurdum, ama ne demek istedigimi anladiniz. Geriye sadece bu sistemleri yönetecek programcilara ihtiyac kaliyor. Onlar da masters of the AI ecosystem olacak, yani cok hizli bir sekilde o ekosistemlerin kullanimi üzerine ihtisas gerekli.

Eger bu yolda kendi basima nasil ilerlerim diyorsaniz, yol haritasi bu:

– Sokaga cikip, insanlari mesgul eden bir problem kesfi

– Claude code ve max subscription

– Sorunu cözmek icin opus 4.8 ile bir satir kod yazmadan ürünü gelistirme

– Ürünü hemen yayilabilmesi icin ücretsiz dagitma

– Ürün etrafinda hizmet sunma ve para kazanma.

Ben bunu yapiyorum su anda!

Hadi ürün tutmadi diyelim ki %99 tutmayacaktir, ama siz yapay zekanin bir kenarindan tutmus oldunuz ve bir ürünün nasil gelistirildigine uctan uca taniklik etmis oldunuz.

Ufak bir not daha düseyim: Burada vide coding mevzusundan bahsetmiyorum. Bunu yapabilecek kisilerin saglam bir enformatik altyapisi olmasi gerekiyor. Mühendisligini okumadiysaniz ya da yillardir programci olarak calismiyorsaniz, zaman kaybindan baska birsey olmazdi.

Söyle bir yazim var, okuyanlar bilirler: Programcilik sanat mi, zanaat mi?

Bu yazim LLMler ünlenmeden ve benim yazilim konusunda fikirlerim degismeden önce kale aldigim bir yaziydi. Ben yazilimi hicbir zaman sanat olarak görmedim. Yazilim ustalik gerektiren birsey ve bir zanaattir. Bazilarinin idda ettigi gibi siir gibi kod yazinca sair, yani sanatci, o kod da sanat eseri olmuyor. Sanatin islevi olmaz, ama kodun islevi var ve istenildigi kadar kopyalanabilir (reproduction), ama sanat eserlerinden genelde bir adet ya da cok az sayida vardir.

Simdi bu konuda fikrim kismen degismis durumda. Programcilik hala bir zanaat, lakin bu kisim LLM’e ve icinde bulundugu ekosisteme kaymis durumda. Bizler yazilimci olarak dirigent konumuna geldik. Ben burada kendimi bir ressam gibi hayal ediyorum ve önündeki bir tuvali (uygulamayi) istedigim firca darbeleri (promt) ile sekillendiriyorum. Bu baglanda yaptigim biraz sanati cagristiriyor. Ama sanat ile bagi sadece bundan ibaret. Bir dirigent olarak yine sistemi bir bütün olarak tasarlayip, calisir hale getirmem gerekiyor. Bu da yine bahsettigim o ustaligi ve beraberinde zanaat faaliyetini getiriyor. Yani yazilim yapmanin dogasi zanaattir.

Cok karmasik bir yapi üzerinde calisiyorsunuz. Yapay zeka (benim örnegimde opus 4.8) gerekli implementasyonu gerceklestirdi ve sonuc istediginiz sekilde olmadi. Ne yaparsiniz?

Örnek olmasi acisindan benim bu durumda nasil ilerledigimiz aktarayim.

Kesinlikle debug yapmaya baslamiyorum. Benim zihnim artik tamamen code first degil AI first olarak isliyor. Böyle durumlarda yeni bir prompt ile yapay zekaya durumu arastirmasini söylüyorum. Eger bu arastirma sadece kod bazinda olursa, yapay zeka hatayi bulamayabilir. Zaten bulabilme potansiyeli olsaydi, implementasyonu dogru yapardi.

Burada, olusan data set ile calismak daha mantikli. Yapilan islem sonunda veritabaninda birtakim recordlar olustu. Prompt yazarken hatayi net olarak tanimliyorum, akabinde “veritabaninda örnegin su ismi tasiyan bir ürün var, ama parcalari eksik, verilerden yola cikarak neden eksik oldugunu arastir ve hatayi cöz” diyorum.

AI first ile kastim bu; tüm kod yazma, hata bulma, debugging gibi islemlerin tamamen yapay zekaya devredilmesi.

Neden bu sekilde calisiyorum? Teknik taraf icin gerekli mental yükün altina girmemek icin. Ben zaten yapay zekanin yaptiklarindan eminim. Benim görevim sadece ortaya cikan neticeyi yani uygulamanin sahip olmasi gereken davranis bicimlerini check etmek. Hata buldugumda debug yapmaya baslarsan, o zaman olusan tüm yeni yapilara hakim olmak icin herseyin üzerinden gecmem gerekir ki bu da bende mental yükü artirir. Zaten debug yapmaya baslamak bile basli basina büyük bir mental yüktür.

Kodun nasil sekillendigi beni ilgilendirmiyor. Ben gerekli mimari cerceveyi olusturdum ve yapay zeka zaten bunlari örnek olarak yeni yapilari olusturacaktir.

Kisacasi bir ustanin isine karismamak lazim. Usta, bu calismiyor denilerek belki yönlendirilir ama kimse evine gelen bir tesisatci ustasinin problemi cözemedigi noktada eline onun cekicini alip, duvara delik acmaya calismiyor, öyle degil mi?

Günlük yasantimizda dogal olan yani bize dogal gelen sürecleri kendi calisma tarzimiza da adapte etmemiz gerekir. Eger yapay zeka ile calisiyorsam, tüm sorumlulugu ona birakmam gerekiyor. Elime cekici alip, bu olmamis diyerek, araya girmek isin mantigina aykiri.

Bu sebeple ya ai first ya da hic o topa girmeyeceksiniz.

Opus 4.8 ile calismak bir tuval üzerinde firca sallayan bir ressam gibi hissettiriyor. Bu his en son Opus 4.6 ile calisirken olumustu ve Opus 4.7 ile tamamen ortadan kaybolmustu.

Opus 4.7 ile teknik detaylara cok odaklanmak zorunda kalirken, Opus 4.8 ile yeniden tamamen, asil isim olan gereksinim analizi ve onun gerceklesmesine odaklanabiliyorum. Opus 4.8 ile bir seyi ikinci kez tekrar etmek ya da tamamlayici nitelikte tekrar tanimlamak zorunda kalmadim. Implementasyonlari nokta atisi yapabiliyor.

Opus 4.7 ile calisma performansim ve günlük islem kapasitem düsmüstü, cünkü istedigim sekilde ilerleyemiyordum. Opus 4.8 ile yine o eski akisi (flow) yakaladim ve saatlerin nasil gectigini farketmiyorum.

Opus 4.8, Opus 4.6 implementasyon yeteneklerinin ve Opus 4.7 analiz kabiliyetlerinin birlesmis hali.

Not: Eskiden Github Copilot CLI kullaniyordum. Github’un (Microsoft kaynakli) ucuklasan fiyat ve kullanim politikalari sonunda, yaka silkerek Claude Code ve max20 ye gectim. Verdigim en iyi kararmis.