Claude Code'da Dinamik İş Akışlarında nasıl uzmanlaşılır: Anthropic mühendislerinin fiilen kullandığı 6 model ve 14 adım

Çoğu Claude Code kullanıcısı hâlâ iş akışlarını elle yazıyor. İstemleri birbirine bağlıyor, çıktıları kopyalıyor, bir sonraki isteme yapıştırıyor, hataları düzeltiyor ve tekrarlıyorlar.

10 geliştiriciden 9'u, iki hafta önce piyasaya sürülmüş olmasına rağmen Dinamik İş Akışları'nı (Dynamic Workflows) bir kez bile denemedi.

Bir iş akışının yapabileceği iş için 50 istem yazıyorlar. İşte bu, Anthropic'in kendi mühendislerinin gerçekte kullandığı 14 adımlık yol haritası ve 6 desen - geçişler, araştırma, sıralama, temel neden, triyaj ve değerlendirmeler için.

En yeni AI alfa içerikleri için Substack'imi takip edin:

movez.substack.com

Dinamik İş Akışları, 28 Mayıs 2026'da Claude Code'da yayınlandı. Varsayılan Claude Code altyapısı kodlama için üretilmiştir - ve bu, çoğu kodlama görevi için iyi çalışır. Ancak tek bir bağlam penceresinin bozulmaya başladığı iş türleri vardır: uzun süreli, büyük ölçüde paralel, oldukça yapılandırılmış veya çekişmeli.

Bunlar için Anthropic eskiden kendi özel altyapılarını oluştururdu (Araştırma, Kod İnceleme, ajan ekipleri). Dinamik İş Akışları ile Claude, bu altyapıyı sizin için anında, görevinize özel olarak JavaScript ile yazar.

14 adım. 6 desen. Elli istem yerine tek bir iş akışı.

Bölüm 1 · Zihinsel Model

01. Bir iş akışı, Claude'un yazdığı bir altyapıdır.

Varsayılan Claude Code altyapısı, Claude'un aynı bağlam penceresinde plan yapmasını ve yürütmesini sağlar. Çoğu kodlama işi için bu harikadır. Uzun süreli, paralel veya çekişmeli işlerde ise bozulur.

Dinamik İş Akışı, Claude'un görev için kendi özel altyapısını yazmasıdır - alt ajanları oluşturan ve koordine eden birkaç özel fonksiyona sahip bir JavaScript dosyası ve aralarında akan verileri işlemek için standart JavaScript (Math, JSON, Array).

Varsayılan altyapının yapamadığı üç şeyi size sunar:

• Ajan başına izolasyon. Her alt ajan, odaklanmış tek bir hedefle kendi bağlam penceresini alır. Çapraz bulaşma olmaz.
• Ajan başına model seçimi. İş akışı, her alt ajanın hangi modeli kullanacağını seçer - zorlu akıl yürütme için Opus, ucuz keşif için Haiku, orta yol için Sonnet.
• Ajan başına izolasyon seviyesi. Worktree (izole git kontrolü) veya remote (kontrol yok). İş akışı, her ajanın neye ihtiyacı olduğuna karar verir.

Birini, Claude'a doğrudan sorarak ("...yapan bir iş akışı oluştur") veya ultracode tetikleyici kelimesiyle başlatın. Bir iş akışı kesintiye uğrarsa - kullanıcı eylemi, terminal kapanması - oturumu devam ettirmek kaldığı yerden devam eder.

02. İş akışlarının çözdüğü 3 başarısızlık modu.

Bir iş akışının ne zaman doğru araç olduğunu bilmek için neyi düzelttiğini bilmeniz gerekir. Claude, karmaşık bir görev üzerinde tek bir bağlam penceresinde ne kadar uzun süre çalışırsa, üç spesifik başarısızlık moduna o kadar yatkın hale gelir - doğrudan Anthropic lansman yazısında adlandırılmıştır:

