DEV Community

Cover image for Loop engineering nedir, her işe değer mi?
Hüseyin Bozdemir
Hüseyin Bozdemir

Posted on Originally published at huseyinbozdemir.com on

Loop engineering nedir, her işe değer mi?

Prod'a doğrudan çıkmayacak hemen her işi yapay zekâya yaptırıyorum. Önce mimari incelemesini yaptırıyorum, sonra çıktıyı kendim inceliyorum, uygunsa prod'a gönderiyorum.

Bu akışta işi yine ben başlatıyorum ve sonucu yine ben okuyorum. Bu yıl çok konuşulan loop engineering ise aradaki adımların büyük kısmını ajanın çevresine kurulan bir sisteme devretmeyi anlatıyor. Türkçe kaynağı az olduğu için önce kavramı netleştireyim, sonra sınırı nereye koyduğumu anlatayım.

Loop engineering nedir?

Loop engineering (döngü mühendisliği), yapay zekâ ajanına her adımı tek tek söylemek yerine onu çalıştıran, sonucunu kontrol eden ve gerekirse yeniden çalıştıran sistemi tasarlamaktır. Terim Haziran 2026'da yayıldı. Sık anılan metinlerden biri Addy Osmani'nin 7 Haziran tarihli yazısı.

Osmani'nin örneği konuyu iyi anlatıyor. Her sabah bir otomasyon CI hatalarını ve açık issue'ları okuyor. Uygun bulduğu iş için ayrı bir çalışma kopyası (worktree) açılıyor, bir ajan düzeltmeyi hazırlıyor, ikinci bir ajan da onu inceliyor. Geliştirici bu adımları tek tek istemiyor.

Alışkın olduğumuz akışta prompt yazar, çıktıyı okur ve sıradaki adımı yine sen yazarsın. Döngüde bu turu bir sistem döndürür. Kabaca şöyle görünür:

hedef: bütün testler geçsin
tur sınırı: 5

her turda:
  ajan işi yapar
  testler çalışır
  geçtiyse: dur, insana gönder
  geçmediyse: hatayı ajana ver

sınır dolduysa: dur, haber ver
Enter fullscreen mode Exit fullscreen mode

Terim, "agent loop" ile sık karıştırılıyor. Google'ın sözlüğü agent döngüsünü, ajanın bir sonlandırma koşulu karşılanana kadar tekrar tekrar ilerlediği döngü olarak tanımlıyor. Yani agent loop ajanın kendi çalışma turu. Loop engineering ise bu turların ne zaman başlayacağını, nasıl kontrol edileceğini ve ne zaman duracağını tasarlama işi.

Kavramın yeni olup olmadığı da tartışılıyor. HackerNoon'daki bir yazı bunun Kent Beck'in kırmızı, yeşil, refactor döngüsünün ajana devredilmiş hali olduğunu savunuyor. Benzerlik gerçek: ikisinde de işi döndüren şey, geçip geçmediği ölçülebilen bir hedef.

Prompt, context, harness ve loop farkı

Bu dört terim sık sık birbirine karışıyor. Machine Learning Mastery'nin girişi bunları iç içe katmanlar olarak sıralıyor. Her katman öncekini içeriyor, yerine geçmiyor.

Katman Neyi tasarlarsın? Örnek
Prompt Modele verdiğin talimatın kendisini "Bu metodu sadeleştir"
Context Modelin yanıt verirken gördüğü her şeyi Konuşma geçmişi, belgeler, araç çıktıları
Harness Ajanın içinde çalıştığı düzeni Kural dosyaları, araçlar, kısıtlar
Loop Ajanın ne zaman çalışıp ne zaman duracağını Zamanlayıcı, kontrol adımı, durma koşulu

Context için Anthropic'in Eylül 2025 yazısı, harness için Mitchell Hashimoto'nun Şubat 2026 yazısı iyi başlangıç noktaları. Hashimoto'nun tarifi akılda kalıcı: ajan bir hata yaptığında, o hatayı bir daha yapmayacağı bir düzen kurmak. Ama tanımlar henüz oturmadı ve kaynaktan kaynağa değişiyor.

Bir döngünün parçaları

