Daha önceki yazilarimda yapay zeka araclari ile calisirken gectigim evreleri sizinle paylasmistim. Buna bir yenisi daha eklendi: Software Factory Pattern

Gectigim Evreler:

Autocomplete -> Prompt Engineering -> Loop Engineering -> Software Factory Pattern

4 sene öncesinde benim icin ilk yapay zeka araci olan Github Copilot ile tanistigimda, satir bazinda autocomplete özelligi ile bu arac benim kodumu tamamlayabiliyor, alternatif kod örnekleri sunabiliyordu. Bunu daha sonra metot ve sinif bazinda yapmaya basladim.

Daha sonra chat özelligi geldi ve ben promptlar ile calismaya basladim. Akabinde uygulama özelliklerini promptlar ile gelistirmeye basladim.

Loop engineering ile bunu otomatize ettim ve uygulama özellikleri icin bir pipeline olusturdum. Daha sonra bunu tüm bir uygulama icin yapabilecegimi gördüm ve simdilerde software factory pattern ile calisiyorum.

Nedir bu software factory pattern?

Yazilim üretilen bir fabrika düsünün. Ben bir ekosistemi olusturan onlarca uygulama üzerinde calisiyorum. Eskiden bir uygulamayi secip, onun parcalari üzerinde calisirdim. Simdilerde bütün bir uygulamayi loop engineering ile bir bütün olarak insa ettiriyorum. Bu 24-48 saat zaman diliminde otonom calisan Codex + Fable 5 ile gerceklesiyor. Fabrika bir sonraki uygulanin kaba insaatini yaparken, ben bu zaman diliminde fabrikadan taze cikmis baska bir uygulama icin fine-tuning islemlerine basliyorum. Fine-tuning prompt engineering ile uygulamayi kaba halinden alip, istedigim hale sokma islemi.

Bunun nasil yapildigini bir sonraki videoda sizlerle paylasacagim.

Yapay zeka araclari ile ürün gelistirmek istiyorsaniz, bunu nasil yapmaniz gerektigine dair benim uyguladigim yol haritasini sizinle paylasmak isterim.

Yol haritasi su sekilde:

• Iyi bir fikrim var
• Analiz safhasi
• Loop engineering ile kaba insaat
• Prompt engineering ile ince insaat (fine-tuning)
• CI / CD ile ilk testler, sürüm ve deployment
• Sistem hatalari ve kullanici geribildirimleri ile düzeltmeler
• Hardening ile güvenlik aciklarinin kapatilmasi
• Performans testleri ile yük kapasitesinin ölcümü ve memory leak düzenlemeleri
• Canliya alim.
• Canlida olusan hatalari ve loglari sürekli yapay zekanin ulasabilecegi bir yere birakma ve hatalarin tamir edilmesi.

Ben öncelikle iyi bir fikri oldugunu düsündügüm noktada ise koyuluyorum. Buradan girisimcilik, piyasa arastirmasi, fizibilite, rekabet kosullari vb gibi konulari göz ardi ediyoruz. Ben ürünün teknik olarak nasil olusturulacagina deginecegim.

Fikir tek basina birsey ifade etmez. Önce fikrin yapilabilirliginin analiz edilmesi gerekmektedir. Bu amacla Codex / Gpt 5.5-high ile önce konuyu netlestirmek icin sohbet turlarina basliyorum. Buradaki maksat henüz göremedigim dolayli ve dolaysiz noktalara ulasabilmek. Akabinde alani (domain) tanimak icin bu sohbetleri analizlere dönüsecek sekilde derinlestirmek oluyor. Bununla birlikte uygulamanin mimari yapisi hakkinda fikir alisverisinde bulunuyorum. Burada benim cerceveyi tanimlamam gerekiyor, aksi taktirde yapay zeka istedigi ve cogu zaman benim tasvip etmedigim sekilde mimari ve kod olusturacaktir. Bu noktada mümkün mertebe baska projeleri referans olarak almasini sagliyorum ve bir senior dev gibi hareket etmesini saglayacak CLAUDE.md dosyasini olusturuyorum.

Bu safhada teknik olarak yeni projeyi baslatabiliriz. Bunun icin Codex’den gereklli tüm loop planlarini olusturmasini ve isi Opus ile koordine etmesini istiyorum ve bu noktada benim aradan cekilme vaktim gelmis oluyor.

