Kişisel siteyi 6 ajanlı takım nasıl yönetir? Claude Code multi-agent vakası

Dün gece, 2026-05-25 akşamı, sitenin baseline SEO audit'ini çalıştırdım. Sonuç beklediğim gibi değildi: site genelinde 0 JSON-LD bloku çıktı. Kodda var sandığım yapısal veri canlıda yoktu. Bir Script afterInteractive hatası tüm BlogPosting + BreadcrumbList şemasını sessizce öldürmüştü. Lighthouse skoru yeşildi, Google'ın preview tool'u kırmızı. 31 saniye sonra 4 dosyalık fix prod'a alındı. Tek satır kod yazmadım. 6 ajanlı takım yazdı.

Bu siteyi (hayrettinsendil.tr) artık ben yönetmiyorum. Takım yönetiyor. Ben sadece brief açıyorum, onay veriyorum, yayını "go" diyorum. Bu yazı, o takımın nasıl kurulduğunu, neden tam 6 ajandan oluştuğunu ve ilk hafta içinde gerçek sayılarla ne yaptığını anlatıyor; replicate edilebilir bir kalıp olarak.

Sorun: tek-ajanın sınırları

Kişisel sitenin günlük yükü göründüğünden fazla. Kod bakımı (Next.js patch'leri, dependency drift, Vercel deploy state'i), blog yazımı, SEO denetimi (metadata, canonical, JSON-LD, sitemap). Marka tutarlılığı (renk, font, OG image), sosyal medya draft'ları, içerik takvimi, sertifika güncellemeleri. Hepsi farklı disiplin, hepsi aynı repo'da, hepsi aynı sahip.

"Claude, şunu yap" modunu denedim. Üç ayda üç sorun bütün berraklığıyla çıktı:

• Token israfı. Her görevde context window'a her şey yükleniyordu: renk paleti, MDX yapısı, Next.js sürüm notları, JSON-LD şeması, sosyal medya tone rehberi. Marka kararı verirken stack bilgisi gereksiz; aynı session'da kod refactor'ü yaparken brand.md gereksiz. Ölçtüğüm beş örnekte ortalama %40 ile %60 arası fazla token yakılıyordu. Bu, hem ücret hem hız maliyeti.
• Domain karmaşası. Hibrit görevlerde ("içerik yaz + OG image kontrol + SEO meta + sosyal post") ajan rolden role atlıyor, hiçbir rolde tam olamıyordu. İçerikçi gibi düşünmesi gerekirken frontend mühendisi gibi cevaplıyor, marka kararı verirken pazarlamacı kasmaya başlıyordu.
• Denetim açığı. Tek bakış açısı = kör nokta. Yazıyı yazan, SEO'sunu da kontrol ediyorsa, kendi körlüğünü göremiyor. JSON-LD vakası tam bu körlüğün bir örneği; yazan ve denetleyen aynı zihindi.

Aradığım üçlüydü: uzmanlık + koordinasyon + denetim.

Çözüm mimarisi: PO + 5 sub-agent

Cevap: bir orchestrator (Product Owner) ve onun yönettiği 5 dar-kapsamlı sub-agent. Her ajanın kendi referans dosyası var (50 ile 100 satır arası), kendi otonomi sınırı var, kendi MCP tool eşlemesi var. PO görevi parçalıyor, doğru ajana gönderiyor, sonuçları topluyor, sahibe rapor ediyor.

Mimari, daha önce çok daha büyük bir projede (Route34: PO + 12 sub-agent) denediğim r34-team v1.0 pattern'inden ilham aldı. Oradaki kalıp burada küçültüldü; kişisel site için 12 ajan aşırı, 6 ajan doğru ölçek.

Akış şu şekilde işliyor:

graph TD
    PO[hs-site-po · PO] --> WEB[WEB · Next.js]
    PO --> SEO[SEO · Metadata + JSON-LD]
    PO --> CON[CON · İçerik]
    PO --> BRD[BRD · Marka + OG]
    PO --> SOC[SOC · Draft-only]
    WEB --> Github[GitHub MCP]
    WEB --> Vercel[Vercel MCP]
    SEO --> Github
    CON --> Github
    CON --> Notion[Notion MCP]
    BRD --> Github
    SOC --> Notion