• Ajan tembelliği - Claude, karmaşık, çok parçalı bir görevi bitirmeden durur ve kısmi ilerlemeden sonra işi bitti ilan eder. Bir güvenlik incelemesindeki 50 maddenin 20'sini ele alır ve geri kalanını "halledildi" olarak işaretler.
• Kendini kayırma yanlılığı - Claude, kendi sonuçlarını bir rubriğe göre doğrulaması veya değerlendirmesi istendiğinde kendi sonuçlarını tercih eder. İşin içinde olan bir doğrulayıcı adil bir doğrulayıcı olamaz.
• Hedef kayması - orijinal hedefe olan bağlılığın, özellikle sıkıştırmadan sonra, birçok turda kademeli olarak kaybolması. Her özetleme adımı kayıplıdır. "X'i yapma" kısıtlamaları 47. turda sessizce kaybolur.

Bir iş akışı, her üçünü de yapısal olarak çözer: kendi bağlamları, odaklanmış hedefleri ve izole durumları olan ayrı Claude'lar. Göreviniz bu kalıplardan herhangi birinden muzdaripse - bu, bir iş akışına yönelme sinyalidir.

03. Statik ve Dinamik iş akışları.

Claude Agent SDK veya claude -p kullanarak zaten statik iş akışları oluşturmuş olabilirsiniz - birden çok Claude Code örneğini koordine etmek.

• Statik iş akışları geneldir: her uç durumu ele almak için bir kez yazılır. Çalışırlar, ancak muhafazakar olmaları gerekir.
• Dinamik İş Akışları farklıdır: Claude bu iş akışını bu görev için yazar. Altyapı, göreve özel olarak hazırlanır. Aşağıda aynı sorunun her iki şekilde ele alınışı bulunmaktadır:

Dinamik sürümün kazanmasının nedeni arama adımı değildir - ikisi de arama yapabilir.

Bunun nedeni, iş akışının kendini sizin bağlamınıza göre şekillendirebilmesidir: faturalama kodunuzu okur, her özelliği gerçek yeni sağlayıcı belgelerine göre kontrol eder, işlem hacminizde fiyatlandırma yapar ve kendi ortaya çıkan cevabına karşı "neden geçiş yapmamalısınız" şeklinde çekişmeli bir geçiş yapar.

Statik bir altyapı bunu yapamaz çünkü kodunuzun var olduğunu bilmez.

04. Temel API. agent(), parallel(), pipeline().

Bir iş akışındaki işin çoğunu üç fonksiyon yapar. Bunları bilmek, Claude'un sizin için yazdığı herhangi bir iş akışını okumak ve belirli bir şekil istediğinizde Claude'u yönlendirmek için yeterlidir.

parallel() bir bariyerdir: dallara ayrılır, ardından her şey dönene kadar bekler. pipeline() akıştır: her öğe, her aşamadan bağımsız olarak geçer.

Soruna göre seçim yapın: bir sonraki adımı atmadan önce tüm sonuçlara ihtiyacım var mı? Evet → parallel. Hayır → pipeline (daha ucuz, genel olarak daha hızlı).

05. Sınıflandır-ve-harekete-geç. İşi yapmadan önce yönlendirin.

Bir sınıflandırıcı ajan, görevin türüne karar verir, ardından iş akışı, cevaba göre farklı ajanlara veya davranışlara yönlendirir. Veya bir sınıflandırıcı sonda çalışır, ham çıktıları bir sonraki adım için gruplara ayırır.

Bu desenin değerini gösterdiği durumlar:

