Temmuz 2026'da, AI programlama alanında büyük bir dönüşüm yaşandı. Peter Steinberger, X platformunda döngüsel mühendislik çağının sona erdiğini duyurarak endüstriyi grafik (Graph) mühendisliğine doğru yönlendirdi. Döngüsel mühendislik, Geoffrey Huntley'nin Ralph yöntemiyle ortaya çıkmış olup, AI Agent'larının hedefe ulaşana kadar sürekli çalışmasını sağlayarak bağlam penceresi sınırlarını aşmayı amaçlıyordu. 2026'nın Nisan ve Mayıs aylarında Codex, Claude Code gibi araçlar sırayla Goal işlevini tanıttı ve döngüsel mühendisliği ürün haline getirdi. Şu anda endüstri, organizasyon grafikleri ve çalışma grafiklerinin eş zamanlı tasarımını içeren daha karmaşık grafik mühendisliklerini araştırıyor.

Yazar ve kaynak: WeChat hesabı InfoQ (ID: infoqchina)

Döngüyü hâlâ tartışıyor muyuz, yoksa zaten şemaya mı geçtik?

18 Temmuz 2026'da Peter Steinberger, X platformunda bu cümleyi kullanarak döngüsel mühendislik çağının sonunu duyurdu. Bu gönderi, yayınlanmasından iki gün içinde 2,6 milyon görüntülenme aldı.

Altı hafta önce, “Döngü Mühendisliğinin, İpucu Mühendisliğinin yerini alacağını gösteren tasarım” adlı içerikle 8,4 milyon görüntülenme elde etti ve küresel geliştiricilerin, ipucu mühendisliğinin dönemine son verildiğini, döngü mühendisliğinin yeni yön olduğunu fark etmesini sağladı.

İki gönderi, toplamda 11 milyondan fazla görüntülenme ile AI programlama alanındaki en popüler tartışmaları bir sonraki aşamaya taşıdı.

Döngünün yükselişi

Geçen ay, "Loop Engineering" AI programlama alanında hızla popüler bir kavram haline geldi.

Ancak gerçek kökeni bir yıl öncesine dayanır. 2025 yılının Temmuzunda yazılım mühendisi Geoffrey Huntley, Claude'nin hedefe ulaşana kadar görevleri tekrar tekrar yerine getirmesini sağlayan basit bir Bash döngüsü olan "Ralph" adlı bir yöntem önerdi:

while :; do cat PROMPT.md | claude-code ; done

Ralph yönteminin temelinde, bağlam penceresinin sınırlarını aşmak yer alır. 2025 yılının ortalarında bağlam penceresinin maksimum kapasitesi 200.000 token idi; bu, daha karmaşık görevler için yetersizdi ve bu nedenle Agent çalıştırması daha küçük çalışma birimlerine bölünerek sırayla yürütülmelidir.

Bu bağlamda, Ralph yöntemi şu şekilde çalışır:

• Bir hedef belirleyin ve hedefe ulaşana kadar Agent’ı sürekli çalıştırın veya yeniden çalıştırın.
• Tamamlanan işleri, günlük veya güncellenmiş plan olarak dosya sisteminde sıkıştırılmış biçimde kalıcı hale getirin.
• Yeni bir bağlam ile Agent'i başlatın, böylece "bağlam bozulması" en aza indirilir.
• Gerekli durumlarda, her Agent genel planı ekleyebilir veya değiştirebilir.

Huntley, bu yöntemi kullanarak sıfırdan bir programlama dili oluşturdu ve uygulanabilirliği doğruladı. Ancak daha güçlü modeller ortaya çıkana kadar geliştirici topluluğunda hızla yayılmadı.

Loop'un patlaması, Anthropic ve OpenAI'nin bazı temel geliştiricilerine de borçludur. İlk olarak Anthropic'in geliştirici konferansında, Claude Code'un yaratıcısı Boris Cherny, "Şimdi Claude'a talimat vermiyorum. Claude'a talimat veren ve sonraki adımı belirleyen bazı döngüler çalıştırıyorum. Benim işim döngüleri yazmak." dedi.

Daha sonra Peter Steinberger, geliştiricilere doğrudan programlama Agent'larını uyarımda bulunmayı bırakmaları için bir gönderide bulundu: "Aylık bir hatırlatma: Artık doğrudan programlama Agent'larını elle uyarımlamayın. Agent'ları uyaracak döngüler tasarlamalısınız."