12/24/48 saat araliklarinda gidisati konrol ediyorum. Olusan uygulama kaba hatlari ile benim siparis ettigim türde bir uygulama seklinde yapilandirlilmis olacaktir. Bu benim o uygulamayi hemen alip, canliya atarak, kullanabilecegim anlamina gelmemektedir. Bu noktada fine-tuning baslamak zorunda.

Öncelikle uygulamaya kullanmaya baslayarak, kesif turlarina cikmam gerekiyor. Bir son kullanici icin atilmasi gereken adimlari Codex’den bana yazmasini istiyorum. Bu arada Codex her loop sonunda gerekli test adimlarini ihtiva eden jira loop ticketleri olusturdu. Ben onlari tek tek inceleyerek, ne insa edildigini ve nasil calistigini görebilirim. Bu benim e2e testlerimi kolaylastiran bir sürec.

Uygulayi ve kapsadigi tüm sürecleri anladiktan sonra fine-tuning islemini baslatiyorum. Burada tek tek uygulama özelliklerini derinlesecek ve benim istedigim sekle gelecek sekilde prompt engineering yöntemleri ile fine-tune ediyorum, yani mevcut özellikleri degistiriyorum, yeni özellikler ekliyorum.

Bu noktadan itibaren uygulama test amacla ilk kullanicilari ile bir araya getirilebilir. Bu arada ben degisik staging alanlari icin deployment pipeline olusturmus oluyorum. Her degisiklik sonunda yeni bir sürüm olusturuluyor ve gerekli staging alanlarina test amacli deployment gerceklesiyor. Bu noktadan itibaren hardening ve performance testing sürecleri basliyor.

Bu islemler sonunda uygulama kullanicilari ile bulusacak canli ortamina alinabilecek kivama geliyor. Bu islemi tamamlayip, uygulamayi calisir halde kullanicilari ile bulusturuyorum.

Ben arka planda olusan bir hatalar icin jira ticketleri olusmasini sagliyorum. Yine düzenli araliklarla Codex buraya göz atip, sorunu analiz ettikten sonra loop planlari hazirliyor ve bu problemlerin Opus yardimi ile cözülmelerini sagliyor.

Yeni uygulama özellikleri icin döngüye yeniden baslatiyorum. Bu kadar :)

Yapay zeka araclari ile ilk zamanlar line autocomplete özelligini kullanarak uygulama gelistirme serüvenime devam etmistim. Daha sonralari bunu metot ve sinif bazinda yapmaya basladim. Akabinde promptlarla uygulanin parcalarini degistirmeye basladim.

Daha sonra promptlarla komple uygulama özellikleri gelistirebilecegimin farkina vardim. Promptlarin uygulama özelligi gelistirme konusunda yetersiz kaldiklarini, tüm bir uygulama özelligi icin onlarca prompta ihtiyac oldugunu ve bunlari elden yönetmeye calismanin zaman kaybi oldugunu gördüm. Kendimce bir döngü kurmaya karar verdim.

Analizleri gpt’nin yaparak, promptlari olusturmasini sagladim. Prompt yazma derdinden kurtulmustum. Sira bunlari arka arkaya sistem tarafindan tek tek uygulama özelligine dönesecek sekilde uygulanmalarini saglamakti. Bunun icin kücük bir döngü catisi olusturdum. Bu aslinda iptidai bir loop engineering sekliydi. Daha sonra loop enginneering ile tanistim ve sistemin loop planlari olusturmasini ve bu planlarin otonom bir sekilde kosturulmasini sagladim.

Loop engineering ile uygulama özelliklerinin el sürmeden ve basinda bekleden olusturulmalarini sagladim. Simdilerde komple uygulamalarin loop enginnering ile el sürmeden olusturulmalarini seyrediyorum.

Bunun ilk örnegin distributed file storage uygulamasi. Döngü 30 saattir isliyor ve kodun %80 i tamamlanmis durumda.

Özetle yapay zeka araclari ile calisirken nereden nereye geldim?

