Geçtiğimiz ay gündemi tararken aynı örüntü inatla önümüze düştü. Anatoli Kopadze'nin 12 milyon kez görüntülenen bir yazısı, tam da aylardır mırıldandığımız şeyi söylüyordu: çoğumuz AI'ı yıllardır elimizde tutuyoruz ama hâlâ en yavaş viteste kullanıyoruz.
Bir şey yaz, bekle, düzelt, tekrar sor. Her adım senden geçiyor. Sen durduğun an, AI da duruyor. Yani asıl bottleneck AI değil — sensin. İşte tam burada bir kırılma var ve adı da konmuş: loop engineering.
“Loop” ne demek, neden herkes aynı anda konuşuyor?
Basitçe: loop, kendi kendini tetikleyen bir prompt. Sen AI'ya tek tek talimat vermiyorsun — bir hedef tanımlıyorsun, o deniyor, sonucu kontrol ediyor, düzeltiyor, tekrar deniyor. Sen uyurken bile.
Cobus Greyling'in konuyu toparladığı repo'da tanım çok net: loop engineering, agent'ı prompt'layan kişi olmaktan çıkıp o işi yapan sistemi tasarlamak demek. Yani artık kürek çekmiyorsun; kürek çeken makineyi kuruyorsun.
Bunu havadan söylemiyoruz. Claude Code'un yaratıcısı Boris Cherny geçen ay şöyle dedi: “Loop'lar, agent'lardan bir sonraki adıma geçiş — kaynak koddan agent'lara geçmek kadar büyük bir sıçrama.” Kendi ifadesiyle, artık Claude'u o prompt'lamıyor; kurduğu loop'lar prompt'luyor. Ortalama bir günde kodunun üçte birini kendisi değil, loop'ları yazıyor.
Bir tarafta Anthropic'in Opus 4.8'e eklediği Dynamic Workflow var — Claude bir orkestrasyon script'i yazıyor, sub-agent'ları deploy ediyor, çıktılarını doğrulyor, sonucu sunuyor. Diğer tarafta aynı hafta çıkan onlarca araç. Aynı dil, aynı anda. Tesadüf değil. Ve şunu görüyoruz: iyi prompt yazmakla iyi loop kurmak aynı kas değil.
Peki bu iş pratikte nasıl işliyor?
En sevdiğimiz çerçeveyi Lenny's Podcast'ten Claire koydu: bir loop'u, birini işe alır gibi düşün. Neyi kontrol edecek, ne sıklıkta, hangi çıktıyı istiyorsun, bir şey ters giderse kime haber verecek? “Her cuma 10.00'da tüm merge edilen PR'ları incele ve eksik kalan becerileri çıkar” — bu bir iş tanımı. Aynı zamanda bir loop.
İşin güzel yanı: başlamak için kod bile gerekmiyor. Claude Cowork'te her sabah takvimini ve mailini kontrol edip sana özet geçen bir scheduled task — o zaten çalışan bir loop. Gerisi bunu büyütmek.
Bunun ciddi hali de var. Mozilla'dan Brian Grinstead, bir ayda Firefox'a 423 güvenlik düzeltmesi göndermiş. Sırrı daha iyi bir model değil, modelin etrafına kurdukları harness olmuş: dosyaları riskine göre puanlayan bir LLM hakem, hedef odaklı loop'lar, hataları doğrulayan sub-agent'lar ve döngüde kalan bir insan gözü. Agent yorulmuyor — bir bug'ı tetiklemek için 14 kez deniyor, insanın çoktan “boş ver ya” dediği yerde o hâlâ deniyor.
Momentumun gerçek olduğunu gösteren sinyaller de bunu doğrulyor: Microsoft “her zaman açık” kişisel agent Scout'u tanıttı; Higgsfield pazarlamayı uçtan uca yürüten, her run'dan öğrenen bir agent playbook'u paylaştı.
Ama loop bedava değil — asıl mesele burada başlıyor
Şüpheci tarafı atlamayalım, çünkü haklılar. Loop çalıştırmak, token-zengini bir yerden bakınca çok kolay görünüyor. Goldman Sachs'ın modeline göre agentic token tüketimi dört yılda 24 katına çıkacak. Sınırsız bütçeyle “döngüyü çalıştır” demek başka; ay sonu bütçesi kısıtlı bir yerden aynı tavsiye neredeyse imkânsız.
Cobus'un repo'sundaki uyarılar da tam bu noktada: sub-agent'lar ve uzun loop'larla token maliyeti patlayabilir. Doğrulama hâlâ sende — gözetimsiz loop, gözetimsiz hata üretir. Ve bir “comprehension debt” birikiyor: loop'un ne gönderdiğini okumazsan, sistemi anladığını sanıp aslında yavaş yavaş kaybediyorsun. Addy Osmani bunu güzel özetlemiş: loop'u kur, ama “başlat”a basıp çekilen kişi gibi değil, mühendis olarak kalacakmış gibi kur.
Brick tarafında biz nasıl bakıyoruz?
Aslında bu bir öğrenme meselesi. İyi haber şu: bilgi bedava. Stanford, Anthropic'in yüksek maaşla aradığı LLM mimarisini 1 saatlik ücretsiz bir derste anlattı. Loop engineering repo'su açık. Agentic design pattern'leri, ücretsiz müfredatlar ortalıkta.
Ama bilgi ≠ beceri. Bir loop'u okumak başka, kendi işine oturan bir loop kurup token'ını, çıktısını, nerede insan müdahalesi gerekttiğini görmek başka. Bu tuğla tuğla, yaparak öğrenilir. AI konusunda tavrımız değişmedi: ne hype ne ret. Deneyeceksin, ölçeceksin, sana uyuyor mu göreceksin.
Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
İyi ürün ekipleri tek bir yöntemle çalışmaz. Tasarım odaklı düşünme, Lean ve Agile çoğu zaman rakip gibi anlatılır — oysa doğru anda doğru olanı kullandığında üçü birbirini tamamlar.
Bu üç yaklaşımın hepsi belirsizliği azaltmaya çalışır, ama farklı sorular sorar. Tasarım odaklı düşünme “doğru problemi mi çözüyoruz?” diye sorar. Lean “bu çözüm işe yarıyor mu?” diye test eder. Agile ise “bunu nasıl sürekli ve güvenilir biçimde teslim ederiz?” sorusuna odaklanır. Ürün keşfi dediğimiz şey, çoğu zaman bu üçünün iç içe geçmesidir.
Design Thinking
Doğru problemi bul, kullanıcıyı anla.
Lean
En küçük deneyle hipotezi test et.
Agile
Küçük adımlarla sürekli teslim et.
Önce doğru problemi bul
Tasarım odaklı düşünme, çözüme atlamadan önce bağlamı anlamaya zaman ayırır. Saha görüşmeleri, gözlem ve müşteri yolculuğu haritaları, ekibin gerçek ihtiyacı varsayımlardan ayırmasına yardımcı olur. Buradaki amaç mükemmel bir çözüm değil; doğru soruyu netleştirmektir.
- Müşteriyle konuş — anketten önce, kod yazmadan önce.
- Problemi bir cümlede ifade edebilene kadar daraltma yapma.
- Çözüm fikirlerini erken ama ucuz biçimde görselleştir.
“Hızlı karar veren ekipler daha az toplantı yapan değil, daha küçük bahisler oynayan ekiplerdir.”
— Martin Eriksson, Alive Konf 2026Sonra hipotezi ucuza doğrula
Lean yaklaşımı, fikri tam ölçekli inşa etmeden test etmeyi önerir. Bir açılış sayfası, sahte bir buton ya da elle yürütülen bir hizmet — hepsi öğrenmek için yeterli olabilir. Önemli olan, her deneyin net bir hipotezi ve bir başarı ölçütü olması.
Lean ve Agile aynı şey değil
İkisi sık karıştırılır. Lean ne yapacağına dair belirsizliği azaltır; Agile nasıl teslim edeceğine dair belirsizliği azaltır. Biri keşif, diğeri teslim disiplinidir.
Lean — Keşif
- Hipotez kurar
- Doğrulanmış öğrenme
- Yön belirsizliği
Agile — Teslim
- Yinelemeli teslim
- Sürdürülebilir tempo
- Uygulama belirsizliği
Amaç, hizalama ve özerklik
Üçünü birlikte işe koşmanın sırrı süreçte değil, kültürde. Net bir amaç ekibe yön verir; iyi bir hizalama ekibin aynı hedefe koşmasını sağlar; özerklik ise her bireyin günlük kararları kendi vermesine alan açar. Bu üçü olmadan hiçbir çerçeve ekibi kurtarmaz.
Sonuç olarak yöntem bir araç kutusudur, bir din değil. Hangi soruyu sorduğunu bilen ekip, doğru aracı sezgiyle seçer — ve birlikte daha cesur kararlar alır.