Yazilim yaparken tek darbogaz her zaman insanin kendisiydi.

Eskiden yazilimcilar kod yazmaya yetisemezken, simdilerde kod review yapmaya ve yapilan degisiklikleri takip etmeye yetisemiyorlar.

Kendimden somut bir örnek vereyim. Dünden beri codex + opus tam otonom iki büyük uygulama özelligini loop engineering yönetimi ile implemente ettiler. Test edilecek 30 dan fazla testcase olustu. Yüzlerce yeni sinif ekledi, binlarce satir kod olustu. Simdi kara kara “bunu da nasil otomatize edebilirim” diye düsünüyorum. Code review tarafi beni ilgilendirmiyor. Testcase’lere odaklanmam lazim.

Her test sonrasinda opus’a “su eksik, bu calismiyor, sunu tamamla” demek istemiyorum, cünkü onunla interaksiyona girdigim andan itibaren yine basinda oturmam gerekiyor. Bu artik yapmak istemedigim birsey. Bu yüzden yine loop engineering metodunu kullanarak, testleri birbir yapacagim ve buldugum hatalari codex’e yeni loop planlari olusturmak üzere bildirecegim. Testler tamamlandiktan sonra yine bu ikili benim yazdiklarim araciligi ile eksikleri giderecekler.

Yani loop engineering sadece otonom kod yazdirmak icin degil, cikan sonuclari da tekrar test ederek, iyilestirmek icin kullanilabilecek bir yöntem.

Biraz yazilimdaki kültür degisiminden bahsedlim mi?

Ben eski programci günlerimden iyi hatirliyorum. “Ben kod yazarim. Gereksinimleri baskalari yapsin. Testleri QA ekibi halleder, ben testci degilim. Dokümentasyonu baskalari yapar” diyen bircok insanla birlikte calistim.

Nereden nereye? Simdi ne yapiyorlar acaba?

Eskiden, benim cok tasvip etmedigim bir görev dagilimi vardi. Bu yazilimda silolasmayi beraberinde getirdi ve silolar arasindaki iletisimi saglamak icin bürokrasiyi artirdi. Ben bunu kulaktan kulaga oyununa benzetiyorum. Müsteri birsey istiyor, birisi bunu birisinin kulagina fisildiyor, o baska birinin kulagina derken, fisiltilar en sonunda isi yapacak olan programcilarin kulagina kadar geliyor. Artik gerekli bilginin ne kadar kisminin programci ekbine ulastigini siz düsünün.

Ben sadece kod yazarim diyen programci devri bitmistir. Bir LLM saniyeler icinde binlerce satir kod olusturabilir, test yazabilr, dokümentasyon ve gereksinim analizi yapabilir.

Bunlarin hepsini yapay zeka yapabiliyorsa, yazilimci icin ne kaliyor? O eskiden algoritmalar, tasarim sablonlari, cevik yazilim, clean code, microservice diyerek kendinden gecerken, simdilerde hangi alanlarda kendisini ve yeteneklerini gösterebilir? Kendisine yeni bir faaliyet alani bulmasi gerekiyor.

Geriye ne kaliyor sorusuna verilebilecek en iyi cevap:

En önemli sey -> Gerensinim analizi

Cünkü yapay zeke yanlis problem icin mükemmel bir cözüm gelistirebilir. Önemli olan ona dogru problemi aktarabilmektir.

Yazilimcinin isini yapabilmesi icin kendisine sormasi gereken soru degisti.

Eskiden: Bunu nasil implemente edecegiz?

Simdi: Tam olarak ne yapmak istiyoruz? Hedefimiz ne?

Artik yazlimci zamanini kod yazarak ya da okuyarak gecirmiyor. Daha ziyade alani anlamak, gereksinimleri toplamak ve analiz etmek, sürecleri tasarlamak, kullanici davranislarini kestirmek gibi konular onun ana calisma sahalari haline geliyor

Isin en trajik tarafi da bu zaten. Programcilar yillarca bu soft skilleri göz ardi ettiler. Gözleri koddan baska birsey görmedi. Bu yüzden programcilarin cok büyük bir kismi bu yeni dönem icin gerekli donanima sahip degiller.

Bahsi gecen yeni görevlerde en etkili soft skill iletisim yetisi. Artik en iyi kod yazan degil, gercek dünyayi en iyi sekilde modelleyen kazaniyor.

Buradan cikaracagimiz baska bir sonuc daha olabilir. Gereksinim analizi aslinda ögrenilmesi gereken bir sonraki programlama dili.

Yazilim artik implementasyondan spesifikasyona dönüsen bir sürece girdi. Bugün gereksinim analizi benim isin degil diyen, yarin bunun en önemli mevzu olmus olduguna sahit olacak.

Simdi loop engineering icin gerekli, full otonom calisan bir setup nasil kurulur, ona deginmek istiyorum.