Satir autocomplete -> metot autocomplete -> sinif autocomplete -> prompt ile degisiklik yapma -> prompt ile uygulama özelligi gelistirme -> loop engineering ile uygulama özelligi gelistirme -> loop engineering ile komple uygulama gelistirme -> nirvana :-)

“Aksamdan prompt verdim, sabah uygulama hazirdi” vari cümleler vibe coding camiasinda insanlarin agzina pelesenk olmus durumda. Yazilim konusunda tecrübesiz bir sahsin vibe coding ile böyle bir netice almasi imkansiz. Benim örnegimde ise bu cümle gecerliligini koruyabilir, cünkü benim gibi yazilimcilar hem sistem girdisini gerektigi sekilde sekillendirebilirler hem de ciktiyi degerlendirebilirler.

Su anda LLM’lerin daha iyi ve hizli kod yaziyor olmalarina karsi duydugun tek argüman: “LLM’ler deterministik output üretmez”.

Fable 5 / Opus 4.8 ile calisin, deterministik output ne anlama geliyor, görün. Ondan sonra bu konuyu tekarr degerlendirelim :)

LLM’lerle calisirken önemli olan derleyicilerdeki gibi ayni input icin ayni output’u almak degildir. Önemli olan ayni input icin ayni derecede iyi calisan outputlar alabilmektir ki bunu Fable 5 ve Opus 4.8 gereginden fazla sagliyorlar.

Siz programci olarak ayni algoritmayi iki gün sonra yazsaniz ayni kodu olusturamazken, LLM’lerden bunu bekliyor olmak garip degil mi? Nasil sizin bir algoritma icin yazdiginiz iki degisik kod ayni neticeyi verecekse (dogru programladiysaniz), LLM’lerin de ayni sorun icin degisik kodlar üretiyor olmasi bir zayiflik degil, zenginliktir.

Önemli olan kodun nasil yapilandirildigi degildir. Önemli olan sizin beklentilerinizdir, yani spesifikasyondur. Bu yerine geldigi sürece makina kodu bile olsa makbuldür, cünkü ben kodu okuyarak degil, onun calisir durumda ve bir uygulama davranisina dönüstügü yerde test ederek dogrulugunu saglayabilirim.

Bu arada refactoring nasil yapildigini hatirlayalim. Refactoring kodu dis davranisini degistirmeden, ic yapisini yeniden yapilandirma islemidir. Yani uygulamayi ben dis davranisini koruyarak, komple baska bir mimariye rafactor edebilirim. Burada kod %100 bile degismis olabilir, lakin dis davranisi hala aynidir. Yani refactoring öncesi e sonraki iki degisik kod mevcuttur, ama ikisi de ayni seyi yapiyordur. LLM’de bunu yapiyor sadece ve cok daha iyi yapiyor.

Yüksek dillerin ortaya cikma nedeni ne? Assembly neden yetmedi?

Gelin simdi neden cok uzun zamandir kod yazmadigimiza bir göz atalim.

Kod derleyiciler icat edilmeden önce dogrudan makina icin yazilirdi. Yüksek dillerin ve onlarin derleyicileri icat edildikten sonra programcilar makina icin kod yazmayi biraktilar. Bütün gerekli kodu ve optimizasyonu derleyiciler yazmaya basladi. Programcilar sadece bir üst soyutluk seviyesinden makinadan ne beklediklerini ifade etmeye, yani deklaratif programlamaya basladilar.

Bu günümüze kadar böyle devam etti. Bugün kod olarak ifade edilen bir Java ya da C yapisi bellli bir syntax icinde kaleme alinmis bir programci niyetidir. Onu ve cok daha fazlasini makina icin anlasilabilir koda derleyiciler dönüstürür. O dönüsen kodu bugün akici bir sekilde okuyup, anlayabilecek insan sayisi cok az, o seviyede makina kodu kodlayacak insan da yoktur.

O halde söyle bir tespit yapalim. Yazilimcilar zaten kod yazmiyorlar, sadece niyetlerini kaleme aliyorlar.

Ikinci tespit su sekilde olsun: Yapay zeka ile yazilan promptlar da niyetten baska birsey degildir.

Ücüncü tespit: Artik kodu LLM’ler yaziyor, yani niyeti (prompt) koda dönüstüren LLM’ler.

