İlk AI Agent Takımınızı Nasıl Kurarsınız? Adım Adım Rehber
İlk AI Agent Takımınızı Nasıl Kurarsınız? Adım Adım Rehber
Giriş: Neden AI Agent Takımı?
Tek bir AI agent kullanmak artık yeterli değil — bunu muhtemelen siz de hissediyorsunuz.
Bir agent ile bireysel üretkenliğinizi artırabilirsiniz. Ama gerçek projelerde işler paralel yürütülmeli: biri frontend yazarken başkası backend'i kurmalı, bir diğeri test yazarken bir diğeri dokümantasyon hazırlayabilmeli. Bunun için ekibe ihtiyacınız var.
AI agent takımları, bu kapasiteyi sağlayan yapıdır. Önceki yazımızda AI agent takımlarının ne olduğunu anlattık. Bu yazıda ise somut adımlarla sizin ilk takımınızı nasıl kuracağınızı gösteriyoruz.
Teoriden çok pratik. Başlayın.
Adım 1: Takım Mimarisini Tasarlayın
Her takım bir hiyerarşiyle başlar. Bu hiyerarşi netleştirilmeden hiçbir şey doğru çalışmıyor.
Üç Katman
Patron (Siz): Stratejik yönlendirme yapan insan. Kim ne yapacak? Öncelikler ne? Kabul kriterleri neler? Bu soruların cevapları Patron'dan gelir. Tamamen otonom bir AI takımı henüz mümkün değil — insan liderliğinin yeri burada.
Team Lead Agent: Operasyonel koordinasyonu yürüten AI. Patron'dan gelen yönlendirmeleri worker agent'lara görev olarak dağıtır. Her agent'ın ilerleyişini takip eder, çıktıları review eder, merge işlemlerini yönetir, Patron'a düzenli rapor verir.
Worker Agent'ler: Kendine atanan görevi bağımsızca yürütür. Kendi scope'u dışına çıkmaz, diğer worker'larla doğrudan iletişim kurmaz.
Patron (İnsan)
|
+-- Team Lead Agent (AI)
|
+-- Worker Agent 1 [Frontend]
+-- Worker Agent 2 [Backend]
+-- Worker Agent 3 [Test]
+-- Worker Agent 4 [Dokümantasyon]
Takım Büyüklüğü
Küçük başlayın. İlk denemeniz için 2-3 worker agent idealdir. Koordinasyon mekanizmasını öğrenmek, 10 agent'le başlamaktan çok daha sağlıklı bir ilk adımdır.
Rolleri netleştirin. "Frontend developer" yeterince spesifik değil. "Homepage ve ürün sayfalarını geliştiren, components/ ve pages/ dizinlerine yazabilen, api/ dizinine dokunmayan frontend developer" — bu bir rol tanımı.
Adım 2: İzolasyonu Kurun (Worktree Yapısı)
En kritik teknik adım bu. İzolasyon olmadan paralel çalışma güvenli değildir.
Git Worktree Nedir?
Git worktree, aynı repository'yi farklı dizinlerde, farklı branch'lerde aynı anda açık tutmanızı sağlar. Her agent kendi dizininde, kendi branch'inde çalışır. Birbirlerinin dosyalarını göremez, değiştiremez.
Kurulum
# Ana repository'den her agent için worktree oluştur
git worktree add ../proje-agent-1 -b feature/agent-1/gorevi
git worktree add ../proje-agent-2 -b feature/agent-2/gorevi
git worktree add ../proje-agent-3 -b feature/agent-3/gorevi
Her agent artık kendi dizininde (../proje-agent-1, ../proje-agent-2 vb.) çalışıyor. Branch'ler birbirinden tamamen ayrı.
Branch Konvansiyonu
Tutarlı bir isimlendirme conflict'leri önler ve kim ne yapıyor sorusunu anında cevaplar:
feature/{agent-id}/{gorev-kodu}-{kisa-aciklama}
Ornekler:
feature/agent-1/AUTH-001-login-page
feature/agent-2/DASH-001-analytics-widget
feature/agent-3/API-001-user-endpoints
Adım 3: Her Agent İçin Kimlik Tanımlayın (CLAUDE.md)
Her agent'ın kendi kimlik dosyası olmalı. Bu dosya olmadan agent davranışı tutarsız, scope dışı çıkma riski yüksek.
CLAUDE.md Nedir?
Her agent'ın çalıştığı dizine koyulan bir markdown dosyası. Agent çalışma başladığında bu dosyayı otomatik yükler. Kimlik kalıcı — her session'da yeniden anlatmanıza gerek kalmaz.
Temel Yapı
# Agent 2 — Backend Developer
## Kimlik
- Rol: Backend Developer
- Takım: [Proje Adı]
- Branch: feature/agent-2/...
## Çalışma Alanı
- `api/` dizini altındaki endpoint dosyaları
- `services/` altındaki iş mantığı dosyaları
## DOKUNMA (Scope Dışı)
- `components/` (frontend — Agent 1'in alanı)
- `pages/` (frontend — Agent 1'in alanı)
- `tests/` (test — Agent 3'ün alanı)
## Kurallar
- Push öncesi build zorunlu
- Her görev tamamlandığında commit + push + Team Lead'e rapor
- Scope dışı değişiklik tespitinde hemen bildir
## İletişim
Team Lead'e aşağıdaki formatta rapor ver:
- Yapılan: [ne tamamlandı]
- Commit: [hash]
- Sonraki: [ne gelecek]
- Blocker: [varsa ne]
En Önemli Kısım: "DOKUNMA" Listesi
Her agent'e "ne yapabilirsin" kadar "neye dokunamazsın" da net söylenmelidir. Bu liste scope dışı değişikliklerin önüne geçen en etkili mekanizmadır. Bir agent'ın başkasının dosyasına dokunması conflict'in kaynağı — CLAUDE.md'deki explicit yasak bunu neredeyse imkânsız kılar.
Adım 4: Görevleri Yapılandırılmış Briefing ile Atayın (Briefing Sistemi)
"Şu feature'i yaz" talimatı bir görev değil. Belirsizlik, tahmin edilemez çıktı demek.
Briefing Dosyası Yapısı
Her görev için bir briefing.md dosyası oluşturun:
# Briefing: [Görev Başlığı]
## Agent
Atanan: Agent 2 — Backend Developer
Branch: feature/agent-2/USER-API-001
## Görev Tanımı
Kullanıcı CRUD endpoint'lerini oluştur.
GET /users, POST /users, PUT /users/:id, DELETE /users/:id
## Scope
### Yapılacaklar
- [ ] 4 endpoint implementasyonu
- [ ] Input validation
- [ ] Error handling (400, 404, 500)
- [ ] API dokümantasyonu (JSDoc)
### YAPILMAYACAKLAR
- Frontend bağlaması (Agent 1'in görevi)
- Authentication middleware (Agent 4'ün görevi)
- Test yazımı (Agent 3'ün görevi)
## Teknik Gereksinimler
- Express.js route yapısı kullan
- Mevcut UserService'i import et (services/user.service.ts)
- Validation için Zod kullan
## Referans Dosyalar
- `services/user.service.ts` (mevcut servis)
- `api/auth.routes.ts` (örnek yapı)
## Kabul Kriterleri
1. Tüm 4 endpoint çalışır ve doğru status code döner
2. Build başarılı (npm run build)
3. Postman ile manuel test geçti
4. JSDoc yorumları eklendi
## Öncelik / Deadline
Öncelik: Yüksek | Beklenen süre: 1 gün
Neden Bu Kadar Detaylı?
Çünkü agent ne yapacağını değil, ne yapmayacağını da bilmeli. "YAPILMAYACAKLAR" listesi, scope kaymalarının %90'ını önler. Kabul kriterleri ise "tamamlandım" sözcüğünün ne anlama geldiğini netleştirir.
Adım 5: Kalite Kapıları Kurun
Paralel çalışan agent'lerin çıktısı kontrolsuz birleştirilirse kaos ortaya çıkar. Kalite kapıları bunu önler.
Zorunlu Üç Kural
Kural 1 — Push Öncesi Build Zorunlu
Her agent, kodu push etmeden önce local build almak zorunda. Build başarısız olan agent push yapamaz. Bu kural CLAUDE.md'ye eklenir.
## Kurallar
- Push öncesi `npm run build` çalıştır
- Build başarısızsa push YAPMA — önce düzelt
Bu tek kural, CI/CD'deki broken build oranını dramatik şekilde düşürür.
Kural 2 — Scope Kontrolü
Her merge öncesi Team Lead, diff'i scope ile karşılaştırır: agent kendi alanının dışında bir dosyaya dokunmuş mu? Dokunduysa, neden? Bu kontrol scope dışı değişiklikleri sıfıra indirir.
Kural 3 — Merge Checklist
Team Lead her merge öncesi şu listeyi uygular:
[ ] Build başarılı (local + CI/CD)
[ ] Scope dışı değişiklik yok
[ ] Commit mesajı anlaşılır
[ ] Kritik bağımlılıklar etkilenmedi
[ ] Patron bildirimi gerekiyor mu?
İlk etapta zahmetli görünür. Ama gün 3'te sizi kurtaran bu checklist olur.
Sonuç: İlk Haftadan Sonra Ne Beklemelisiniz?
AI agent takımı kurmak bir gecede tamamlanan bir iş değil. Ama ilerleme hızlıdır.
Gün 1: Beklenenin üzerinde sorun. Build hataları, scope dışı değişiklikler, eksik iletişim. Normal — sistemi gerçek sorunlarla öğreniyor.
Gün 2-3: Protokoller oturuyor. İletişim netleşiyor, conflict azalıyor, kalite yükseliyor.
Hafta 1 Sonu: Takım ritmi yerleşik. Agent'ler tahmin edilebilir çıktılar üretir, Team Lead koordinasyonu yönetir, siz stratejik kararlara odaklanırsınız.
Bir ay sonra: 3 agent'ten 6'ya geçiş, yeni proje için yeni takım kurulumu, template'lerle onboarding süreci günlerden saatlere indi.
Başlamak için mükemmel zaman beklemek yerine küçük bir takımla başlayıp öğrenmek — bu her zaman daha iyi bir strateji.
HiveTeams'in bu altyapıyı nasıl sağlayabileceğini öğrenmek için ürün sayfamıza bakın →
Ekibiniz için bir demo ayarlayalım →