Cikis noktam yeni bir modül. Cok genis kapsamli oldugu icin gpt 15 loop plani olusturdu. Normalde ben her plani alip, elden opus’a verip, gelen sorulari gpt’ye aktarip, is bittikten sonrada gpt’nin analiz etmesini istiyordum. Bu 15 plan icin 2 gün sürecek bir islem gibi görünüyor, o yüzden benim aradan cekilerek, gidisati otomatize etmem gerekiyor diye düsündüm. Bu setup icinde gpt ve opus’un yapilacak isi koordine etmeleri gerekiyor. Ama gpt’nin dogrudan opus’a is verebilme kabiliyeti yok.

Ikisinin ortak calisabilmesi ibir shared memory olusturmak gerekiyor. Bunun icin herhangi bir dosyayi kullanabiliriz. Üc adet dosya var:

• LOOP.md: Güncel ve islem gören loop planin yer aldigi dosya
• LOOP-PLANS.md: Bütün planlarin yer aldigi depo
• AI-HANDOFF.md: Gpt ile opus arasindaki koordinasyonu saglayan dosya

Gpt ve opus’un bu ortak dosyalari okuyabilmeleri icin bir nevi dosya iceriklerini check edebilecekleri cronjoblara ihtiyaclari var. Her ikisinde de bu mekanizma mevcut. Aktif edilmesi gerekiyor. Ayrica AI-HANDOFF.md dosyanin icerigi ikisinin anlasabilecekleri bir protokol ihtiva etmek zorunda. Bu yapiyi daha sonra aktaracagim.

Sürec su sekilde isliyor:

• Alan analizi sonunda olusan tüm loop dosyalarini gpt LOOP-PLANS.md dosyasina aktariyor.
• Akabinde ilk loop planini alip, LOOP.md dosyasina yaziyor. Bu dosyada sadece bir adet güncel ve opus’un üzerinde calistigi bir loop plani yer aliyor.
• Gpt AI-HANDOFF.md dosyasi durum statüsünü Status: READY_FOR_OPUS olarak degistiriyor. Bu opus icin baslama sinyali.
• Opus ise basladigi andan itibaren statüyü OPEN olarak degistiriyor. Isini tamamladiginda bu READY_FOR_CODEX_REVIEW’ye dönüsüyor. Eger konu hakkinda sorulari olursa, bu sorular icin hazirlanmis olan bölüme yaziyor. Soru bölümünde her soru icin yine bir STATUS alani mevcut. Yeni bir soru gelirse statüsü OPEN, bu soru gpt tarafindan cevaplandiginda ANSWERED oluyor.

Bu sekilde gpt ve opus AI-HANDOFF.md dosyasi üzerinden bir loop icin gerekli tüm interaksiyonu saglayarak, gerekli interaksiyon, review ve test islemlerini yapabiliyorlar.

Bir loop plani tamamlandiktan sonra statüsü DONE olarak degisiyor. Bu durumda gpt LOOP.md dosyasindaki icerigi silerek, LOOP-PLANS.md dosyasinda aldigi yeni bir loop plani buraya yerlestiriyor. Yeni loop planin statütüsü READY_FOR_OPUS olacagi icin opus bir sonraki cron uyanisinda bu loop plani üzerinde calismaya basliyor ve döngü bu sekilde tüm loop planlari tamamlanana kadar devam ediyor.

Her loop plan tamamlandiktan sonra gpt LOOP-TESTING.md dosyasina bu loop planini elden nasil test edecegime dair bilgileri ekliyor.

Bundan sonraki adim bir PLAN-SYSTEMS.md olusturup, bir uygulamanin tüm modülerini otonom insa ettirmek olacak. Ondan sonra PLAN-OS.md, PLAN-WORLD.md, PLAN-UNIVERSE.md seklinde devam edecegim ;-)

Loop engineering insan ve LLM arasindaki yazilim konusundaki is birliginin ilk neslidir. Daha önce gelen hersey teknik hazirlikti.

Aciklayayim.

Nasil programliyorduk?

Fikir -> Kod -> Derleyici – Testler

Yapay zeka ile nasil calismaya basladik?

Fikir -> Prompt -> LLM -> Kod

Bu noktadan itibaren programci deklaratif calismaya basliyor. Sadece ne istedigini ifade ediyor ve nasil cevabini LLM veriyor.

Loop engineering ile ne degisti?

Analiz -> LLM – > Review -> LLM -> Review -> LLM

Bu noktadan itibaren programci ve LLM birlikte düsünce seviyesinde hareket ediyorlar. Tanimli bir döngü ayni zamanda bir geri bildirim döngüsü olusturuyor ve programci ile LLM birbirlerinden ögrenmeye basliyorlar.

Burada atilacak bir sonraki adimi belirleyen yine programci oluyor.

Loop engineering son durak degil. Loop engineering sonrasinda ne gelecek?

Simdiye kadar gördügümüz calisma modeli su sekilde:

Insan -> LLM

Bu yerini

Insan -> Amac

modeline birakacak ve sistem kendi icinde gerekli organizasyonu yapacak. Söyle ki:

Amac -> plan yapan ajan -> implementasyonu yapan ajan -> test eden ajan -> durumu degerlendiren ajan -> refactoring yapan ajan -> dokümentasyon yapan ajan -> döngüyü yeniden baslatan ajan.

Bu sürece insan sadece ondan bir karar vermesi beklendiginde dahil olacak.

Bu noktada artik loop engineering terim olarak yine LLM dünyasina kaymis oluyor, cünkü insan aradan cekiliyor. Bu noktada olusan yapiyi

> Autonomous Engineering

olarak isimlendirebiliriz.

Görüldügü gibi insan perspektifinden artik mevzu sadece yazilim degil. Asil mevzu ne gerekl oldugunu idrak etmektir. Bu sekilde neyi tayin etmemiz gerektigini bilerek, nasil sorunu tamamen göz ardi edebiliriz.

Programci artik kod yazan bir ara varliktan, amaclari tanimlayan bir varliga dönüsüyor. Büyük bir ihtimalle buna bile gerek kalmayabilir. Amac yerine degerlere odaklanmak yeterli olacak, örnegin güvenli, anlasilir, yüksek performansli, ucuz, bakimi kolay gibi degerler. Bunlar tanimlandiktan sonra sistem (LLM ve ekosistemi) bu degerlerie yaklasan en iyi sistemi olusturma döngüsüne girecek ve en iyi cözümü bulana kadar devam edecek.

Eger istikrarli bir sekilde bu yolda devam ettigimizi düsünecek olursak, Epistemic Engineering diyebilecegimiz bir kavrama dogru evriliyor olacagiz.

Loop engineering ile hala isin icinde bir programci gidisati sekillendirirken, Autonomous Engineering ile insan aradan cekilmis olacak. Bir sonraki adim olan Epistemic Engineering seviyesinde asil yetkinlik artik yazilimi bizzat gelistirmekten degil, insan ile yapay zekanin birlikte yazilim hakkinda giderek daha derin ve daha dogru bilgiye ulasmasini saglayacak bir süreci tasarlamaktan gecer. Ben buna yazilim epistemolojisi diyorum ve yeni dünyanin programcilari da benim icin birer yazilim epistemologlaridir.

Gelelim refactoring konusuna. Programci iken en sevdigim konulardan birisi idi.

Refactoring ile kodun yeniden yapilandirilmasini kastediyorum. Refactoring her daim yapilabilecek bir aktivite degildir. Yapilabilmesi icin yerine getirilmesi gereken cok önemli bir sart bulunmaktadir. Test mevcudiyeti.

Cevik olmanin temelini aslinda refactoring dedigimiz aktive sagliyor. Onun icin de testler lazim. Bu yazimda buna deginmistim.

Simdi yeni bir savim var:

> Loop Engineering mimari seviyede yeni refactoring yöntemidir.

Bu tezimi aciklayayim.

Yapay zeka öncesinde nasil refactoring yapiyorduk?

Kod

↓

Testleri kostur

↓

Kodu degistir

↓

Testleri kostur

↓

Kodu degistir

↓

Testleri kostur

Testler burada imdat simidi görevi görüyorlar. Onlar olmadan kod degisikliklerin yan etkilerini yakalamak imkansiz. Bu yüzden code coverage yüksek olmak zorunda.

Martin Fowler refactoring yöntemini su sekilde tanimliyor:

> Davranisi degistirmeden ic isleyisi degistirmek.

Bu yüzden zaten yillarca interface siniflar ve onlari implemente eden somut siniflari gelistirdik, cünkü isleyisi degistirmeden ic davranisi yeni bir somut sinif implementasyonu ile degistirmek mümkündü.

Yapay zeka ile durum degisti. Artik Opus benim icin gerekli refactoring islemini yapiyor. Ben artik herhangi bir sinifi refactor etmiyorum. Opus araciligi ile tüm bir sistemi refactor ediyorum.

Refactoring islemini loop engineering ile nasil iliskilendiriyorum?

Bir loop plan yapisina bakalim:

Analiz

↓

Plan

↓

Implementasyon

↓

Test

↓

Review

↓

Eksik ya da problemi yerlerin tespiti

↓

Tekrar analiz

Bu döngü refactoring döngüsüne cok benzemiyor mu? Tek bir farki var. Eskiden. bu adimlarin hepsini ben kendim tek tek atmak zorundaydim. Bunu simdi LLM yapiyor.

Loop engineering sayesinde bütün bir sistemi istedigim sekle sokana kadar refactor edebilirim. Eskinden ben metod, sinif, modül bazinda bu islemi yaparken, günümüzde tek bir loop ile koca bir sistemi bile yeniden yapilandirabiliyorum.

