Kişisel siteyi 7 ajanlı Claude Code takımı nasıl yönetir?

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 artı BreadcrumbList şemasını sessizce öldürmüştü. Lighthouse skoru yeşildi, Google'ın preview tool'u kırmızı. Aynı akşam 4 dosyalık düzeltme prod'a alındı. Tek satır kod yazmadım. Takım yazdı.

Bu siteyi (hayrettinsendil.tr) artık ben yönetmiyorum. Takım yönetiyor. Ben sadece brief açıyorum, onay veriyorum, yayına "go" diyorum. Bu yazı, o takımın nasıl kurulduğunu, neden bu ölçekte durduğunu ve ilk 48 saatte gerçek sayılarla ne yaptığını anlatıyor; replicate edilebilir bir kalıp olarak.

Güncelleme, 27 Temmuz 2026. Bu yazı yayımlandıktan sonra takıma 7. ajan eklendi ve JSON-LD vakasının teknik anlatımında bir hata bulundu: metin, ADR-009'da elenen seçeneği çözüm diye anlatıyordu. İkisi de düzeltildi. Hatayı bulan, yazının kendisinin savunduğu denetim mekanizmasıydı; aşağıda anlatıyorum.

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. Kaba tahminim, göreve göre %40 ile %60 arası fazla token yakıldığıydı; ölçülmüş bir sayı değil, ADR-002'de kayıtlı bir öngörü. Bu, hem ücret hem hız maliyeti.
• Domain karmaşası. Hibrit görevlerde ("içerik yaz artı OG image kontrol artı SEO meta artı 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 artı koordinasyon artı denetim.

Çözüm mimarisi: PO artı 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 r34-team v1.0: PO artı 12 sub-agent) denediğim kalıptan ilham aldı. Oradaki kalıp burada küçültüldü; kişisel site için 12 ajan aşırı, PO ve 5 uzman doğru ölçekti.

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]
    PO --> EDT[EDT · Editöryal denetim]
    WEB --> Github[GitHub MCP]
    WEB --> Vercel[Vercel MCP]
    SEO --> Github
    CON --> Github
    CON --> Notion[Notion MCP]
    EDT --> Notion
    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 (bu yazıda değişiklik gerekmedi), WEB commit artı 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 next/script'i kaldırıp JSON-LD'yi sunucuda render edilen düz <script> etiketine taşıdı, commit artı push, deploy başarılı. Karar momenti tek bir sahip yorumu kadar bile sürmedi.

Niye önce 6 ajan?

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

6 sayısı keyfi değildi. Sitenin gerçek iş yüküne karşılık geliyordu: kod (WEB), arama (SEO), yazı (CON), marka (BRD), sosyal (SOC) ve bunları yöneten bir karar mercii (PO). Bir tane daha eklesem yapay olurdu; GA4 ve GSC denetimini SEO zaten yapıyor, ayrı bir ANALYTICS ajanı sadece tablo şişirirdi. Bir tane çıkarsam, örneğin SOC, yayın sonrası sosyal görünürlük boş kalırdı; okunmayan yazı yayımlanmamış yazıya denk.

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.

7. ajan: EDT

Yukarıdaki altı ajan kadronun ilk hâliydi. Kısa sürede bir eksik ortaya çıktı: metni yazan ajan ile denetleyen ajan aynıydı.

CON bir yazı çıkarıyor, SEO meta'ya bakıyor, WEB commit ediyordu. Ama metnin kendisini, üslubunu, imlasını, önceki yazılarla tutarlılığını ayrı bir gözle okuyan yoktu. Bu, yukarıdaki "denetim açığı" maddesinin içerik tarafındaki karşılığı.

Çözüm 7. ajan oldu: EDT (Editor). İçerik üretmez, yalnız denetler. Em-dash yoğunluğu, 3. tekil şahıs sızıntısı, uzun cümle, madde-itis, Türkçe imla, terim tutarlılığı ve yazıdan yazıya üslup kayması. Çıktısı P0/P1/P2 önceliklendirilmiş bir bulgu tablosu ve CON için düzeltme brief'i. Kod commit yetkisi yok; öneri üretir, düzeltmeyi başka ajan yapar.