Dördüncü tespit: Cagimizin derleyicileri LLM’lerdir.

O halde su sonucu cikarabiliriz: frontend ve backend’in LLM tarafindan hangi dilde yazildigi artik önem tasimamaktadir. LLM bugün promptlari dogrudan 1010101010 lardan olusan makina koduna dönüstürse, yeridir.

Cok kisa bir zaman sonra Java, C, Python gibi diller tarihe karisacak ve promptlarin belli bir syntax ile daha güclü ifade etmeyi mümkün kilacak programlama dilleri ortaya cikacak.

Benim icin yeni calisma modeli loop engineering + jira kanban.

Su an aktiv iki döngü calisiyor, backend proje ve mobil proje icin.

Mobil kisminda yeni bir backend api’ye ihtiyac duyan yeni bir özellik olusturmak istedigimde, su sekilde ilerliyorum:

• Mobil kanban board icinde yeni uygulama özelligi icin bir ticket aciyorum. Orada detayli olarak ihtiyac duydugum uygulama özelligini ve backend api’yi de tanimliyorum.
• Bilgisayarimdaki mobil loop bir ticketi aldiktan sonra backend projesinde yeni api icin gerekli ticketi aciyor.
• Mobil loop yeni jira ticketi aliyor ve gerekli loop planini olusturuyor. Bu noktadan itibaren yeni uygulama özelligi implemente ediliyor.
• Backend loop board üzerinde yeni bir ticket var mi sorgusunu yapiyor ve yeni api icin gerekli ticketi buluyor. Bu ticketi indirip, backend icin yeni bir loop plani olusturuyor.
• Mobile paralel olarak diger döngü icinde backend api implementasyonu basliyor.
• Ikisi tamamlandiktan sonra ben iki kanban board icinde ticketlerin TEST kolonuna kaydirildigini görüyorum. Bu noktadan itibaren gerekli testleri yapmaya basliyorum.

Tek bir tasla iki kus vurma buna deniyor sanirim ;-)

Loop engineering sayesinde rate limitler sorun olmaktan cikiyor.

Rate limit LLM’i saglayan sirketin size koydugu token kotalaridir. Bu kotalar genelde 5 saatlik ve haftalik zaman dilimlerinde resetlenir. Ne kadar SIK LLM ile interaksiyona girerseniz, o kadar cok token harcaniz ve o hizda da kotaniz dolar.

Dün ilk gpt 5.5 rate limitler gelmeye basladi, cünkü codex dakika basi jira’ya baglanip, yeni ticket var mi diye bakmaya baslamisti. Bu kullandigi contexti hizli bir sekilde sisirir hale getirdi.

Rate limit ne zaman sorun olmaya basliyor? LLM ile konsol araciligi ile interaksiyona giriyorsaniz, yani prompt engineering yapiyorsaniz, yani basina bekliyorsaniz.

Ama tam otonom calisan bir loop engineering setup bünyesinde artik saatlik ve haftalik kotalar problem olmaktan cikiyor, cünkü döngü icinde bir rate limit aldiginizda, o döngü while(true) semantiginde calistigi icin sürekli yapilmasi gereken son islemi tekrar ediyor. Er ya da gec rate limit kalkacagi icin, bir sonraki islem baslamak ve sonlanmak zorunda.

Benim örnegimde son rate limit örnegin sabah 04:00 civarinda gelmis. Bunun üzerinde codex 3 saat bekledikten sonra 07:00 de islemlere devam etmis ve aksam tanimladigim tüm jira ticketleri calismis ve test kolonuna göndermis.

Bu durrumda ben basinda beklemedigim icin gelen kota sinirlamalari beni artik baglamiyor, cünkü basinda beklemiyorum, codex ile interaksiyona girmiyorum.

Sadece bu sebepten dolayi bile loop engineering altyapisi kurmak mantikli, cünkü rate limit artik sistemin bir yan etkisi olmaktan cikti ve programci olarak bizim calisma tarzimizi sekillendirir oldu.

Zeki olan kim burada? Cikan sorunlari sürekli cözme egilimi olan programci mi yoksa yapay zeka mi? (not: zekiyim filan demedim, yanlis anlasilmasin :) )