• Görev heterojendir - farklı alt türler farklı işlem gerektirir.
• Pahalı modeli yalnızca karmaşıklığın gerektirdiği yerde harcamak istersiniz (sınıflandırıcı ucuz modelde, ardından yalnızca gerektiğinde Opus'a yönlendirin).
• İşin ayrıştırılması, kendi başına önemsiz değildir ve şekle karar vermesi için bir modelden faydalanır.

Örnek: "Auth modülünün nasıl çalıştığını açıkla." Bir sınıflandırıcı alt ajan önce kod tabanını okur, karmaşıklığı tahmin eder, ardından gerçek açıklama görevini 10 dosyalık bir modül için Sonnet'e veya 100 dosyalık bir modül için Opus'a yönlendirir. İş anlaşıldıktan sonra iş için doğru model seçilir.

06. Dallan-ve-sentezle. Birçok küçük adım, tek bir birleştirilmiş sonuç.

Bir görevi birçok küçük adıma bölün. Her adımda paralel olarak bir ajan çalıştırın. Sonuçları tek bir cevapta sentezleyin.

Sentezleme adımı bir bariyerdir - her dallanan ajandan gelen sonuçları bekler, ardından yapılandırılmış çıktılarını birleştirir.

Bu desenin pratikte neden baskın olduğu: tek bağlamlı çalışmanın "aynı anda çok fazla şey" başarısızlığını çözer. Her alt ajan yalnızca kendi parçasını görür. Orkestratör asla 50 ilgisiz ayrıntıyla dikkati dağılmaz.

Her adım, kendi temiz penceresinden faydalanır, böylece çapraz bulaşma olmaz.

Bunu şu durumlarda kullanın:

• Açıkça sıralanabilir bir iş öğeleri listeniz var (50 dosya, 200 uç nokta, 100 inceleme).
• Her öğe bağımsızdır - hiçbir öğenin başlamak için başka bir öğenin çıktısına ihtiyacı yoktur.
• Sonunda tek bir birleştirilmiş cevap istiyorsunuz, bir yığın kısmi rapor değil.

1// Dallan: dosya başına bir ajan. Bariyer: hepsini bekle.
2const reviews = await parallel(
3  files.map(file => () => agent(
4    `${file} dosyasını güvenlik sorunları için incele`,
5    { model: "haiku", schema: IssueList }
6  ))
7)
8
9// Sentezle: bir Opus ajanı her şeyi birleştirir.
10const report = await agent(
11  `Bu incelemeleri tek bir önceliklendirilmiş raporda birleştir:\n${JSON.stringify(reviews)}`,
12  { model: "opus" }
13)

07. Çekişmeli doğrulama

Bu, kendini kayırma yanlılığı için yapısal düzeltmedir. Oluşturulan her ajan için, çıktısını bir rubriğe göre çekişmeli bir şekilde doğrulayan ayrı bir oluşturulmuş ajan çalıştırın. Doğrulayıcı, orijinal çalışmayı hiç görmemiştir; onu kayıramaz.

Desen en çok şunlar için önemlidir:

• İddia kontrolü - bir rapordaki her olgusal ifade, orijinal kaynağa karşı kontrol eden kendi doğrulayıcı alt ajanını alır.
• Kod incelemesi - yazar ajan düzeltmeyi yazar, inceleyici ajan (ayrı bağlam) onu inceler. Asla aynı Claude kendini yargılamaz.
• Kalite kapıları - herhangi bir yapıt gönderilmeden önce, bir rakip ona karşı en zayıf durumu bulmaya çalışır. Rakip bulamazsa, gönderirsiniz.

Eşleştirme kuralı: doğrulayıcı, yalnızca rubriği ve yapıtı bilmelidir, onu kimin ürettiğini değil. Aksi takdirde, istemdeki ipuçlarıyla kendini kayırma geri sızar.

08. Oluştur-ve-filtrele.

Bir konu hakkında bir dizi fikir oluşturun, ardından bunları bir rubriğe veya doğrulamaya göre filtreleyin. Kopyaları çıkarın. Yalnızca en yüksek kaliteli, test edilmiş fikirleri döndürün.

Bu desenin parladığı yerler:

• Beyin fırtınası - 30 ürün adı, ardından bir doğrulayıcı klişeleri, ticari marka çakışmalarını ve zayıf fonetikleri eler. 3 tane görürsünüz.
• Hipotez oluşturma - Bir soruna 5 farklı yaklaşım, ardından her biri kısıtlamalarınıza göre puanlanır. Kazanan bunu hak etmiştir.
• Çözüm tasarımı - Bir soruna 5 farklı yaklaşım, ardından her biri kısıtlamalarınıza göre puanlanır. Kazanan bunu hak etmiştir.

Claude'dan "en iyi cevabı" istemenin tam tersi. En iyi cevabı istemek, Claude'un erken taahhütte bulunmasına neden olur. Oluştur-ve-filtrele, Claude'un her seçeneğe meydan okunduktan sonra geç taahhütte bulunmasını sağlar.

09. Turnuva. İkili karşılaştırma, mutlak puanlamadan daha iyidir.

İşi bölmek yerine, ajanların bu konuda rekabet etmesini sağlayın. Her biri farklı yaklaşımlar kullanarak aynı görevi deneyen N tane ajan oluşturun, ardından sonuçları biri kazanana kadar ikili olarak değerlendirin.

Karşılaştırmalı yargı, mutlak puanlamadan daha güvenilirdir - özellikle zevke dayalı işler için.

Bunun puana göre sıralamayı neden yendiği: 1.000 öğeyi tek bir istemde sıralamaya çalışmak iki cephede başarısız olur - kalite düşer ve bağlama sığmaz. Bir turnuva, her biri yalnızca iki öğeyi karşılaştıran yeni ajanlar arasında parantezi böler.

Parantezin kendisi, bağlamda değil, deterministik döngü kodunda yaşar. Her karşılaştırma hızlı, adil ve izoledir. Aynı fikir, zevke dayalı sıralama için de işe yarar: tasarım seçimleri, aday seçimi, içerik önceliklendirmesi.

10. Bitene kadar döngüye al.

Bilinmeyen miktarda iş içeren görevler için, sabit sayıda geçiş çalıştırmak yerine, bir durma koşulu karşılanana kadar (yeni bulgu yok, günlüklerde daha fazla hata yok, teori doğrulandı) ajanlar oluşturan döngüye alın.

Bu desen, "gerçekten bitene kadar devam et" sorusunun cevabıdır:

• Tutarsız test hata ayıklaması - tekrarla, teoriler oluştur, test et, bir teori doğrulanana kadar.
• Hata avı - tam bir geçiş sıfır hata dönene kadar hata bulmaya devam et.
• Desen madenciliği - kümele, kuralları belirle, yeni kümeler görünmeyene kadar.

Bu deseni, zor bir tamamlama gereksinimi belirlemek için /goal ile ("bir teori işe yarayana kadar durma") ve tüm iş akışının kendisini periyodik bir programda çalıştırmak istiyorsanız /loop ile eşleştirin.

Parantez ve durma koşulu kodda yaşar; yalnızca aktif yineleme bağlamda kalır.

11. Gerçek kullanım durumları için desenleri birleştirin. Tek bir iş akışı, birkaç desen.

6 desen nadiren tek başına görünür. Gerçek bir iş akışı, bunlardan 2-4'ünü birleştirir. Aşağıdaki matris, Anthropic lansman yazısındaki her kullanım durumunu kullanma eğiliminde olduğu desenlerle eşleştirir:

• Geçişler ve yeniden düzenlemeler. Dallan (bir worktree'deki her çağrı sitesi/başarısız test için bir ajan) → çekişmeli doğrulama (ayrı bir ajan her düzeltmeyi inceler) → bitene kadar döngüye al. Anthropic'in Bun'u Zig'den Rust'a yeniden yazmak için kullandığı desen budur.
• Derin araştırma (/deep-research becerisi). Dallan (paralel web aramaları) → çekişmeli doğrulama (her iddia bağımsız olarak doğrulanır) → sentezle (tek bir alıntılı rapor).
• Bir taslağın derinlemesine doğrulanması. Tüm olgusal iddiaları belirle (bir ajan) → dallan (iddia başına bir doğrulayıcı, her ajan kaynağa karşı kontrol eder) → meta-doğrulayıcı (doğrulayıcının kaynaklarının yüksek kalitede olup olmadığını kontrol eder).
• 1.000'den fazla öğeyi sıralama. Turnuva (5-9. adımlar) - ikili karşılaştırma, grup sıralaması veya parantez. Karşılaştırmalı yargı, asla mutlak puanlama değil.
• Bellek ve kurala uyum. Kural başına doğrulayıcı (dallan) → şüpheci kişilik, yanlış pozitifleri önlemek için kuralların kendisini inceler.
• Temel neden araştırması. Bağlantısız kanıtlardan teoriler oluştur (farklı ajanlar günlükleri, dosyaları, verileri okur) → her teori için bir doğrulayıcı ve çürütücü paneli → biri hayatta kalana kadar döngüye al.
• Ölçekte triyaj. Sınıflandır-ve-harekete-geç → mevcut biletlere karşı kopyaları temizle → ya düzeltmeyi dene ya da yükselt. Sürekli triyaj için /loop ile eşleştir.
• Keşif ve zevk (tasarım, adlandırma, UI seçimleri). Oluştur-ve-filtrele (5-20 seçenek) → bir rubrikle turnuva → sırala veya seç.
• Hafif değerlendirmeler. Adayı bir worktree'de çalıştır → karşılaştırma ajanları rubriğe göre not verir → iyileştir ve yeniden not ver. Sıralama için değil, not verme için bir turnuvayla aynı şekil.

Bunları içselleştirmenin doğru yolu: mevcut görevinizin hangi başarısızlık modu altında olduğunu belirleyin, ardından onu yapısal olarak önleyen deseni seçin.

Kayma → dallan. Kendini kayırma → çekişmeli doğrulama. Açık uçlu → bitene kadar döngüye al. Puanlaması zor → turnuva.

12. /goal, /loop ve token bütçeleriyle eşleştirin.

İş akışları pahalı olabilir. Üç kontrol, onları "havalı ama maliyetli" olmaktan "gözetimsiz çalıştırdığım bir araç" haline getirir.

• /goal zor bir tamamlama gereksinimi belirler. Döngü deseniyle eşleştirin: "bir teori işe yarayana kadar durma." /goal olmadan, bir iş akışı yumuşak bir tamamlama noktasında durur. /goal ile, gerçek bitiş koşulu karşılanana kadar yinelenir.
• /loop tüm iş akışını periyodik bir programda çalıştırır. Sürekli çalışmasını istediğiniz iş akışları için kullanın - triyaj, haftalık araştırma güncellemeleri, tekrarlayan doğrulama.
• Açık token bütçeleri. Claude'a istemde şunu söyleyin: "10k token kullan." Bu, iş akışı çalışmasına bir sınır koyar. Bir sınır olmadan, iddialı bir iş akışı beklediğiniz tokenlerin 5-10 katına kadar şişebilir.

<code-code-segment id="seg_1" lang="python">

ultracode bu varsayımın hızlı çekişmeli incelemesi:

"Postgres'e geçmek, parça yeniden dengelememizi ortadan kaldırır."

5k token kullan. /goal ya bir karşı örneğin ya da

üç bağımsız onayın olana kadar durma.

</code-code-segment>

Claude Code ekibinden doğrudan alıntı: "En iyi uygulamalar hâlâ gelişiyor. Dinamik iş akışları genellikle daha fazla token kullanır, bu nedenle bunları ne zaman ve nasıl kullanacağınızı dikkatlice düşünün." Çoğu geleneksel kodlama görevi 5 kişilik bir inceleme paneline ihtiyaç duymaz.

Kendinize sorun: bu görev gerçekten daha fazla hesaplama gücü gerektiriyor mu? Normal bir Claude Code oturumu bunu beş dakikada bitirecekse, bir iş akışına ihtiyacınız yoktur.

13. Güvenilmeyen girdi için karantina desenini kullanın.

Güvenilmeyen herkese açık içeriği okuyan herhangi bir iş akışı - destek biletleri, hata raporları, kullanıcı geri bildirimleri, kazınmış veriler - bu içeriğin istem enjeksiyonu içerebileceğini varsaymalıdır.

Düzeltme: karantina. Güvenilmeyen içeriği okuyan ajanların herhangi bir yüksek ayrıcalıklı eylemde bulunmasını engelleyin. Ham içeriğe maruz kalmayan ayrı ajanlar eylemi gerçekleştirir.

Kullanıcı tarafından gönderilen içeriği işleyen (destek biletleri, hata raporları, müşteri geri bildirimleri, sosyal medya), herkese açık web sayfalarını kazıyan veya bir üçüncü taraf API'sinden gelen çıktılara karşı çalışan herhangi bir iş akışı.

Girdi sizin veya güvendiğiniz bir ekip arkadaşınız tarafından yazılmadıysa, onu karantinaya alın. 30 satırlık salt okunur bir okuyucu ajan neredeyse hiçbir maliyete sahip değildir ve tüm bir istem enjeksiyonu risk sınıfını ortadan kaldırır.

14. İş akışlarını kaydedin. Bunları Beceri olarak gönderin.

Bir iş akışı çalıştıktan sonra kaydedin: iş akışı menüsünde s tuşuna basın. Kaydedilen iş akışları ~/.claude/workflows adresine gider. Buradan iki yolunuz vardır:

• Yerel tutun - kendi projelerinizde yeniden kullanın.
• Beceri olarak gönderin - JavaScript dosyasını bir Beceri klasörünün içine paketleyin, SKILL.md'de referans verin ve Beceriyi yükleyen herkes aynı iş akışını çalıştırır.

Bilmeye değer pratik bir nüans: bir iş akışını bir Beceriye paketlediğinizde, Claude'a iş akışını kelimesi kelimesine çalıştırılacak bir betik olarak değil, bir şablon olarak ele almasını söyleyin.

Bu, genel yapıyı korurken Claude'un iş akışı şeklini eldeki belirli göreve uyarlamasına yer bırakır. Özellikle kullanım durumuna göre esnemesi gereken "derin doğrulama" veya "triyaj" gibi iş akışları için kullanışlıdır.

İş akışlarında token israfına neden olan hatalar

• Normal bir Claude Code oturumunun yeterli olacağı yerde bir iş akışına yönelmek. Çoğu geleneksel kodlama görevi 5 kişilik bir inceleme paneline ihtiyaç duymaz.
• Token bütçesi olmaması. İddialı iş akışları, açık bir sınır olmadan beklediğinizin 5-10 katına kadar şişer.
• Hem işi hem de doğrulamayı yapan tek bir ajan. Kendini kayırma yanlılığı, doğrulayıcının çalışanı kayırmasına neden olur. Ayrı olmalıdırlar.
• parallel() ve pipeline()'ı birbirinin yerine kullanılabilir olarak ele almak. Bariyer önemlidir - parallel hepsini bekler, pipeline akış yapar.
• Döngü desenlerinde /goal atlamak. İş akışı, ilk yumuşak tamamlama noktasında erken durur. /goal, zor tamamlamayı zorunlu kılar.
• Güvenilmeyen içeriğin aktöre ulaşmasına izin vermek. Kullanıcı tarafından gönderilen herhangi bir şeyi işlediğinizde karantina isteğe bağlı değildir.
• Mutlak puanlarla sıralama. Karşılaştırmalı yargı daha güvenilirdir. Bir turnuva kullanın.
• Çalışan iş akışlarını asla kaydetmemek. Her hafta aynı şekli yeniden istemlemek. s ile kaydedin, Beceri olarak gönderin.

Sonuç:

https://x.com/_catwu/status/2060054180379689074