Makaleler
Fan-out'u artık akılsızca yapmayın: Claude Haiku 5.5 ile dört katmanlı orkestrasyon mimarisi uygulamada
Claude Haiku 5.5 hızlı ve ucuz; ama tüm görevleri paralel olarak ona yığmak yalnızca yanlış kararları, değerlendirici yanlılığını ve Supply Chain risklerini büyütür. Bu yazı şu katmanlı mimariyi ele alıyor: Fable ile karar, Opus ile orkestrasyon, Sonnet ve Haiku ile uygulama, CI ile doğrulama, Opus ile kabul. Ayrıca hangi görevlerin Fan-out'a değdiğini anlatıyor.
· 6 dk okuma
Claude Haiku 5.5, 7 Ekim 2026'da çıktı. Prompt 100 bin token'ın altındayken fiyatı Sonnet 5.5'in yirmide biri, gecikmesi ise bu nesil Claude modelleri arasındaki en düşük.
Hem ucuz hem hızlı olunca şunu yapmak çok cazip geliyor: Tüm coding görevlerini parçalayıp bir Haiku sürüsüne paralel olarak vermek, bitince de işi kapatmak.
Prototip aşamasında bu belki işe yarar. Gerçek bir mühendislik ortamına koyduğunuzda ise çabucak üç sorunla karşılaşırsınız:
- Küçük modeller belirsizlikle başa çıkmaya uygun değildir. Haiku 5.5'in resmî konumlandırması sınıflandırma, çıkarım, yönlendirme ve subagent gibi yüksek hacimli, düşük gecikmeli işlerdir. Gereksinim iş açısından belirsizse ve sistemin tamamının bağlamını gerektiriyorsa, tam görünen ama aslında yanlış yöne tahmin edilmiş sonuçlar vermesi çok kolaydır.
- Cevabı modele seçtirmek değerlendirici yanlılığı doğurur. Onlarca çıktıyı büyük bir modele okutursanız, mantığı ve çalışması gerçekten doğru olan sürümü değil, "mimarisi güzel görünen" sürümü seçmeye meyleder.
- Yetkiler Worker sayısıyla birlikte büyür. Paralel subagent'ların otomatik paket kurmasına veya ayar değiştirmesine izin verirseniz, N Worker açmak kötü amaçlı paket sokabilecek N giriş noktası daha demektir.
Bu yüzden katmanlı orkestrasyona (Hierarchical Orchestration) geçtim: Her katman yalnızca iyi olduğu işi yapar, Haiku'nun paralel çalışma gücü de yalnızca gerçekten gereken yerde kullanılır.
Önce sonucu söyleyeyim: Fable düşünüp netleştirir, Opus dağıtır ve kabul eder, Sonnet ana uygulamayı yapar, Haiku yalnızca mekanik görevleri ve otomatik doğrulanabilen arama tipi görevleri yapar. Aday çözümler önce CI'dan geçer, sonra modele gösterilir.
Dört katmanlı mimari: karar, orkestrasyon, doğrulama, kabul#
Gereksinim girişi
│
▼
[Karar katmanı] Fable: mimari kararlar, görev bölme, kabul ölçütleri
│
▼
[Orkestrasyon katmanı] Opus Main Session: yalnızca dağıtır, yeniden bölmez
├─► Yol A: karmaşık ama sınırları net ──► Sonnet uygular
├─► Yol B: mekanik görev ──► tek bir Haiku
├─► Yol C: arama tipi, birden çok çözüm ──► birden çok Haiku, her biri ayrı bir Git Worktree'de
│
▼
[Doğrulama katmanı] Build, Type Check, Test, Benchmark (Yol C'de yalnızca ilk 2–3 kalır)
│
▼
[Kabul katmanı] Opus kabul ölçütlerine göre sonuçları toplar
Başarısızlıkta yükseltme: Haiku 2 düzeltmeden sonra hâlâ başarısızsa ➔ Sonnet ➔ Opus'a geri döner
Her modelin hangi katmana konacağı, resmî konumlandırmaya ve fiyata göre belirlendi. Aşağıdaki rakamlar Anthropic'in 8 Ekim 2026 tarihli resmî belgelerinden; fiyat birimi milyon token başına ABD dolarıdır:
| Model |
Resmî konumlandırma |
Gecikme |
Input / Output fiyatı |
| Claude Fable 5.1 |
Zor akıl yürütme ve uzun süreli agentic işler |
Daha yavaş |
$10 / $50 |
| Claude Opus 5.5 |
Uzun süreli agentic coding ve bilgi işi |
Orta |
$4 / $20 |
| Claude Sonnet 5.5 |
Hız ve yeteneğin en iyi birleşimi |
Hızlı |
$2 / $10 |
| Claude Haiku 5.5 |
Yüksek hacimli, düşük gecikmeli sınıflandırma, çıkarım, yönlendirme ve subagent görevleri |
En hızlı |
$0.10 / $0.50'den başlar |
Haiku 5.5'in fiyatı iki kademelidir: Prompt 100 bin token'ı aşınca $0.50 / $2.50 olur.
Karar katmanı: Fable mimari kararları ve kabul ölçütlerini üstlenir#
Her gereksinim için Fable gerekmez. En pahalı ve en yavaş katman olduğundan, onu yalnızca gereksinim belirsizse, sistemler arası entegrasyon söz konusuysa veya çekirdek mimari kararlar alınacaksa kullanıyorum.
Fable üç şey teslim etmeli:
- Çözüm tasarımı
- Görev bölme
- Her alt görev için testle doğrulanabilen kabul ölçütleri (Acceptance Criteria)
Akıl yürütme ile bölme aynı katmanda yapılmalı. Sistemin kör noktalarını netleştirebilen katman, sınırları temiz alt görevleri de kesebilir; mimariyi A'ya, bölmeyi B'ye verirseniz arayüz tanımları genellikle bulanıklaşır.
Güvenlik görevleri istisnadır. Bu nesil Claude modellerinin hepsinde güvenlik sınıflandırıcıları var; bir istek engellendiğinde stop_reason: "refusal" döner ve meşru güvenlik işleri de yanlışlıkla engellenebilir. Fable 5.1'in sınıflandırıcısı güvenlik içeriklerinin çoğunu kapsıyor, resmî açıklamaya göre de güvenlik alanı için tasarlanmamış; Opus 5.5 ise kaynak kodda açık aramaya izin veriyor. Bu yüzden güvenlik açığı düzeltme gibi gereksinimlerde ilk analizi doğrudan Opus'a veriyorum.
Orkestrasyon katmanı: Opus yalnızca dağıtır, yeniden bölmez#
Opus, Main Session'dır ve yönlendirme ile iş dağıtımından sorumludur. Bu katman mimariyi baştan devirmez, ikinci bir bölme de yapmaz.
- Yol A, karmaşık ama sınırları net: Mantığı karmaşık ama arayüz sınırları zaten netleşmiş görevler Sonnet'e verilir. Uygulamanın ana gücü odur.
- Yol B, sade mekanik görevler: Şablon kod (Boilerplate), değişken yeniden adlandırma, basit birim testi ekleme, belge ekleme gibi işler tek bir Haiku'ya verilir.
- Yol C, arama tipi ve optimizasyon görevleri: Performans ayarı, karmaşık SQL veya Regex'in farklı yazımları, Flaky Test ayıklama gibi işlerde Fan-out başlatılır: Birden çok Haiku, her biri bağımsız bir Git Worktree'de farklı çözümler dener.
Hangi yol izlenirse izlensin, çıktılar doğrulama katmanına girmelidir.
Doğrulama katmanı: önce makine, sonra model#
Çok yaygın bir uygulama, paralel üretilen kodun hepsini Opus'a veya Sonnet'e verip prompt ile incelemesini istemektir.
Sorun şu: Model kodu okurken düzenli biçimlendirilmiş, tip bildirimleri eksiksiz cevaplara kapılır; oysa bu, cevabın sınır testlerinden geçtiği anlamına gelmez. Bu yüzden aday çözümler önce makine eleğinden geçmeli:
- Build ve Type Check: Derlenmeli, tipler doğru olmalı
- Unit / Integration Tests: Birim ve entegrasyon testleri geçmeli
- Benchmark / Profiling: Performans ve bellek ölçülmeli
Otomatik testleri geçemeyenler doğrudan elenir. Yol C'nin adayları için Opus yalnızca kontrolleri geçen ve metrikleri en iyi olan ilk 2–3'e bakar; bu, context window'dan ve token'dan da tasarruf sağlar.
Kabul katmanı: Opus toplar, başarısızlıkta yukarı yükseltilir#
Son olarak Opus, sonuçları karar katmanında tanımlanan kabul ölçütlerine göre toplar. Worker takılırsa sırayla yukarı yükseltilir (Escalation Path):
- Haiku başarısız olursa, otomatik 2 düzeltmeden sonra hâlâ geçemiyorsa yeniden denemeyi bırakın.
- Düzeltmeyi Sonnet devralır.
- Sonnet de kabulü geçemezse, bu genellikle görev bölmesinde veya öncüllerde bir çelişki olduğu anlamına gelir. Görev Opus'a geri döner; Opus, yeniden bölmek üzere Fable'a gönderilip gönderilmeyeceğine karar verir.
Gerçek ortama koymadan önce üç kural#
Körü körüne Fan-out yapmayın#
Basit görevler birden çok Worker gerektirmez, belirsizliği yüksek görevleri de küçük modeller çözemez. Birden çok Haiku'yu paralel çalıştırmaya yalnızca "çözüm uzayı geniş" ve "otomatik testlerle hızlıca doğrulanabilen" arama tipi görevler değer.
Ortamı yalıtın, Lockfile'ı kilitleyin#
Git Worktree kod değişikliklerini yalıtır; paralel Worker'lar birbirinin dosyalarının üzerine yazmaz. Ağı da, programın erişebileceği kapsamı da kısıtlamaz. Supply Chain Attack'a karşı ayrıca bir sandbox gerekir; Worker'ların incelenmemiş paket kurması veya Lockfile'ı değiştirmesi yasaklanmalıdır. Kurulum yetkisini gelişigüzel açmak, Agent'ın kaynağı belirsiz paketleri ve betikleri kod deposuna sokmasına izin vermek demektir.
Kabulü model yorumuyla değil, ölçüm verisiyle yapın#
Test sonuçları, kapsam, bellek kullanımı ve gecikme, yeniden üretilebilir ve karşılaştırılabilir dayanaklardır. Modelin metin değerlendirmesi referans olabilir ama kod kalitesini kabul etmek için kullanılamaz.
Ucuz modeli doğru yerde kullanın#
Haiku 5.5 paralelliği ucuz hale getiriyor, ama paralellik tek başına sonucu doğru yapmaz. Karar, dağıtım, doğrulama ve kabulü birbirinden ayırdığınızda ucuzluk ve hız gerçek bir avantaja dönüşür.
Bu katmanlama aslında AI Agent aslında bir çevik ekiptir yazımda anlattığım Graph: Kim önce yapar, bitince kime devreder, sorun çıkınca kime aktarılır.