Bir brief tek ajana gitmiyor, PO'ya geliyor. PO da gerekirse paralel çağrı, gerekirse zincir oluşturuyor. Bu yazı için zincir şuydu: CON yazıyı çıkarır, SEO meta kontrol eder, BRD OG'yi onaylar (otomatik, NOP), WEB commit + deploy eder. JSON-LD bug fix vakasında zincir daha farklıydı: SEO baseline audit açtı, bulgu raporu PO'ya gitti, PO 4 dosyalık handoff briefi WEB'e geçirdi, WEB Script tag'i beforeInteractive'e çevirdi, commit + push, deploy başarılı. Toplam: 31 saniye. Karar momenti tek bir sahip yorumu kadar bile sürmedi.

Niye 6 ajan?

İlk gün dört seçenek vardı. ADR-001'de hepsini karşılaştırdım:

6 sayısı keyfi değil. Sitenin gerçek iş yüküne karşılık geliyor: kod (WEB), arama (SEO), yazı (CON), marka (BRD), sosyal (SOC) ve bunları yöneten bir karar mercii (PO). Bir tane daha eklesem (örneğin ANALYTICS) yapay olur; GA4 / GSC denetimini SEO zaten yapıyor, ayrı ajan sadece tablo şişirir. Bir tane çıkarsam (örneğin SOC), yayın sonrası sosyal görünürlük boş kalır; yazıyı ben üretemeyeceksem yayın da yapmamış olurum.

Sayı kadar önemlisi, ajanların birbirinden bağımsız ama PO üstünden zincirlenebilir olması. SEO, WEB'in commit'lediği koda metadata denetimi koyabiliyor; BRD, CON'un yayımladığı yazıya OG önizleme üretiyor. Hiçbiri "her şeyi yapan büyük bir asistan" değil; her biri kendi rolünden çıkmadan başkasına teslim ediyor. Ne çok ne az.

Bu denge şu an doğru. Site büyürse (örneğin paid workshop kataloğu, podcast veya yeni yayın kanalları eklenirse) yeni ajan eklenebilir; tablo bu büyümeye dayanıyor.

Karar anı: tam otonom + chat-driven

ADR-003'te en zor karar burası oldu: ajanlar PR mı açsın, yoksa direkt main'e push mu etsin?

PR teatrikal görünüyordu. Tek geliştiriciyim, gözden geçirecek bir ekip yok, "self-review" özel bir disiplin değil; PR açıp kendi PR'ını merge etmek sadece git tarihinde gürültü üretiyor. Vercel atomic deploy yapıyor; bozulursa rollback bir tık. Build kırılırsa zaten prod hiç güncellenmiyor, "bozuk versiyon canlıda" senaryosu Vercel mimarisinde mümkün değil. Bu risk profiliyle PR zorunluluğu ek değer üretmiyordu, sadece sürtünme.

Karar: tam otonom + chat-driven. Ajanlar main'e doğrudan push eder, Vercel deploy alır, hatalıysa rollback yapılır. Brief açık, sonuç açık, denetim raporu sahibe gelir.

Üç istisna var:

• Yeni blog yazısı published: false default; sahip yayına alır. Yazıyı yanlışlıkla canlıya alma olasılığı sıfır.
• Renk paleti değişikliği sahip onayı; brand.md tek otorite, ajan kendi başına token değiştiremez.
• Sosyal medya post draft-only; kişi bazlı kanallarda doğrudan yayın yok, çünkü ton bir kez bozulursa düzeltilmesi zor.

Yani otonomi mutlak değil, risk-tonlu. Düşük etki = tam otonom, yüksek etki = sahip onayı. Bu denge, "asistan" ile "ekip" arasındaki gerçek farkı tarif ediyor.

İlk hafta sonuçları

Sayılar lafı kapatır:

• 2026-05-25: Plugin v1.0.0 doğdu; 14 dosya, public repo, MIT lisans. Aynı gün 4 commit: SEO baseline (metadata + canonical düzeltmesi), dinamik OG image (per-post 1200×630), sitemap + robots, share buttons. Hiçbirini ben yazmadım. Brief açtım, ajanlar yaptı, ben review ettim.
• 2026-05-25 akşamı: Plugin'in ilk gerçek smoke testi; SEO baseline audit. Sonuç: 3 P0 bug.
  • /about ve /blog sayfalarının canonical URL'i home sayfasına bakıyordu. metadata.alternates.canonical her sayfada explicit set edilmemişti; Next.js default'u root'a düşürüyordu. Google bot için /about, anasayfanın duplicate'iydi.
  • Site genelinde 0 JSON-LD bloku. Script tag afterInteractive ile yükleniyordu, Google bot DOM render etmeden tarıyordu. Yapısal veri "var" sanılıyordu, gerçekte tarayıcı sonrası yükleniyordu. ADR-009 olarak belgelenip beforeInteractive'e çevrildi.
  • /blog listesi sayfasının og:image'ı broken; generic site OG'sine fallback alıyordu.
  • Bir handoff brief, 4 dosya, 31 saniyede prod. Üç P0 bir sprint'te değil, bir kahve molasında kapandı.