Önceki Google mühendisi Addy Osmani, ardından “Döngü Mühendisliği” adlı bir makale yazarak bunu şöyle özetledi: “Döngü mühendisliği, Agent'e doğrudan talimat verme konumundan çıkıp, bunun yerine sizin için bu işi yapan bir sistem tasarlamaktır.”

Kavram var, isim var, altyapı da hızla ilerliyor.

2026 yılının Nisan ve Mayıs aylarında Codex, Claude Code ve Hermes sırayla /goal komutunu tanıttı, el ile yazılan döngüleri tek bir komuta dönüştürdü.

Ralph'ın yaygın olarak kullanılmasına başlamasından yaklaşık altı ay sonra, Codex goal işlevini yayınladı.

Codex belgesi şunları yazıyor: "Hedefler, Codex içinde kalıcı olan hedeflerdir ve bir diyalog akışının çok sayıda etkileşim boyunca net bir sonuç doğrultusunda ilerlemesini sağlar. Hedefler, Codex'e bir tamamlama koşulu sağlar: hangi durumun geçerli olması gerektiği, başarı nasıl kontrol edileceği ve hangi kısıtlamaların her zaman korunması gerektiği."

Belge özellikle şunu belirtiyor: “Genel ipucu, ‘şunu yap’ anlamına gelir. Goal ise, ‘bu sonuç geçerli olana kadar çalışmaya devam et’ anlamına gelir.”

Normal isteklerde Codex, mevcut talimatı işler, sonucu rapor eder ve sonraki adımı bekler. Goal kullanıldığında, bir sürekli hedef thread'e eklenir. Bir yürütme döngüsü bittikten sonra, mevcut kanıtları kontrol edebilir ve hedefin tamamlanıp tamamlanmadığını belirleyebilir. Cevap hayır ise ve Goal hala etkinse ve bütçe tükenmemişse, Codex en son durumdan çalışmaya devam edebilir.

Örneğin: “Çekim test套件inin her zaman geçmesini garanti altına alarak, checkout benchmarkindeki p95 gecikmesini 120 milisaniyenin altına düşürün.”

Bu, Agent'e doğrudan verilebilecek yeterince net bir “bitirme kriteridir.” Ardından, Agent görevleri kendi başına bölecek, alt Agent'lar oluşturacak ve iş tamamlanana kadar çalışmaya devam edecektir. Codex ekibi, Ralph döngüsünden ilham alarak, birden fazla Agent'ı koordine edip birbirlerini engellememelerini sağlamak; durumu yönetmek; testleri çalıştırmak; Agent'ları başlatmak ve durdurmak için altyapı kurdu; daha sonra bütçe ayarları gibi fonksiyonlar da ekledi.

Hedefler fonksiyonunun mimarisi

Geliştiriciler döngüyü nasıl kullanır

Geliştirici aslında döngüyle ne yapıyor? Topluluk geri bildirimlerine göre, en yaygın senaryo hâlâ periyodik işlerin işlenmesidir.

Ancak döngünün kapasitesi bununla sınırlı değildir. Döngü mühendisliğinin gerçek değerini, sürekli yinelemeye ihtiyaç duyan daha karmaşık uzun vadeli görevler ortaya koyar.

Örneğin büyük ölçekli kod taşıma işlemini tamamlamak. Girişimci Rafel Mendiola, bir React uygulamasını React Native'e dönüştürmek zorunda kaldı. Geleneksel yöntem, büyük bir Epic oluşturup 50 ila 100 adet iş talebi oluşturmakti; altyapıyı kurmak bile korkutucuydu.

Alternatifi, Agent'in taşınabilir kod bloklarını kendi kendine tanımasını, dönüştürmesini ve ilerlemeyi takip etmesini sağlayan bir Beceri oluşturmak ve bu Beceri'yi 30 dakikada bir çalışan bir Cron zamanlayıcıya eklemektir. Büyük bir migrasyon planı yönetmekle karşılaştırıldığında, bu yöntem bilişsel olarak çok daha hafiftir.

Sonraki durak: Graph

Peter'in tweet sorusu aslında bir gelişim yolunu işaret ediyor.

Bir yıl önce, ipucu mühendisliği temel beceriydi. 2025 ile 2026 başı arasında odak, döngü tasarımı üzerine kaydı. Şimdi ise Peter, çok sayıda döngüden oluşan bir grafik tasarımı yönünde işaret ediyor—her bir Agent kendi döngüsünü çalıştırıyor ve bağımlılıklar aracılığıyla birbirine bağlı.