Zincir böylece şu hâle geldi: CON yazar, EDT denetler, CON revize eder, BRD görseli üretir, SEO meta'yı kontrol eder, WEB yayına alır.

Bu, aşağıda anlatacağım "auditless trust = bug" prensibinin içerik tarafındaki yapısal karşı önlemi. Kodda multi-agent denetim kör noktayı açıyordu; metinde de aynısı gerekiyormuş. Bu yazının başındaki güncelleme notu da EDT'nin ilk geçişinden çıktı.

Karar anı: tam otonom artı chat-driven

ADR-003'te en zor karar burada 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 artı 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.

Beş 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 postu draft-only; kişi bazlı kanallarda doğrudan yayın yok, çünkü ton bir kez bozulursa düzeltilmesi zor.
• Dependency major bump sahip onayı; minor ve patch otonom.
• env ve secret değişikliği sahip onayı; hassas veri repo'ya hiç girmiyor.

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 48 saatin sonuçları

Sayılar lafı kapatır:

• 2026-05-25: Plugin v1.0.0 doğdu; public repo, MIT lisans. Aynı gün 4 commit: SEO baseline (metadata artı canonical düzeltmesi), dinamik OG image (per-post 1200×630), sitemap artı 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 sınıfı bulgu.

  • /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 sunucuda render edilen düz <script> etiketine taşındı. beforeInteractive de değerlendirildi ve elendi: hâlâ JS bağımlı ve bot uyumluluğu garantilenemiyor.
  • /blog listesi sayfasının og:image'ı broken; generic site OG'sine fallback alıyordu.

  Bir handoff brief, 4 dosya, tek commit (29f0b29, artı 108 eksi 38 satır), 6/6 canlı doğrulama PASS. Vercel deploy READY: 31 saniye. Uçtan uca, audit'in açılmasından prod'a: altı dakika. Üç 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 artı BRD artı WEB artı SEO). Senkron koordinasyonu PO yaptı, çakışan dosya yok.

• Faz 2 Chain 2 (otomasyon): Her 6 saatte bir GitHub Actions cron'u Vercel deploy state'ini kontrol ediyor. ERROR durumunda Claude logu analiz ediyor, Notion'a incident kartı açıyor, beni notify ediyor. Bu satırları yazarken yeni devreye aldım; ilk gerçek tetiklenme sayılarını bir sonraki yazıda paylaşacağım.

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

Öğrenilen kalıplar

docs/patterns.md dokuz kalıp 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. Beklenen token tasarrufu %40 ile %60 arası; ADR-002'de tahmin olarak kayıtlı, henüz ölçmedim. 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.
• Auditless trust = bug. İlk günkü 0 JSON-LD vakası tam bu kalıbın ö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. Bu yazının kendisi de aynı kalıba yakalandı: metin ADR log'u yanında değil, hafızadan yazılmıştı ve iki ay boyunca yanlış teknik reçeteyi öğretti.
• 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.

Görebileceğin yer

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

Sitenin içerik repo'su (hsendil/hayrettinsendil) private kalıyor; yazı taslakları ve env değişkenleri orada. Açık olan, o içeriği yöneten takımın kendisi. Bu ayrımın gerekçesi ADR-007'de.

Bir başka not: plugin'i bir öğleden sonrada yarattım, ilk gerçek görevini aynı akşam 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: docs/architecture.md içindeki ADR-009 bölümü (JSON-LD'nin neden next/script yerine sunucuda render edilmesi gerektiği) ve docs/patterns.md (dokuz operasyonel kalıp).

Sonuç

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

Bu yazıyı okuyorsan, sen de aslında her gün bunu yapıyorsun. Kafanın içinde farklı modlara geçiyorsun (kodçu, 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, kalıplar 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ı.