Loop Engineering Nedir? Prompt'tan Sisteme Geçiş
Bir süredir farkında olmadan kurduğum bir şeyin adını sonradan öğrendim: tek seferlik iyi cevap değil, niyeti koruyan tekrar eden döngüler.
"Loop Engineering" tabirini ben de son haftalarda sık sık görmeye başladım. Önce kenara koydum, çünkü yeni bir etiketin daha modaya dönüşmesi beni pek heyecanlandırmıyor. Ama tabir aklımda kaldı, çünkü tarif ettiği şey benim için yeni değildi. Yaklaşık bir aydır MORTY tarafında kurduğum düzen tam da buydu: belli aralıklarla araştıran, sinyal yakalayan, bulduğunu kendine geri besleyen ve bundan ürün ya da taslak çıkaran ajanlar. İsim sonradan geldi; pratik zaten oradaydı.
Bu yazıyı bir trendi açıklamak için yazmıyorum. Tam tersine, bir süredir elimle yokladığım bir problemin nihayet bir adı olduğunu fark ettiğim için yazıyorum. O ajan döngülerini kurarken kafamda hep aynı soru vardı: bir işi modele iyi anlatmak ile o işi zaman içinde kendi başına doğru yapan bir düzen kurmak neden bu kadar farklı hissettiriyor? Loop Engineering bana bu farkı düşünmek için temiz bir çerçeve verdi. Ve dürüst olayım: bunu hâlâ kurarak öğreniyorum. Anlatacaklarım bitmiş bir teori değil, çalışan ama hâlâ olgunlaşan bir pratiğin notları.
O farkı en iyi şöyle anlatabilirim. İyi prompt gerçekten işe yarıyor: daha net cevap alıyorsun, daha az açıklama yapıyorsun, model seni daha hızlı anlıyor. Ama aynı işi üçüncü, beşinci, onuncu kez yaptığında tuhaf bir şey fark ediyorsun — sorun artık cevabın kalitesi değil. Sorun, o cevabı üreten düşünceyi her seferinde sıfırdan kurmak zorunda kalman. İşte tam orada, prompt yazmaktan sistem kurmaya geçiyorsun.
·
AKSAM NOTUNDAN SABAH KARARINA
┌─────────────────┐ ┌────────────────┐ ┌─────────────────┐
│ ◆ aksam │ │ MORTY │ │ sabah │
│ │ │ │ │ │
│ kisa not │◆ · sinyal arar │· · ben okurum │
│ fikir kacmasin │ │ taslak birakir│ │ karar bende │
│ │ │ │ │ │
└─────────────────┘ └────────────────┘ └─────────────────┘
┌──────────────────────────────────────────────────────┐
│ yasayan dongu │
│ ◆ niyet -> · arama -> · taslak -> ◇ karar │
│ hafiza: sadece yarina degerse kalir │
└──────────────────────────────────────────────────────┘
Loop burada soyut bir şema değil; akşam yakalanan niyet, gece çalışan ajan ve sabah insana dönen karar yüzeyi.
Problem: Prompt'tan sisteme geçerken niyet kaybı
Tek seferlik prompt, bir anlık zekâdır. O an için bağlamı kafanda tutarsın, ne istediğini bilirsin, çıktıyı gözünle süzersin. Sorun, o anın tekrar etmesi gerektiğinde başlıyor. Aynı işi ikinci kez yaptığında bağlamı yeniden kuruyorsun; üçüncüde sınırları unutuyorsun; beşincide format kayıyor. Her tekrar, niyetinin biraz daha aşınması demek.
Bir yerde bu tekrar can sıkıcı olmaktan çıkıp mimari bir sinyale dönüşüyor. Çünkü artık soru "daha iyi prompt nasıl yazarım?" değil. Soru şu: bu işi her defasında yeniden tarif etmek yerine, niyetimi taşıyan bir düzene nasıl çeviririm? MORTY tarafında bunu en çok sinyal taramasında hissettim. Bir ajana "şu kaynakları tara, ilgili olanı çıkar" demek bir prompt'tur. Ama bunun her gün, aynı ölçütle, aynı kalite eşiğiyle ve benim onayımı koruyarak dönmesini istiyorsan, artık bir cümle değil bir sistem tasarlıyorsun demektir.
Bunu daha önce yazdığım Sistem Debugging yazısıyla aynı eksende görüyorum. Orada dert, zihinsel gürültüyü ve uçucu RAM'i — kafanın içinde buharlaşan o düşünceleri — fiziksel, işlenebilir bir çıktıya çevirmekti; debugging'i bir metodoloji gibi kullanıp kaosu mimariye dönüştürmek. Loop Engineering aynı işi bir eşik öteye taşıyor: orada düşünceyi bir kez somutlaştırıyordun, burada o somutlaştırmayı zamana yayıyorsun. Çünkü mesele tek seferlik prompt ile aylarca dönen loop arasındaki farkta düğümleniyor — niyet ile otomasyon arasında. Tek seferlik prompt'ta niyeti sen taşıyorsun. Otomasyona geçince o yükü sisteme devrediyorsun ve devrederken bir şey sızıyor.
·
CIZGI DONGUYE BUKULUR
┌───────────────────┐ ┌───────────────────┐
│ prompt │ │ cevap │
│ │ │ │
│ input -> output │◆ · · · · ◆ · · · │ burada biter │
└───────────────────┘ └───────────────────┘
·
┌──────────────────────────────────────────────┐
│ loop niyeti tasir │
│ ◆ niyet · sinyal · rapor │
│ │
│ ◇ karar -> geri besleme │
└──────────────────────────────────────────────┘
Tek seferlik cevap yetmediğinde çizgi bükülür; bağlam, karar ve geri besleme aynı sisteme taşınır.
Prompt bir çizgidir: girer, çıkar, biter. Loop bir döngüdür: zaman içinde tekrar eder ve tekrar ettikçe bir karakter kazanır. Çizginin hızı vardır ama belleği yoktur. Döngünün ise, iyi kurulduğunda, hem ritmi hem de hafızası olur. Davranış üreten şeyi bu yüzden tek bir cümle gibi değil, küçük bir sistem gibi düşünmek gerekiyor — çünkü onunla bir kez değil, aylarca yaşayacaksın.
Sistem: Loop dediğim şey hangi parçalardan oluşuyor?
Kendi kurduğum düzene geri dönüp baktığımda, işe yarayan her loop'un aynı beş parçadan oluştuğunu gördüm. Bunu sonradan, çalışan şeyleri sökerek çıkardım; baştan tasarlamadım.
1. Intent — Bu döngü kime hizmet ediyor?
Her loop bir niyetle başlamalı. Hangi yükü azaltıyor? Hangi kararı görünür yapıyor? Benim berraklığımı, hızımı veya güvenliğimi artırıyor mu? Bu soruya net cevap veremiyorsam otomasyon kurmuyorum; çünkü cevapsız kurulan döngü iş yapıyormuş gibi görünüp aslında sadece daha şık bir gürültü üretiyor. MORTY'deki sinyal loop'unun niyeti mesela çok dar: bana her gün, kendim taramaya üşeneceğim kaynaklardan işime yarayabilecek birkaç başlığı süzüp getirmek. Daha fazlası değil.
2. Signal — Döngü neyi dinliyor?
Bir loop bir sinyalle tetiklenir. Bu sinyal zaman olabilir — her sabah, her akşam, her hafta. Bir repo değişikliği, bir sesli not, bir RSS akışı, bir e-posta ya da benim attığım kısa bir komut olabilir. Benim düzenimde sinyallerin çoğu ya takvime ya da yeni gelen bir kaynağa bağlı: SUMMER tarafı gün içinde değişenleri izliyor, MORTY belli aralıklarla tarıyor, ben de arada sesli notla araya giriyorum. Sinyal bulanıksa loop da bulanık olur; yanlış şeyi dinleyen sistem, doğru saatte yanlış kapıyı çalar.
3. Interpreter — Sinyal nasıl anlamlandırılıyor?
Asıl iş burada. Ham sinyali anlama çeviren katman: sistem yönergesi, ajan rolü, RUNE brief'i, risk sınıfı. Sistem Debugging'de ham veriyi dökmenin tek başına yetmediğini, o gürültüyü desene çevirmek için bir yorumlama adımı gerektiğini anlatmıştım. Loop'ta da aynısı geçerli — sinyali neye göre yorumlayacağını bilmeyen ajan işlem yapar ama anlam üretmez. "Şu başlık çıktı" ile "şu başlık senin şu projen için neden önemli olabilir" arasındaki fark, tamamen bu katmanın kalitesinde saklı.
4. Output — Ne üretiyor?
Çıktı her zaman bir dosya, commit ya da aksiyon olmak zorunda değil. Çoğu zaman en değerli çıktı kısa bir rapor, bazen "bugün dikkate değer bir şey yok" cümlesi, bazen de "Patron, burası riskli" deyip durmak oluyor. MORTY'nin günlük taraması bana çoğu gün üç beş satırlık bir özet ve birkaç ham ürün fikri bırakıyor; bunların çoğunu eliyorum, biri tutuyor. İyi çıktı bana iş yaptırmaz; bir sonraki kararımı kolaylaştırır.
5. Feedback / Hafıza — Ne kalıcı oluyor?
Her çıktı hafıza değildir, olmamalı da. Bir loop'un gücü her şeyi saklamasında değil, doğru şeyi damıtmasında. Bazı bilgiler README'ye gider, bazıları docs içinde kalır, bazıları bir skill'e dönüşür, bazıları sadece o oturumda yaşar ve unutulur. Sistem büyüdükçe değer kazanan şey hafızanın hacmi değil, neyi tutup neyi atacağını bilen seçicilik oluyor. Beslemeyi yanlış kurduğun loop, zamanla kendi gürültüsünü gerçek sinyal sanmaya başlıyor.
Protokol: Ajan nerede duracak, insan nerede kalacak?
Loop kurarken en kritik karar otomasyonun ne yapacağı değil, nerede duracağıdır.
Benim sistemimde tekrar tekrar koymaya çalıştığım kural şu: önce oku, sonra raporla, sonra gerekirse sor.
İnsan tarafı niyeti verir, sınırı çizer, risk eşiğini belirler ve son kararı alır. Ajan tarafı okur, karşılaştırır, özetler, önerir ve riskli yerde durur. Aradaki ortak protokol ne kadar netse, loop o kadar güvenilir olur.
·
AJANIN DURDUGU YER
◆ read-only -> calisabilir
· local draft -> raporla ┌──────────────────┐
│ insan kapisi │
· repo write -> kapsam net │ │
│ riskte sor │
◇ external -> onay◆ · · · · ◆ │
│ sinir ciz │
◆ service -> riskli dur │ │
└──────────────────┘
· secret -> dokunma
İyi loop sadece koşmaz; riskli yerde durur ve insan kararını doğru noktaya çağırır.
Bu liste teknik bir güvenlik notu gibi görünebilir ama aslında loop'un ahlakıdır.
Ajanın gücü sadece dosya yazabilmesi, komut çalıştırabilmesi veya web'e bakabilmesi değil. Asıl güç, ne zaman duracağını bilmesinde.
Felsefi boyut: Form değişirken niyet korunuyor mu?
Spinoza'nın conatus fikrini burada pratik bir test gibi kullanıyorum: Bir sistem benim varlık gücümü artırıyor mu, azaltıyor mu?
Eğer bir loop daha fazla bildirim, daha fazla takip yükü, daha fazla sahte ilerleme üretiyorsa bana hizmet etmiyor. Çalışıyor olabilir ama gücümü artırmıyor. Hatta tam tersi, dikkatimi kendi ritmine bağımlı hale getiriyor.
İyi loop bana daha çok şey yaptıran sistem değil. Gereksiz şeyi zihnimden alan, kritik şeyi önüme koyan sistem.
Sistem Debugging'de kaotik düşünce ile rafine edilmiş çıktı aynı düşüncenin iki farklı formuydu. Burada prompt ve loop da aynı niyetin iki farklı formu. Prompt anlık form. Loop zamana yayılmış form.
Soru şu: Form değişirken öz korunuyor mu?
Pratik kurulum: Kendi ilk loop'unu küçük kur
Bunun için üç makineli bir ajan ağına ihtiyacın yok. Benim düzenim oraya yıllar içinde, hep tek bir küçük loop'tan büyüyerek geldi. İlk versiyon küçük olmalı; hatta sıkıcı olması iyiye işarettir, çünkü heyecan verici ilk versiyonlar genelde fazla şey vaat edip niyeti dağıtıyor.
Haftalık repo özeti, günlük proje kontrolü, sesli not işleme, haber taraması veya blog taslak hazırlığı gibi bir iş seç. Finans, servis yönetimi veya credential içeren alanlarda ilk versiyon sadece read-only olmalı.
·
RAPOR BIR KARAR YUZEYIDIR
┌──────────────────────┐ ┌───────────────────────┐
│ ham log │ │ DID / SAW / NEEDS │
│ │ │ ◆ DID: tarandi │
│ ok │ │ │
│ │ │ · SAW: sinyal var │
│ done │ ◆ · · · · │ │
│ │ · │ · RISK: dusuk │
│ 200 │ │ │
│ │ │ ◇ NEEDS: karar │
│ ... │ │ │
└──────────────────────┘ └──◆ NEXT: kucuk adim───┘
Ham log değil: ne yaptı, ne gördü, nerede risk var, senden ne istiyor?
Bu format basit ama güçlü. Loop'un ne yaptığını, ne gördüğünü, nerede risk gördüğünü, senden ne istediğini ve sıradaki küçük adımı görünür kılar.
Dosya yazmasın. Dış mesaj göndermesin. Servis restart etmesin. Sadece okusun, özetlesin ve gerekiyorsa karar istesin. Önce görünürlük, sonra otomasyon.
Sonra onay kapısını yaz. Ne zaman kendi ilerleyebilir? Ne zaman sormalı? Ne zaman açıkça "bu riskli" deyip durmalı?
En sonda hafıza kuralını koy: Bu bilgi yedi gün sonra hâlâ değerli olacak mı? README'ye mi gitmeli, docs'a mı, skill'e mi, yoksa sadece geçici bir rapor olarak mı kalmalı?
Nereye gidiyoruz?
Ajanlar her ay biraz daha yetenekli hale geliyor. Bunu kendi düzenimde net görüyorum: bir yıl önce elle tarif ettiğim adımların çoğunu artık modele anlatmama gerek kalmıyor. Ama burada sezgilere ters bir şey var. Model ne kadar yetenekli olursa, iyi prompt yazabilmenin getirdiği avantaj o kadar eriyor. Herkes iyi cevap alabildiğinde, "iyi cevap" artık kimseyi öne çıkarmıyor.
AI çağında en büyük risk işini kaybetmek değil, kendi üretim ritmini hiç kurmamış olduğunu fark etmektir. Dış sistemlere yalnızca gelir için değil, anlam, geri bildirim ve üretim yönü için de bağımlı kaldığında; modelin ne kadar iyi olduğu ikincil hale geliyor. Elinde kendi döngün yoksa, başkasının ritmine göre çalışıyorsun.
O yüzden bir sonraki avantajın "en iyi prompt'u kim yazıyor" sorusunda olmayacağını düşünüyorum. Avantaj, dört şeyi aynı döngüde birleştirebilenlerde olacak: kendi yargısını koyabilen bir irade, neyin önemli neyin gürültü olduğunu ayıran bir zevk, sisteme geri dönen dürüst bir geri bildirim ve bunları tekrar tekrar çalıştıran bir sabır. Modelin halledemediği kısım tam olarak bu — neyi dinleyeceğine, nerede duracağına ve nelerin senin hayatına değdiğine dair kararlar. Bunlar prompt'a sığmıyor; ancak yaşadığın işin içinden, kendi ham malzemenden çıkıyor.
·
BIR SONRAKI AVANTAJ
┌───────────────┐ ┌───────────────┐
│ ◆ irade │ │ zevk │
│ yon sec │ │ gurultuyu ele │
└───────────────┘ ┌───────────────────┐ └───────────────┘
│ dongu │
│ yasayan is │
│ │
└───────────────────┘
┌───────────────┐ ┌───────────────┐
│ geri bildirim │ │ sabir │
│ sonucu oku │ │ tekrar et │
└───────────────┘ └───────────────┘
avantaj = bu dortluyu ayni dongude kurmak
Bir sonraki avantaj zeki bir prompt değil; irade, zevk, geri bildirim ve sabrın aynı döngüde çalışması.
İşin dürüst tarafı şu: ben de bunu yaşayarak öğreniyorum. Kurduğum loop'ların bir kısmı çalışıyor, bir kısmını söküp attım, bir kısmı beni kendi ritmine bağlamaya çalıştığı için kapattım. Mükemmel bir sistem kurmuyorum; her seferinde niyetimi biraz daha iyi taşıyan, biraz daha az sürpriz çıkaran bir düzen kuruyorum.
Bunu yedi yazılık bir seriye yaymak istememin sebebi de bu. Bu ilk yazı kavramı oturtuyor; sonraki altı yazıda loop'un katmanlarını tek tek açacağım:
- Niyet kaybı: Loop'lar nasıl bozulur?
- Görünür loop: Log değil, karar yüzeyi
- İnsan-ajan protokolü: Nerede duracağını bilen sistem
- Ritim tasarımı: Cron job bir saat değil, sinir sistemidir
- Loop hafızası: Ne kalmalı, ne silinmeli?
- Kendi loop'unu kur: Küçük başla, görünür büyüt
Çünkü davranış üreten her sistemin er geç bir karakteri oluyor. Benim asıl derdim, o karakteri şansa bırakmamak.
Bir süredir farkında olmadan kurduğum bir şeyin adını sonradan öğrendim: tek seferlik iyi cevap değil, niyeti koruyan tekrar eden döngüler.