Bu tweet'in tartışmasında en etkileyici yorum Luis Catacora'dan: "Döngülerde büyük bir hata payı vardır. Grafik, iş akışınızın ne kadar kısmının aslında modellenmediğini kabul etmenizi zorunlu kılar."

Bu cümle, bu iki paradigmayı arasındaki farkı ortaya koyar. Döngü, mimari tasarımı ertelemenizi sağlar: Bir Agent'in tüm işleri üstlenmesine izin verin, artık yönetemeyene kadar. Grafik ise tüm yapıyı önceden belirtmenizi gerektirir—kim neyi sorumlu tutuyor, hangi görevler hangi görevlere bağlı, bir dal başarısız olursa ne yapılmalı. Döngü, kararları ertelemektir; grafik, kararları önceden almaktır.

Google'nun üst düzey AI ürün yöneticisi ve Awesome LLM Apps kod deposunun (GitHub'da 124.000'den fazla yıldız) yazarı Shubham Saboo, iki seviyeyi ayırt eden başka bir ayrıştırma sundu: "Sürekli var olan organizasyon şeması, hangi alanın kim tarafından sorumlu olduğunu tanımlar ve bağlamı korur; çalışma şeması ise şu anda ne yapılması gerektiğini tanımlar ve kanıtlara göre bölünebilir, birleştirilebilir, yeniden sıralanabilir veya tamamen kaybolabilir."

Graph tam olarak nedir?

Loop, Agent'in davranışlarını programlanabilir hale getirir. Graph, Agent'in organizasyonlarını programlanabilir hale getirir.

Daha ileri adım, dinamik Agent organizasyonudur: Görev yürütme sırasında Graph, kendi yapısını kendiliğinden yeniden yazacaktır.

Preston Holmes: En az iki Graph önemlidir. Birincisi, uzun ömürlü Agent'lerden oluşan ve her biri bir bölgeye sorumlu olan, grafikte gösterilen Graph'tır. İkincisi, tamamlanması gereken işlerin oluşturduğu Graph'tır. Bu dinamiktir ve sürekli değişir.

Shubham Saboo: Sürekli olan “organizasyon diyagramı”, her bölgenin sorumlusunu belirler ve bağlamı korur. “iş diyagramı”, şu anda hangi görevlerin tamamlanması gerektiğini belirler. Yeni kanıtlar ortaya çıktıkça, bu diyagram bölünebilir, birleştirilebilir, yeniden sıralanabilir veya tamamen kaybolabilir.

Üretim seviyesi çok Agent sisteminin anahtarı: Aslında aynı anda iki grafik çalışıyor.

Organizasyon Şeması (Org Graph): “Kim neyi sorumlu” tanımını yapar. Her bir Agent, sabit bir alana sorumlu olacak şekilde kalıcıdır ve bu alanın bağlamını, uzmanlık yetkinliklerini ve araç erişim haklarını korur. Organizasyon şeması, bir şirketin organizasyon yapısına benzer şekilde nispeten kararlıdır.

Çalışma Grafiği (Work Graph): “Şu anda ne yapmalı ve görevler nasıl akmalı” tanımını içerir. Görevler ve yeni kanıtlarla birlikte değişir, bölünebilir, birleştirilebilir, sıralama değiştirilebilir veya doğrudan iptal edilebilir. Çalışma grafiği, gerçek zamanlı olarak oluşturulan bir proje planına benzer.

Preston Holmes, iki grafiğin de önemli olduğunu ve farklı zaman ölçeklerinde çalıştığını düşünüyor. Organizasyon grafiği önceden tasarlanıp dağıtılır; çalışma grafiği ise her görev için dinamik olarak oluşturulur ve görev tamamlandıktan sonra atılır.

Eğer döngü, Agent'in davranışlarını programlanabilir hale getiriyorsa, grafik Agent'in organizasyonunu programlanabilir hale getirir. Bir sonraki adım, dinamik Agent organizasyonudur—görev yürütme sırasında grafik kendi yapısını kendi kendine yeniden yazar.

İyi bir Prompt yazmaktan, Loop tasarlamaya ve ardından Graph oluşturmana kadar, AI programlama becerisinin odak noktası sürekli yükseliyor. Geliştiriciler artık tek bir Agent ile nasıl iletişim kuracakları yerine, Agent'lar arasındaki iş birliği yapısını nasıl tasarlayacakları üzerinde düşünmeye başlıyor.