Benim yazilimci gecmisimin kisa özeti söyle:
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:
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:
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:
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.
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:
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.
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 :)