Burada testler yine ayni vazifeyi görmeye devam ediyorlar. Her loop sonunda testlerin de calisir durumda olmalari, refactoring isleminin yan etkisiz yapildigini garanti edecektir.

Burada yazilimcinn vazifesi de tam anlamiyla degismis durumda. Artik refactoring yapan kendisi degil, kullandigi LLM’dir. Yazilimci iyi bir uygulama mimarisi icin ne gerektigini cok iyi bilen ve bu bilgisi isiginda degisik iterasyonlarda tasarladigi sistemin oraya cikmasini saglayan kisidir.

Loop engineering refactoring yönteminin bir sonraki evrimidir.

Eskiden kod ve test kodu dokümentasyondu. Örnegin Java’da bunun icin @Javadoc isminde özel bir yapi bile var.

Ben kodun icinde dokümentasyon yapmayi hic bir zaman tasvip etmedim, cünkü kod cok hizli degisebilen bir mevhum ve metotlar ve siniflar icinde birakilan yorumlar zaman icinde gecerlilklerini yitiriyorlar.

Ben testlerin, özellikle onay/kabul testlerinin gercek dokümentasyon olduklari savini tasiyordum. Bu konuda da fikrim degisti.

Öncelikle kod dokümentasyonunun neden yapildigina bir göz atalim. Dokümentasyon bir sonraki yazilimcinin ne yapildigina dair hizli bir sekilde fikir edinebilmesi icin yapilan bir aktivitedir. Kodu okuyup, anlamak zor olabilir. Bu yüzden zaten clean code gibi akimlar basladi. Dokümentasyon mimari, algoritma ve yeri yapilari hakkinda bilgiler ihtiva eder.

Dokümentasyonun en kötü özellikleri:

• Cok hizli gercekleri yansitamaz sekilde geride kalmasi
• Her daim dogrulari ihtiva etmemesi ve güvenilir bir kaynak olmamasi
• Karmasik olabilmesi

Peki bizim programci olarak dokümentasyon okuma istedigimiz nereden geliyor? Öncelikle sunu belirtelim: böyle bir istek yok. Programci hemen kodu acar, karistirmaya baslar. Bu kafa yapisi ile bir ürün kullanma klavuzuna bakmadan, ürünü calistirmaya calisma zihniyet aynidir.

Genel olarak dokümentasyonu karmasik bir yapiyi anlayabilmek icin okuruz. Peki buna gerek kaldi mi? Bize birisi uygulamanin tüm özelliklerini, kullandigi mimariyi, algoritmalari ve veri yapilarini anlatabilir mi? Evet anlatabilir. Bunu kim yapabilir? Yapay zeka!

Bu sebeple dokümentasyon olusturmaya gerek kalmamistir. Kodun en güncel durumuna en kisa sürede yapay zeka yardimi ile vakif olabiliriz. Code review yapmak istemiyorsak, buna bile gerek kalmamistir. Code review yapmak bile gereksiz bir aktivitedir artik, cünkü olusan tonla kodu mantikli bir. zaman cercevesinde review yapmak mümkün degildir.

Dokümentasyon yerine ben ne yapiyorum? Onay kabul testleri icin onay/kabul kriterleri olusturuyorum. Bunlari test speclleri olarak yapay zekaya veriyorum ve gerekli onay/kabul testlerini olusturmasini ve kosturmasini söylüyorum. Bu testler sorunsuz calisana kadar benim icn kod hatalidir ve üzerinde calisilmasi gerekir.

Benim icin gecerli tek dokümentasyon ve hakikat kaynagi onay/kabul kriterleridir. Gerisi beni ilgilendirmiyor. Onlari okuyarak, uygulamadan olan beklentileri cok hizli bir sekilde kavrayabilirim.

Loop engineering yapmaya kadar evrilen kendi yapay zeka serüvenimi prompt yazma üzerinden size adim adim aktarayim.

• Satir bazinda autocomplete: Github copilot ilk ciktiginda bu özelligi kullanarak, kodu satir bazinda tamamlatiyordum. Cok eglenceli oldugunu görünce, gidisati daha da derinlestirmek istedim.
• Metot bazinda autocomplete: Bir zaman sonra bunu metot bazinda yapabilecegimi de fark ettim ve yeni metotlar böyle olusmaya basladi.
• Sinif bazinda autocomplete: Metot olursa, siniflari da böyle olusturabilirim fikri olustu. Basladim siniflari bu sekilde sekillendirmeye.
• Ilk prompt engineering ile tanismam: Copilot bir zaman sonra chat özelligini getirdi ve ben orada ilk promptlari yazmaya basladim. Cikan sonuclar idare eder türdendi ve aslinda kod yazmaya devam ettim.
• Gercek prompt engineering: Copilot cli ve Opus 4.5 ile tanistim ve artik sadece prompt yazmaya ve kod yazmamaya basladim.
• Ilk loop engineering deneyimim: Claude code’a gectikten sonra gpt destegi ile cok farkinda olmadan loop engineering yapmaya basladim.
• Gercek loop engineering: Claude code + opus 4.8 + gpt ile loop engineering yapmaya basladim.