Tetikleyici döngüyü başlatır. Ajan işi yapar, sonuç kontrol edilir, durum kaydedilir; iş bitmediyse tur başa döner. Döngü bitince sonuç prod'a doğrudan gitmez, önce insan inceler.

Kaynaklar küçük farklarla aynı parçaları sayıyor:

  • Tetikleyici: Döngüyü ne başlatıyor? Bir zamanlayıcı, kırılan bir CI işi ya da yeni açılan bir issue olabilir.
  • Test edilebilir hedef: "Bitti" neye göre bitti? Hedef kötü yazılırsa döngü yanlış şeyi hızla iyileştirir.
  • Kontrol: Test ve derleyici gibi aynı girdide aynı sonucu veren araçlar önce gelir. Osmani yazan ile kontrol edeni ayırmayı öneriyor, çünkü kendi ödevini notlandıran model fazla iyimser oluyor.
  • Durma koşulu: Tur sınırı, bütçe ve ilerleme olmadığını fark eden bir kontrol. Bunlar yoksa döngü token yakmaya devam eder.
  • Hafıza: Model iki çalışma arasında her şeyi unutur. Neyin bittiğini ve sırada ne olduğunu konuşmanın dışında, bir dosyada ya da panoda tutman gerekir.

Ne zaman işe yarar, ne zaman yaramaz?

İyi aday, tekrar eden ve sonucu makineyle kontrol edilebilen iştir. Osmani'nin örneğindeki CI hataları buna uyuyor: sorun bellidir, düzeltme testle sınanır.

Tek seferlik işte durum tersine döner. Machine Learning Mastery, böyle bir işte normal bir ajan oturumunun daha hızlı ve daha güvenli olabileceğini yazıyor. SSD Nodes'un rehberi de ucu açık refactor ve tasarım işlerini henüz uygun görmüyor.

Kontrol adımı da tek başına güvence değil. Machine Learning Mastery'nin verdiği hata örneği, ajanın kırık testi silerek CI'ı yeşile çevirmesi. Ben de AI'ın yazdığı testleri ölçerken kapsam ve mutation skoru %100 çıktığı halde hatanın kaçabildiğini görmüştüm. Yeşil bir sonuç, kontrolün baktığı kadarını söyler.

Faydası da henüz net ölçülmüş değil. Ağustos'ta yayımlanan bir makale 36.710 açık kaynak depoyu tarayıp 217'sinde otonom ajan döngüsü buluyor. Aynı çalışmaya göre konuyu anlatan blog ve rehberler, iddia ettikleri faydalar için sistematik kanıt sunmuyor. Maliyet tarafında da Osmani, alt ajanların daha çok token harcadığını özellikle hatırlatıyor.

Prod kapısı neden insanda kalıyor?

Benim sınırım prod. Hemen her işi yaptırırım ama sonucu incelemeden prod'a göndermem. Neyi incelediğim de projeye göre değişiyor. Backend'de bir iş yaptırıyorsam git diff'ten neler yaptığına bakıyorum ve istediğim mimaride mi diye inceliyorum.

Testler kodun çalışıp çalışmadığını söyler, istediğin mimaride olup olmadığını söylemez. Bu yüzden diff'i okuyan birine hâlâ ihtiyaç var.

Kaynaklar da bu noktada aynı yere çıkıyor. Osmani'ye göre döngünün "bitti" demesi kanıt değil, bir iddia. Üretilen kodu okumazsan sahip olduğun anlayış ile var olan kod arasındaki fark büyüyor; buna anlama borcu (comprehension debt) diyor. Machine Learning Mastery de finansal işlem ve veritabanına yazma gibi hassas adımlardan önce açık insan onayı öneriyor.

İlk döngünü nasıl kurarsın?

Küçük bir işle başla. "Bitti" tanımını çalıştırılabilir bir komut olarak yaz, örneğin bir test komutu. Tur sınırı koy ve döngünün sonucunu prod'a değil, bir PR olarak açtır. Birkaç PR'ı okuduktan sonra hangi kontrollerin eksik kaldığını görürsün.

Scion yazısında review yükünün arttığını yazmıştım. Döngü bir sabahta on PR açtığında bunları kimin okuyacağı ise henüz cevabı net olmayan bir soru.


Bu yazı ilk olarak huseyinbozdemir.com'da yayımlandı.

Top comments (0)