Loop Drift: Loop'lar Nasıl Bozulur?
Çalışan bir loop güven verici olabilir; ama zamanla niyetinden uzaklaşan sistem, sessizce yanlış şeyi optimize etmeye başlar.
Önceki yazıda Loop Engineering'i prompt'tan sisteme geçiş olarak tarif etmiştim. Tek seferlik iyi cevaptan, niyeti zaman içinde taşıyan döngülere geçmek. Kulağa düzenli geliyor. Hatta biraz huzurlu geliyor: bir şey kurulmuş, çalışıyor, rapor veriyor, seni tekrar eden yükten kurtarıyor.
Ama çalışan her sistem doğru çalışmıyor.
Bunu MORTY ve SUMMER tarafında küçük örneklerle gördüm. Bir loop ilk kurulduğunda niyeti çok net oluyor: şu kaynakları tara, gereksizleri ele, bana karar vermemi kolaylaştıracak birkaç satır bırak. Sonra birkaç hafta geçiyor. Kaynaklar değişiyor, benim odak alanım değişiyor, rapor formatı yavaş yavaş şişiyor, bazı varsayımlar eskiyor. Loop hâlâ çalışıyor. Hatta teknik olarak daha çok şey yapıyor. Fakat bir sabah fark ediyorsun: bu sistem artık ilk kurduğum soruya değil, kendi alışkanlığına cevap veriyor.
Ben buna loop drift diyorum. Türkçesiyle niyet kayması.
Drift radarı: Prompt, sinyal, çıktı ve hafıza katmanlarını eşik gibi izlemek.
DRIFT RADARI
◆ prompt ██░░░░ istisna artiyor
┌───────────────┐
· sinyal ████░░ kaynak eskidi │ review │
│ KEEP │
│ │
· cikti ██████ ! karar azalir │ CHANGE │
│ │
│ STOP │
◇ hafiza ██████ ! cop kalici └───────────────┘
esik asilirsa buyutme: daralt / durdur / yeniden yaz
Dört katman aynı anda izlenir: prompt, sinyal, çıktı ve hafıza. Eşik aşılırsa loop küçültülür.
Çalışıyor olması yetmez
Teknik sistemlerde garip bir körlük var: bir şey hata vermiyorsa onu sağlıklı sanmaya meyilliyiz. Cron çalışmış, script çıkmış, dosya oluşmuş, HTTP 200 dönmüş, rapor gelmiş. Dışarıdan bakınca düzen var.
Fakat loop'un başarısı sadece çalışmasıyla ölçülmez. Çünkü loop bir defalık araç değil, tekrar eden bir davranış üreticisidir. Her tekrar, sistemin karakterini biraz daha sabitler. Yanlış ölçütle çalışan bir loop, bir defa yanlış cevap veren modelden daha tehlikeli olabilir; çünkü hatasını tek seferde değil, ritim halinde üretir.
Bu yüzden Loop Engineering'de ilk güvenlik sorusu şu değil: “Bu çalışıyor mu?”
Daha doğru soru şu: “Bu hâlâ kurulduğu niyete hizmet ediyor mu?”
Aradaki fark küçük görünüyor ama pratikte çok büyük. Çalışıyor mu sorusu log'a bakar. Niyete hizmet ediyor mu sorusu insana, bağlama ve sonuca bakar.
Drift nerede başlıyor?
Benim gördüğüm drift genelde dramatik bir bozulmayla başlamıyor. Sistem patlamıyor. Kimse alarm üretmiyor. Daha çok, küçük kaymalar birikiyor.
İlk kayma prompt katmanında oluyor. Başta net olan yönerge, yeni ihtiyaçlar geldikçe yamalanıyor. “Şunu da ekle”, “bunu da kontrol et”, “bazen şuna da bak” derken loop'un tek cümlelik niyeti parçalanıyor. Bir süre sonra prompt, canlı bir tasarım kararı olmaktan çıkıp küçük istisnalar çöplüğüne dönüşüyor.
İkinci kayma sinyal katmanında oluyor. Loop hâlâ aynı kaynakları dinliyor ama senin hayatın aynı yerde değil. Üç hafta önce önemli olan bir kaynak bugün gürültü olabilir. Bir repo artık aktif değildir. Bir konu kapanmıştır. Bir ürün fikri olgunlaşmıştır ve artık araştırma değil satış veya dağıtım ister. Loop bunları bilmezse eski dünyayı dürüstçe raporlamaya devam eder.
Üçüncü kayma çıktı katmanında oluyor. Rapor formatı karar vermeyi kolaylaştırmak için doğmuşken, zamanla kendini kanıtlama aracına dönüşebilir. Daha çok madde, daha çok tablo, daha çok “bak ne kadar çalıştım” hissi. Güzel görünen ama karar yükünü azaltmayan raporlar üretmeye başlar. Bu noktada loop iş yapmıyor; dikkat istiyor.
Dördüncü kayma hafıza katmanında oluyor. Her çıktı bir yerlere yazılmaya başlarsa sistem kendi geçmişine bağımlı hale gelir. README, docs, skill, memory, backlog… Hepsi değerli olabilir ama yanlış şey kalıcı olunca loop gelecekte kendi eskimiş varsayımına referans vermeye başlar.
Bu kaymaların hiçbiri tek başına felaket değil. Felaket, hepsinin sessizce normalleşmesi.
Niyet kaybının erken belirtileri
Bir loop'un bozulduğunu anlamak için önce onun sesini dinlemek gerekiyor. Bazen teknik metrikler temiz görünür ama raporun tonu değişmiştir.
Benim kullandığım birkaç pratik belirti var:
İyi rapor bir sonraki hareketi kolaylaştırır. Drift eden rapor kendi varlığını açıklamaya başlar. “Şunları yaptım, bunları gördüm, ayrıca şunlar da var” der ama senden hangi kararı istediğini net söylemez.
Tekrar her zaman kötü değil; ritim zaten tekrar demek. Ama raporlar aynı cümlelerle geliyor, aynı öneriler dönüyor, aynı riskler hiçbir karara bağlanmadan listeleniyorsa loop sinyal değil yankı üretiyor olabilir.
Bir loop'un neden kurulduğunu tek cümlede söyleyemiyorsam durup bakıyorum. Çünkü niyeti cümleye dökemediğim yerde sistemin davranışını da denetleyemem. “Genel olarak faydalı” otomasyon için tehlikeli bir etikettir.
Ajan gereksiz yerde soruyorsa dikkat yükü artar. Riskli yerde sormuyorsa güvenlik azalır. İkisi de drift belirtisidir. İnsan-ajan sınırı zamanla yeniden çizilmezse sistem ya fazla çekingen ya da fazla özgüvenli hale gelir.
Üç ajan, tek yüzey: MORTY, SUMMER ve RICK ayrı çalışır; Patron tek karar yüzeyi görür.
UC AJAN, TEK YUZEY
┌───────────────┐
│ ◆ MORTY │ ┌──────────────┐
│ is yapar │◆ │ patron │
│ │ · ┌───────────────┐ │ │
└───────────────┘ ·│ RICK │ │ karar │
sentezler │· · ◆ │ │
┌───────────────┐ ·│ │ │ risk │
│ SUMMER │ · └───────────────┘ │ │
│ izler │· │ next │
│ │ └──────────────┘
└───────────────┘
gorevler daginik olabilir; yuzey tek olmali
MORTY, SUMMER ve RICK ayrı sinyal üretir; okura tek yüzey kalır: karar, risk ve sonraki adım.
Drift'i engellemek değil, görünür tutmak
Burada amaç kusursuz loop kurmak değil. Böyle bir şey yok. Bağlam değiştikçe her loop bir miktar kayar. Önemli olan drift'i ahlaki bir başarısızlık gibi görmek değil, sistemin doğal entropisi gibi izlemek.
Benim pratik kuralım şu: her loop'un yanında küçük bir drift check olmalı.
Bu check uzun bir doküman olmak zorunda değil. Hatta olmamalı. Dört soru yeterli:
- Bu loop bugün hangi niyete hizmet ediyor?
- Dinlediği sinyal hâlâ doğru mu?
- Çıktısı kararımı kolaylaştırıyor mu?
- Hafızaya yazdığı şey yedi gün sonra hâlâ değerli mi?
Bu dört soruya verilen cevap bulanıklaşırsa loop'u büyütmek yerine küçültmek gerekir. Daha fazla kaynak eklemek, daha fazla model çağırmak, daha uzun rapor istemek drift'i çözmez. Çoğu zaman sadece daha pahalı hale getirir.
Bazen doğru hamle loop'u kapatmaktır. Bazen haftalık yapmaktır. Bazen sadece read-only hale çekmektir. Bazen de niyeti yeniden yazıp eski hafızanın bir kısmını budamaktır.
Çalışan sistemi bozmak istemem. “Dokunma, çalışıyor” iyi bir içgüdüdür. Ama “çalışıyor” dediğimiz şeyin neye çalıştığını arada bir sormazsak, sistem kendi yönünü sessizce bizden devralır.
Küçük protokol: Drift review
Kendi loop'larım için kullanışlı bulduğum en küçük review formatı şu:
LOOP:
ORIGINAL INTENT:
CURRENT OUTPUT:
STILL USEFUL? yes / no / narrower
DRIFT SEEN:
KEEP:
CHANGE:
STOP:
Bu formatın güzelliği, teknik detay istememesi. Bir loop'u savunmaya zorlamıyor; sadece hizmet ettiği şeyi görünür yapıyor. Eğer ORIGINAL INTENT satırı boş kalıyorsa zaten cevap belli: önce niyeti yeniden bulmak gerekiyor.
Küçük bir örnek şöyle görünebilir:
LOOP: haftalık kaynak taraması
ORIGINAL INTENT: ürün ve yazı fikri için birkaç temiz sinyal bulmak
CURRENT OUTPUT: uzun liste, az karar
STILL USEFUL? narrower
DRIFT SEEN: kaynak sayısı arttı, karar cümlesi zayıfladı
KEEP: üç iyi sinyal
CHANGE: raporu DID / SAW / NEEDS formatına indir
STOP: arşiv değeri olmayan ham listeyi saklama
Ben bunu özellikle cron tabanlı ajanlarda seviyorum. Çünkü cron, insan zihninde “kuruldu ve bitti” hissi yaratır. Oysa zamanlanmış iş, zamanla daha az değil daha çok denetim ister. Her gün çalışan küçük bir yanlış, ayda bir çalışan büyük bir yanlıştan daha kalıcı iz bırakabilir.
Sonuç: Loop'un karakteri tesadüfe bırakılmaz
Loop Engineering bana göre biraz da bu yüzden prompt engineering'den ayrılıyor. Prompt'ta bir anın kalitesini artırırsın. Loop'ta tekrar eden bir davranışın karakterini tasarlarsın.
Karakter dediğim şey süslü bir metafor değil. Sistem neyi önemser? Neyi görmezden gelir? Ne zaman susar? Ne zaman durur? Ne zaman hafızaya yazar? Ne zaman insana döner? Bunların toplamı zamanla bir karakter üretir.
Niyet kayması da karakterin sessizce değişmesidir.
Bu yüzden iyi loop kurmak, bir kere doğru prompt yazıp kenara çekilmek değil. Arada bir sistemin gözlerinin içine bakıp şunu sormak:
“Sen hâlâ benim kurduğum şeye mi hizmet ediyorsun, yoksa kendi alışkanlığını mı büyütüyorsun?”
Bir sonraki yazıda bunu daha görünür bir katmana taşıyacağım: log ile rapor arasındaki fark. Çünkü loop'un ne yaptığını bilmek yetmiyor; bunu insanın karar verebileceği bir yüzeye çevirmesi gerekiyor.
Sonraki yazı: Görünür loop: Log değil, karar yüzeyi.
Çalışan bir loop güven verici olabilir; ama zamanla niyetinden uzaklaşan sistem, sessizce yanlış şeyi optimize etmeye başlar.