Simdilerde gpt gereksinim analizlerini yapiyor ve loop planlarini otomatik olarak LOOP.md dosyasina yaziyor. Opus bu dosyayi alip, gerekli implementasyonu yapiyor.

Bundan sonraki adim ne olacak sizce?

Bir derleyici ile interaksiyona girmek ne kadar mantikli? Kimse yapmiyor degil mi?

Peki bir LLM le interaksiyona girmek ne kadar mantikli? Herkes yapiyor degil mi?

Her ikisi icin de interaksiyon anlamli bir yaklasim degil. Bu isi sizin neden oldugunuz bir dag bogaza dönüstürür.

Bizler yapay zeka ile calismayi ne sekilde ögrendik? Prompt yazarak. Cogu programci da bu sekilde devam ediyor. Ama bu yapay zeka kullanimindaki potansiyelin %90 ve üzerinin kullanilmadigi anlamina gelir.

Aradan nasil cekiliriz? Prompt yazmayarak! Bunun yerine yapay zekanin uzun bir süre yaptigi is üzerine odakli calisabilecegi döngüler kurmamiz gerekiyor.

Bu düsünce dünyasina gecis yaptiktan sonra agentic programlama seviyesine cikmis oluyoruz.

Döngüyü baslatabilmek icin yapmamiz gereken tek sey döngü planlari (loop plan) olusturmak. Döngü planlari yeni promptlarimiz. Her döngü plani icinde o göreve ait tanimlanmis ve adim adim atilmasi gereken adimlari ihtiyava eden bir yol haritasi mevcut. Artik prompt degil döngü promptlari ile yapilacak isi külliyen tayin edip, yapay zekanin bu plani gerceklestirmesini sagliyoruz. Aradan cekiliyor ve seyrediyoruz (ben kitap okuyorum, bu yazilari yaziyorum, spor yapiyorum).

Ben döngü planlar icin gpt kullaniyorum. Gpt her is icin gerekli döngü planlarini LOOP.md dosyasyina yaziyor ve opus bu planlari okuyup, calismaya basliyor. Netice istedigim sekilde olana bu her döngü devam ediyor.

Hala prompt mu yaziyorsunuz yoksa döngü kurmaya basladiniz mi?

Loop engineering demistik en son, oradan devam edelim.

Loop enginneering’in ne oldugu konusuna diger yazilarimda deginmistim. Ben bunu günlük hayatimda nasil uyguluyorum, bunlara örnekler vererek devam etmek istiyorum.

Loop engineering yaptigim degisik senaryolar var. Ben “bugünden itibaren loop engineering yapacagim” demedim. Kendimi icinde buldum, cünkü kullandigim yeni arac, claude code buna yatkinmis. Ben loop engineering yaptigimi bu terimi gördükten sonra anladim.

Simdi en basit halinden, en komplex haline dogru örnekler üzerinde loop engineering nedir, inceleyelim.

Örnegin büyük bir feature icin calismaya baslamis olayim. Bunun baslangici da loop engineering’e dayaniyor, lakin o noktaya sonra gelecegim. Karmasik uygulama özelliklerinin olusturulmasi da karmasik bir sürec, cünkü sürekli gpt ve opus arasinda da semantik bir loop olusturmam gerekiyor. Bu loop geri bildirim almak ve ikisi arasindaki calismayi senkronize etmek icin gerekli.

Ipin ucunu kaybettigim zaman gpt’nin son durumu analiz etmesini ve eksikler icin bir loop plani olusturmasini istiyorum. Bu loop plani dogrudan opus’a veriyorum ve yaptigi ise hic karismiyorum. O plan modda basladigi icin tekrar analiz yapiyor ve varsa, sorularini bana yöneltiyor. Bu sorulari ben dogrudan cevaplayabilir durumda olmama ragmen, onlari gpt’ye gösteriyorum ve fikrini aliyorum. Buna göre secimleri yapip, opus’in implementasyonu tamamlamasini istiyorum. O isini tamamlayinca, gpt’nin tekrar üzerinden gecmesini ve hata ya da eksik varsa, yine bir loop plan olusturmasini istiyorum. Bu döngü gpt’nin “tamam, simdi eksiksiz” demesine kadar devam ediyor.

Büyük bir feature implementasyonu icin yine gpt ile bir gereksinim analizine giriyorum. Buradaki ana amac alani iyi anlamak. Bu alan bilgisi olmadan yapay zekayi yönlendirmek cok anlamli degil. Bu analiz sona erdikten sonra bana gerekli tüm loop planlarini vermesini istiyorum. Burada onlarca loop plani olusabiliyor. Bu noktadan itibaren her loop plani icin daha önce anlattigim döngü calismaya basliyor.