Loop engineering tam otomasyon üzerine kurgulu degilse, yapay zeka ile yapacagi isler konusunda interaksiyon gerekiyor. Bir önceki yazimda tam otomasyon icin kuyruk yapilarinin nasil kullanildigindan bahsettim. Bu yazimla birlikte uygulama gelistirmeye yaklasim tarzimin nasil degistigini aktarayim.

Asagidaki resimde son yarim saat icinde irili, ufakli yaptirdigim isleri görüyorsunuz. Bu kanban boardda yer alan ticketleri ben ready kolonuna koydum ve gerisini loop yapan codex + opus ikilisi halletti.

Bundan önceki sürümde ne durumda oldugumuzu anlamak ve neyin test edilmesi gerektigini ögrenmek icin codex’e en son ne yaptiklarini raporlamasini istiyordum. Konsol üzerinden gerceklesen bu interaksiyon ne yazik ki kaosa neden oluyordu. Bu kaosu düzenlemek icin asagida gördügünüz kanban boardu olusturdum.

Simdi yapmam gereken dört sey:

• yeni uygulama özellikleri icin bir ticket olusturma,
• onu ready kolonuna cekme,
• arada bir test kolonunda bitmis is var mi diye bakma,
• burayi bos birakiyorum, ne yapacagimi sonra düsünürüm ;-)

Bu kadar!

Opus ile günlerdir konusmadim bile. O artik codex icin calisan programci. Codex’de benim icin calisan proje yöneticisi. Bense artik hizli bir sekilde uygulamayi test edip, eksikleri görüp, onlar icin yeni ticket acan product owner.

Yani isler kebap!

Bundan sonraki adim: bu sistemi 10x calisacak sekilde replike etmek.

Eger hale bir yapay zeka araci ile interaksiyon halindeyseniz, loop engineering bile olsa tam otonom yazilim yaptirmiyorsunuz.

Tam otonom yazilim icin ne gerekli?

Bir kuyruk (queue) sistemi. Bunun en güzel örnegi Jira.

Benim örnegimde:

• Jira altinda bir Kanban board olusturdum.
• Tüm yeni gereksinim, degisiklik ve bugfix icin yeni bir ticket olusturuyorum. Bu ticket hazirlanis esnasinda Backlog kolonunda yer aliyor. Ticket hazir hale geldikten sonra onu Ready kolonuna aliyorum.
• Codex icinde bir cronjob calisiyor ve dakika basi Codex ready kolonunda yeni bir ticket olup, olmadigina bakiyor. Yeni bir ticket varsa, onu alarak yeni bir loop plani olusturuyor. Akabinde bu yeni planini LOOP-PLANS.md dosyasina ekliyor. Bu alt katmanda islerin takip edildigi kuyruk.
• Codex sirasi gelen loop planini LOOP-PLANS.md dosyasindan alip, LOOP.md dosyasina ekliyor ve statüsüne READY_FOR_OPUS olarak isaretliyor.
• Claude code bünyesinde de bir cronjob calisiyor ve opus dakika basi LOOP.md dosyasinda yapmasi gereken yeni bir is var mi diye bakiyor. Yeni bir is buldugunda statüyü IN_PROGRESS olarak degistiyor. Isi tamamladiginda bu statü READY ye geciyor. Sorun cikarsa ya da sorulari varsa REVIEW_FOR_CODEX olarak statüyü güncelliyor.
• Eger loop tamamlandi ise Codex Jira altindaki ticketi Test kolonuna aliyor. Bu sekilde ben test edilecek yeni özellikleri takip ediyorum. Eger test ederken bir sorun cikarsa, bu ticketi Regain kolonun aliyorum, gerekli yorumlari yapiyorum Codex bu kolondo olan ticketleri toplayarak, gerekli calismalari organize ediyor.
• Eger Codex bir sorunla karsilasirse, gerekli notu düserek ticketi blocked kolonuna aliyor. Bu sekilde bende yarim kalan seyleri tamamlayarak, ticketi tekrar regain kolonuna aliyorum.

Bu sekilde döngü kendisini tekrar ediyor. Ben artik tamamen uygulama özelliklerine odaklaniyorum, codex ise teknik implementasyona ve görev dagilimina. Bu bilgisayarim 7×24 acik kaldigi sürece calisan bir döngü.