• 2026-05-26: Blog UX v2; TOC sidebar, reading progress bar, related posts, Giscus yorumlar, AuthorBio kartı. 9 dosya, 4 sub-agent paralel çalıştı (CON + BRD + WEB + SEO). Senkron koordinasyonu PO yaptı, çakışan dosya yok.
• Faz 2 Chain 2 (otomasyon): Her 6 saatte Vercel deploy state'i otonom kontrol ediliyor. ERROR durumunda Claude logu analiz ediyor, Notion'a incident kartı açıyor, sahibi notify ediyor. Şu ana kadar 3 kez tetiklendi, hepsinde root-cause doğru tespit edildi; birisinin uykuda olduğu vakitte.

Birinci günde plugin yazıldı; ikinci gün plugin gerçek bir denetim yaptı ve kendisi 4 dosyalık fix doğurdu. 72 saatte yapılmış işin yarısı, ben başka bir görevle ilgilenirken oldu.

Öğrenilen patternler

docs/patterns.md dokuz pattern içeriyor. Üçü vurgulamaya değer:

• Lazy reference loading. Her sub-agent kendi referans dosyasını gerektiğinde yüklüyor. PO sadece tablo görüyor, detay aşağı iniyor. Token tasarrufu ortalama %40 ile %60 arası. Eski tek-ajan modunda her sefer brand.md de stack.md de yükleniyordu; şimdi sadece görev sahibinin gerektirdiği dosya çağrılıyor. Bu pattern, plugin'in lifetime cost'unu doğrudan etkiledi.
• Auditless trust = bug. İlk günkü 0 JSON-LD vakası tam bu pattern'in örneği. Yazılım yazılmıştı, code review yapılmıştı, deploy başarılıydı, ama kimse "canlıda gerçekten gözüküyor mu" demedi. Multi-agent denetim, kör noktayı görmeyi mecbur kılıyor; çünkü denetleyen ajan, yazan ajandan farklı kapsamla bakıyor.
• Draft-only safety. Yüksek riskli eylemlerde ("yayın", "renk değişikliği", "sosyal post") ajan üretir, insan yayınlar. Bu kural otonomiyi azaltmaz; yanlış-yayın olasılığını azaltır. Bir yazıyı yanlışlıkla canlıya alma ihtimali sıfırlandı, sosyal medya postlarında ton kazası mümkün değil.

Görebileceğin yer

Plugin açık kaynak; repo public, MIT lisanslı: github.com/hsendil/hs-site-team. 14 dosya, 8 ADR, 9 pattern, TR/EN README. Fork edip kendi projene uyarlayabilirsin; sub-agent listesini sıfırdan da kurabilirsin, mevcudu da kullanabilirsin.

Bir başka not: plugin'i 3 saatte yarattım, ilk gerçek görevini 6 dakikada teslim etti. Setup'a yatırılan zaman, sonraki haftalarda misliyle geri dönüyor; özellikle birden fazla disiplin kesiştiğinde.

ADR'lerden ikisi özellikle okunmayı hak ediyor: ADR-009 (JSON-LD'nin neden beforeInteractive olması gerektiği) ve docs/patterns.md (dokuz operasyonel pattern).

Sonuç

Asıl soru: kendi iş akışını hangi 3 ajana bölerdin?

Bu siteyi okuyorsan, sen de aslında her gün bunu yapıyorsun. Kafanın içinde farklı modlara geçiyorsun (kodcu, içerikçi, marka, sosyal, ürün sahibi). Hepsi aynı beyin ama farklı bağlam. Onları açıkça ajanlaştırdığında üç şey birden geliyor: token tasarrufu (her ajan dar kapsam yükler), drift azalması (her ajan kendi rolünden çıkmaz) ve şeffaflık (kararlar ADR'ye düşer, pattern'ler dokümante olur).

Tek başına bir LLM penceresinde "her şeyi yapan zeki bir asistan" pazarlamasından çok farklı bir yer burası. Bu, ben dahil herkesin kullanabileceği bir mühendislik kalıbı.