Loop engineering benim icin cok dogal bir yaklasim, zaten terimi bilmeden bu sekilde calistigimdan bahsetmistim. Bunun nedeni cevik yazilimi icsellestirmemde yatiyor. Söyle hizli bir sekilde cevik yazilima bakacak olursak, su noktalari net olarak görebiliriz:

• Test yazarak kodun ne durumda oldugu,
• Sürekli entegrasyon yaparak, ürünün ne durumda oldugunu,
• Müsteriye sorular sorarak, ne istedigi,
• Pair programming yaparak, alani ve implementasyonu ne kadar anladigimiz,
• Yeni sürümler olusturarak, gereksinimlerin ne oranda tatmin oldugu

geri bildirimini aliyoruz. Yazilimda geri bildirim en önemli husustur. Yapay zeka ile bunun bir üst seviyedeki halini yasamaya baslamis olduk.

Eskiden programci olarak nasil soruna cevap arardim. Bu durum tamamen degismis durumda. Artik ne sorusunun pesindeyim. Programlama tarihi de LLM’ler ile birlikte nasil sorusundan ne sorusuna dogru evrilen bir soyutlama tarihine dönüsüyor.

Günümüzde programlama paradigmalarinin evrimine canli, canli sahit oluyoruz:

Imperatif -> Deklaratif -> Niyet Tabanli (intent based) Programlama

Niyet tabanli programlama ile ne kast ettigimi aciklayacagim.

Ben Java dilinde cok uzun bir dönem imperatif kod yazdim. Java 8 ile gelen Stream API ilk deklaratif kod yazma imkani sagladi. Java 8 öncesi for, if, add yapisi Java 8 ile filter, map, collect e döndü. For döngüsü yerine filter yapisini kullanarak ne yapilmasi gerektigini tayin ediyorum, ama nasil yapilmasi gerektigine JVM kendisi karar veriyor. Stream API ile gelen en büyük degisiklik bu oldu.

Yapay zeka ile bu calisma tarzi yine bir üst soyutluk seviyesine tasinmis oldu. Artik promptlar ile “x modülünü yap, sunu desteklesin, bunu yapabilsin” yine ne yapilmasini gerektigini tayin ediyorum, ama artik sunu filtrele, su algoritmayi kullan bile demiyorum. Sadece niyet (intent) belirtiyorum. Bu da aslinda yeni bir paradigmanin dogusu: Intent Programming. Belki buna semantik programlama bile denebilir.

Prompt benim icin bir DSL (domain specific language). DSL ile bir problem tanimlanir. Ayni sey prompt icin de gecerli. Prompt dogal dil ile yazilmis bir DSL.

Bir üst soyutluk seviyesine saracak olursak, prompt aslinda DSL degil, ISL (Intent Specific Language), cünkü DSL’de oldugu gibi syntax artik önemli degil, daha cok semantik icerik önemli.

Eskiden derleyiciler Java -> Bytecode -> Makina kodu seklinde calisiyorlardi. Simdi ise niyet -> LLM -> Java, yani LLM bir üst seviye derleyici gibi davraniyor. Kisaca LLM’lere prompt compiler diyebiliriz.

Eskiden yazilimci nasil yapildigini bilen kisi idi. Yeni yazilimci ise problemi en dogru sekilde modelleyen kisi olacak. Burada yine domain driven design öne cikiyor, cünkü ne sorusuna cevap verebilmek icin alani cok iyi tanimak lazim.

Ben artik kod yazmiyorum. Sadece niyetimi ifade ediyorum. Kod insan ile makine arasindaki son ortak dil olmaktan cikip, yapay zekanin insanlar adina ürettigi bir ara temsile dönüsüyor. Simdiye kadar gördügümüz tüm deklaratif programlama teknikleri son durak degildi. Onlar bizi prompt programlamaya hazirlamis oldular.

Yapay zeka araclari kullaniminin zaman icinde bende nasil degistigini kisaca paylasayim.

– 2022 baslarinda IIntelliJ IDEA bünyesinde Github Copilot plugini kullanmaya basladim. O zamanlar hatirladigim kadariyla chat modu yoktu. Sadece autocomplete yapma özelligi ile ben kod yazarken bana destek oluyordu. Bunu ilk gördügümde, yolculugun nereye gidecegini anlamistim.

– 2023 + 2024 de plugine chat özelligi eklendi ve bugün bildigimiz sekli ile prompt engineering yapmaya basladim.

– 2025 de Github copilot cli geldi ve ben tamemen IntelliJ / Android studio bünyeinde calismayi biraktim ve konsola gectim. Birkac hafta öncesine kadar da prompt engineering yapmaya devam ettim. Burada birden fazla ajan ile calismanin nasil olduguna dair ilk deneyimlerini yapmaya basladim.

– Birka hafta önce copilot’in kullanim ve fiyat politikalari radikal bir sekilde degistigi icin tamamen claude code’a gectim.

– Bu zamandan beri Claude code ve Gpt ile loop engineering yapiyorum.

Loop enginering terimi aslinda benim bugün dikkatimi ceken bir konuya dönüstü. Ben aslinda haftalardir loop engineering yapiyormusum, bugün onun farkina varmis oldum. Loop engineering ile uygulama özelliklerini (feature) tek sürümde bitirmek daha kolay bir hale geldi.

Bundan sonra yapay zeka araclari kullanimi nereye evrilecek dersiniz?

Kücük bir spoiler vereyim: ürün gelistirmenin insansiz yapildigini hayal edin.

Komple bir envanter yönetimi sistemini (dashboard, envanter kalemleru, depolar, hareketler, depo transferleri, sayimlar, receteler, siparis önerileri, satin alma siparisleri, mal kabulleri, tedarikciler, raporlar bölümleri; angular, spring boot backend, sayisiz yeni api, dto, mapper, service, entity siniflari, liquibase scriptleri, unit ve entegrasyon testleri ile) loop engineering ile 3 gün icinde tamamladim. Kendin kodu yazmaya kalsaydim, muhtemelen minimum 3 ay ugrasirdim. Büyük bir ihtimalle daha uzun bile sürebilirdi. Buna paralel sayim yapmak ve depolarda mal kabulü icin bir Flutter mobil uygulamasina basladim. O da yarin tamamlanmis olacak.

Ve…

Bir satir kod bile yazmadim!

Hala prompt engineering mi yapiyorsunuz?

Ok, time for the next mind shift.

Artik prompt engineering degil, onun yerine loop enginering yapiyorum.

Ikisinin arasindaki fark ne?

Prompt engineering türünde yapay zeka ile sürekli interaksiyon halindesiniz. Prompt veriyorsunuz, o birseyler yapiyor, siz sonuca bakiyorsunuz, düzeltmek istedikleriniz icin yeniden bir prompt yaziyorsunuz ve bu döngü sürekli bu sekilde devam edip, gidiyor. Kisaca prompt engineering ile su kodu yaz diyorsunuz. Github Copilot CLI ile bu sekilde calisiyordum.

Claude code ile durum degisti ve loop enginnering yapmak mümkün hale geldi benim icin.

Loop engineering nedir?

Artik task bazli düsünmüyorum. Üzerinde calismak istedigim bir feature var ise, bunu bir bütün olarak Opus 4.8 de veriyorum ve o bir döngü icinde analizden testlere kadar gereken tüm adimlari kendi basina kosturuyor. Artik araya ben girmiyorum. Prompt engineering yaparken sürekli araya girmem gerekiyordu ve bu yüzden karmasik uygulama özelliklerini (feature) implemente etmek daha uzun zaman aliyordu. Loop engineering sayesinde yapay zeka ile calisma tarzim tamamen degismis oldu.

Pratikte bu loop nasil olusturuluyor?

Bir ikipte 3 kisiyiz.

– Ben: Product owner ve alan icin karar verici

– Gpt: Mimar, prompt designer ve kodu review yapan arkadasimiz

– Opus 4.8: Multiagent programcimiz, yani programcilarimiz

Ilk adimda üzerinde callismak istedigim uygulama özelligini (feature) seciyorum ve Gpt’ye söyle bir prompt giriyorum:

> Bu yeni özelligi analiz et. Opus icin bana bir loop-plani olustur. Bu plan model, backend, frontend, testler, rizikolar ve onay/kabul kriterlerini ihtiva etmeli.

Cikan prompt 4,5 loop paragrafi ihtiva eder ve Opus bunlari adim, adim implemente edecektir. Opus isini bitirdikten sonra tekrar Gtp’ye dönerek, Opus’un yaptiklarini analiz etmesini istiyorum. Buradan cikan review dokümanini tekrar Opus ile paylasiyorum ve eksikleri tamamlamasini istiyorum.

Benim buradaki tek rolüm neyin yapilacagini yani neyi tayin etmek, nasil yapilacagina Gpt ve Opus karar veriyorlar. Bunu gerceklestirmek icin hem Gpt ve Opus arasinda bir loop olusturuyorum hem de Opus’un kendi loop mekanizmasinda istedigim sonucu cikarmasi icin gerekli yönlendirmeyi Gpt sayesinde yapmis oluyorum.

Bir sonraki step tamamen aradan cekip, sunu yapin demek olacak. Bunun icin Gpt ve Opus’u birlikte calisabilecek sekilde entegre etmek gerekiyor, yani Gpt Opus’a gerekli loop promptlari verebilmeli. Bu Jira üzerinden ticket olusturularak da cözülebilir. Bu konu üzerinde calisacagim. Gelismelerden sizi haberdar ederim :)

Yapay zeka hakkinda yazilarima buradan ulasabilirsiniz:

Birisi Fable 5 i hacklemis ve Mythos özelliklerini ortaya cikarmis. Claude 1000 saat test ettik, hersey güvenli diyordu :)

https://lnkd.in/eHpgzN2K

Bende su an Fable 5 calisiyor ama icerde Opus 4.8 e routing yapiyor olabilir. Zaten güvenlik söz konusu olunca default Opus 4.8 e yönlendiriyordu promptlari.

Kac gün oldu Fable 5 cikali? 4 gün, 5 gün? Ben ciktigini duydugum ilk saatten beri Fable 5 kullaniyorum. GPT, Opus final onun yaninda hikaye. Fable gercekten baska bir seviye.

Fable 5 ile yazilm yapmak ismine yarasir bir sekilde masal gibiydi. Hic kodun yazilmadigi, sadece gereksinimlerin oldugu bir masal dünyasi. Ne yazik ki bitti.

Opus 4.8 isimizi görüyor, sikinti yok.

Adak falan mi adasak acaba Fable 5 icin, belki daha hizli geri gelir? Ben klavye ve faremi adak vermeye hazirim, yeter ki geri gelsin ve masala kaldigimiz yerden devam edelim.

Bilgisayarimda claude code fable ve chatgpt desktop sürümünü birbirleri ile birlikte calisacak sekilde kullaniyorum. Chatgpt analiz konusunda, fable ile teknik implementasyon tarafinda daha iyi. Aklima gelen ilk sey dogal olarak, benim aradan cekilerek, birbirleri ile sohbet halinde benim taleplerimi yerine getirebilip, getiremeyecekleri oluyor. Bu dogrudan mümkün degil, ama dolayli olarak yapilabiliyor.

Birlikte calisabilmeleri icin sagladiklarim:

– Ikisi de kodun yer aldigi workspace alanini dogrudan erisebiliyor. Chatgpt git araciligi ile yapilan tüm degisikleri takip edebiliyor ve analizlerinde güncel kod durumunu kullanabiliyor.

– Fable isini bitirdikten sonra bir session report olusturmasini istiyorum. Bunu chatgpt ile paylasiyorum ve gerekli analiz buradan da yürüyebiliyor.

– Ortak CLAUDE.md dosyasini kullanabiliyorlar. Chatgpt bu dosyada yer alan temel prensipler dogrultusunda kendi analizlerini sekillendirebiliyor.

Bu saymis oldugum konular iki yapay zeka sisteminin birlikte calismalari icin yeterli oluyor.

Henüz uygulamadiklarim:

– MCP üzerinden ikisinin arasinda baglanti kurulabilir

– Ajan orkestrasyonu üzerinden isbirligi yapabilirler

Adim adim insansiz yazilima dogru ilerliyoruz.

Bir ürün gelistirmek icin muhattap alinmasi gereken tek sahis müsteridir. En ideal sartlarda müsteri SIKlikla yazilim ekibi ile bir araya gelir ve sorulari cevaplar. Cogu zaman aslinda müsterinin de ne istedigini bilmedigi ortaya cikar, ama yine de ürüne dair bir vizyon gelistirmek ve gerekli ürünü ortaya koymak bu sekilde kolaylasir.

Müsterinin yazilim ekibi ile bir araya gelemeyecegi durumlarda bir vekile ( customer proxy) ihtiyac duyulur. Bir sekilde gereksinimlerin ekip icindeki yazilimcilar tarafindan analiz edilmesi ve koda dönüstürülebilir hale getirilmesi gerekmektedir. Müsterinin vekili bu görevi üstlenir ve yazilim ekibi ve müsteri arasinda köprü vazifesi görür.

Bu bahsettigim iki durum, ya müsteri ya da vekilinin yazilim ekibi ile calisiyor olmasi, olmasi gereken en saglikli yöntemdir. Ama cok ender rastlanan bir türdür. Genelde bir gereksinim analiz mühendisi kafasina göre gereksinim analizi yapar ve bunlari yazilim ekibine verir. Nasil bir sonuc ciktigina da mutlaka sahit olmussunuzdur.

Benim durumumda ortada ne müsteri var ne de vekili. Gereksinim analizi isini de baska birisine devretmek istemezdim. Bu yüzden gereksinim analizi icin Chatgpt yi kullaniyorum. Chatgpt bir nevi customer proxy rolüne geciyor ve alan icin gerekli analizi detayli bir sekilde yapabiliyor.

Bu sekilde karmasik bir alana ait gereksinimlerin tespitini, veri yapilarini, gerekli sürecleri ve alan analizlerini yaptirmak cok daha kolaylasiyor. Buradan cikan analizler yardimi ile backend ve frontend icin gerekli kodu Fable 5 kolay bir sekilde olusturabiliyor. Artik kod yazmaya gerek kalmadi diyerek bu süreci kastetmis oluyorum.