Kod Aracısı Orkestrası - Çoklu Aracılı Kodlamayı Gerçekten Çalıştırmanın Yolu

• Tek bir yapay zeka asistanıyla senkron döngüler içinde birlikte çalışılan yaklaşımdan, birden fazla ajanının kendi bağlam penceresi ve dosya kapsamıyla asenkron çalıştığı orkestratör modeline geçiş 2026 itibarıyla sürüyor
• Subagents, Agent Teams ve hiyerarşik delege etme olmak üzere 3 temel desen, çoklu ajanlı kodlamanın temel yapısını oluşturuyor; her biri paralellik, uzmanlaşma, yalıtım ve bileşik öğrenme etkileri sağlıyor
• Paylaşılan görev listesi ve eşler arası mesajlaşma, ajan ekiplerinin temel eşgüdüm mekanizması olarak bağımlılıkların otomatik çözülmesini ve darboğazların önlenmesini mümkün kılıyor
• 2026 itibarıyla araç ekosistemi süreç içi subagent'lar (Tier 1), yerel orkestratörler (Tier 2) ve bulut tabanlı asenkron ajanlar (Tier 3) olmak üzere üç katmana ayrılıyor; geliştiricilerin çoğu bu üç katmanın tamamını kullanım amacına göre birlikte kullanıyor
• Darboğaz artık kod üretiminde değil, doğrulama (Verification) aşamasına kaymış durumda; plan onayı, hook'lar, AGENTS.md üzerinden kurulan kalite kapıları ve insan incelemesi, çoklu ajan yapısının güvenilirliğini belirleyen temel unsurlar

---

Güncel geçiş: şeften orkestratöre

• 6 ay öncesine kadar geliştiricilerin çoğu tek bir yapay zeka asistanıyla senkron biçimde çalışıyordu ve tek bir bağlam penceresi işin üst sınırını belirliyordu
• Bugün en üretken geliştiriciler, her birinin kendi bağlam penceresi, dosya kapsamı ve sorumluluk alanı olan birden fazla ajanı asenkron biçimde koordine eden bir yaklaşıma geçmiş durumda
• Conductor modeli: tek bir ajanı gerçek zamanlı ve senkron biçimde yönlendirme; Claude Code CLI ve Cursor editöründeki ajan modu bunun tipik araçları
• Orchestrator modeli: kendi bağlam penceresine sahip birden fazla ajanı asenkron biçimde koordine etme; Agent Teams, Conductor, Codex ve Copilot Coding Agent bunun tipik araçları
• Orkestratör rolünde artık net spesifikasyon yazma, işi parçalara ayırma ve çıktıları doğrulama gibi yeni beceriler gerekiyor

AI destekli kodlamanın 8 aşaması

• [Orkestrasyon]
  • L8 — Kendi orkestratörünü kurma: ajan oluşturma, yönlendirme ve yönetimi için gereken koordinasyon katmanını doğrudan kodla kendin kurmak
  • L7 — 10'dan fazla ajan, manuel yönetim: "Eyvah, işler karıştı." Yanlış bağlam yanlış ajana gidiyor ve "Claude Code, Claude Code'u çalıştırırsa ne olur?" sorusu ortaya çıkıyor
  • L6 — Ajan çoklama: beklemek sıkıcı geldiği için birer birer daha fazla ajan çalıştırmak, birden çok akış arasında gidip gelirken duramaz hale gelmek
• [Önce ajan]
  • L5 — Önce ajan, IDE sonra: ana çalışma alanı ajanla yapılan konuşma, IDE ise kodu kontrol etmek için kullanılıyor
  • L4 — diff kayboluyor, konuşma öne çıkıyor: artık her diff'i tek tek incelemek yerine ajanın davranışını gözlemleyip yön vermeye odaklanmak
• [IDE çağı]
  • L3 — YOLO modu: ajanın IDE içinde serbestçe çalışması, güvenin artması
  • L2 — IDE içinde ajan, izinler manuel onaylı: tüm dosya değişikliklerini tek tek onaylamak, tamamen manuel kontrol
  • L1 — AI yok: geleneksel geliştirme iş akışı
• Steve Yegge'nin derlediği yapay zeka araç kullanımının 8 aşamalı çerçevesine göre, geliştiricilerin çoğu seviye 3–4'te kalıyor
• Orkestrasyon katmanı seviye 6'da başlıyor ve seviye 5'e kadar gelişen becerilerden temelden farklı bir yetkinlik seti gerektiriyor
• Bu içerik seviye 5–8'i ele alıyor

Tek ajanlı yaklaşımın sınırları

• Bağlam aşırı yüklenmesi: tek bir ajanın taşıyabileceği bilgi miktarı sınırlı ve büyük kod tabanları tek bir bağlam penceresini aşıyor
• Uzmanlaşma eksikliği: veri katmanı, API, UI ve testi aynı anda ele alan bir ajan en fazla genelci olabilir; yalnızca veri katmanına odaklanan bir ajan çok daha iyi veritabanı kodu yazar
• Eşgüdüm eksikliği: yardımcı ajanlar eklense bile birbirleriyle iletişim kurmaları, görev paylaşmaları veya bağımlılık çözmeleri mümkün değil; eşgüdüm primitifleri olmadan ajan sayısı arttıkça yönetim zorluğu da artıyor
• İlk iki sorunu subagent'lar, üç sorunun tamamını ise Agent Teams çözüyor

Neden çoklu ajan?

• Paralellik (3 kat throughput): frontend, backend ve test ajanları aynı anda çalışır
• Uzmanlaşma (odaklı bağlam): her ajan yalnızca sorumlu olduğu dosyaları bilir; yalnızca db.js dosyasını bilen bir ajan, tüm kod tabanını ele alan bir ajandan daha iyi DB kodu yazar
• Yalıtım (güvenli yürütme): Git worktree, her ajana bağımsız bir çalışma dizini sağlar; merge çakışması yaşanmaz
• Bileşik öğrenme: AGENTS.md dosyaları oturumlar arasında desenleri ve dikkat edilmesi gereken noktaları biriktirir; böylece her oturum bir sonrakini iyileştirir
• Odaklanmış 3 ajan, 3 kat daha uzun süre çalışan 1 genelci ajandan istikrarlı biçimde daha iyi sonuç verir

Desen 1: Subagent'lar — odaklı delege etme

• Task aracı kullanılarak üst orkestratörden uzmanlaşmış alt ajanlar oluşturulur; bu, önce denenmesi gereken en basit çoklu ajan desenidir
• Somut örnek: Claude Code'a "Express ve SQLite ile Link Shelf adlı bir yer imi yöneticisi oluştur" komutu verildiğinde, üst orkestratör bunu üç subagent brifine ayırır
  • Veri katmanı subagent'ı: db.js dosyasını kurar, ardından DATA.md raporunu yazar
  • İş mantığı subagent'ı: validation.js dosyasını kurar, ardından LOGIC.md raporunu yazar
  • API route subagent'ı: DATA.md ve LOGIC.md dosyalarını okuduktan sonra server.js dosyasını kurar
• İlk iki subagent birbirinden bağımsız olarak paralel çalışır, üçüncüsü ise iki rapor tamamlandıktan sonra başlar; üst ajan bağımlılık grafiğini manuel yönetir
• Subagent yaklaşımının sınırları: üst ajanın bağımlılık grafiğini manuel yönetmesi gerekir; ajanlar arasında eşler arası mesajlaşma veya paylaşılan görev listesi yoktur; dosya kapsamı gevşek yönetilirse çakışmalar çıkabilir
• Toplam yaklaşık 220 bin token ile maliyet açısından nötr seviyededir

• Hiyerarşik subagent'lar (takımların takımı)

  • Orkestratörün doğrudan 6 subagent oluşturması yerine, 2 feature lead oluşturulur ve her feature lead kendi içinde 2–3 uzman oluşturur
  • Üst orkestratör yalnızca iki ajanı yönetir, böylece bağlam temiz kalır; feature lead A, "arama özelliğini oluştur" brifini alır ve bunu kendi içinde parçalar
  • Mantık, gerçek mühendislik organizasyonlarının işleyişiyle aynıdır: VP görevleri tek tek mühendislere vermez, bunları tech lead'ler üzerinden iletir

Desen 2: Aracı ekipleri — gerçek paralel yürütme

• Claude Code'un deneysel bir özelliği; export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 komutuyla etkinleştirilir
• 3 katmanlı mimari:
  • Ekip lideri (Team Lead): işi parçalara ayırma, görev listesi oluşturma, sonuçları birleştirme
  • Paylaşılan görev listesi: durum takibi (pending, in_progress, completed, blocked) · bağımlılık takibi · dosya kilitleme
  • Ekip üyeleri (Teammates): her biri bağımsız bir Claude Code örneği, kendi bağlam penceresine sahip, tmux bölünmüş panellerinde çalışır
• Ekip üyeleri paylaşılan listeden görevleri özerk biçimde seçer ve eşler arası mesajlaşma ile doğrudan iletişim kurar; lider üzerinden geçmez
• Bir ekip üyesi görevi tamamlayıp tamamlandı olarak işaretlediğinde, buna bağımlı olan engellenmiş görevlerin kilidi otomatik olarak açılır
• Ctrl+T ile görev listesinin görsel kaplaması açılıp kapatılabilir

• Aracı ekiplerinin temel mekanizmaları

  • Paylaşılan görev listesi: backend ekip üyesi arama API'sini tamamlandı olarak işaretlediğinde, engellenmiş test yazma görevi otomatik olarak pending durumuna geçer; dosya kilitleme eşzamanlı düzenlemeyi önler
  • Eşler arası mesajlaşma: backend aracısı, API sözleşmesini frontend aracısına doğrudan iletir — "GET /search?q= returns [{id,title,url}]"; liderin koordinasyon darboğazına dönüşmesini önler
  • Bir ekip üyesi boşta kaldığında lidere otomatik bildirim gider

• Aracı ekipleri için temel öneriler

  • 3 ila 5 ekip üyesi en uygun noktadır; token maliyeti ekip boyutuyla doğrusal olarak artar
  • Plan onayı: ekip üyesi uygulamaya geçmeden önce bir plan yazar, lider bunu inceler ve onaylar ya da reddeder; mimari sorunları kod ortaya çıkmadan fark etmek çok daha ucuzdur
  • Odaklanmış 3 ekip üyesi, dikkati dağınık 5 ekip üyesinden sürekli olarak daha iyi performans gösterir

• Aracı ekipleri için güvenilirlik ipuçları

  • Döngü korkulukları + düşünme adımı: tüm ekip üyeleri için MAX_ITERATIONS=8 üst sınırı belirleyin; her yeniden deneme öncesinde "Ne başarısız oldu? Hangi somut değişiklik düzeltme getirebilir? Aynı yaklaşımı tekrarlıyor muyum?" düşünme istemini zorunlu kılın → kilitlenmiş aracıların görülme sıklığını büyük ölçüde azaltır
  • Ayrılmış @reviewer ekip üyesi: Claude Opus 4.6'yı (salt okunur) reviewer olarak atayın, yalnızca lint · test · güvenlik taraması araçlarını kullansın, her TaskCompleted olayında otomatik tetiklensin; her 3 ila 4 geliştirici için 1 reviewer oranı; lider her zaman yalnızca gözden geçirilmiş kod alır

Desen 3: Ölçekte orkestrasyon

• 5, 10, 20 veya daha fazla aracıyı birden çok repo ve özellik üzerinde yönetirken özel orkestrasyon araçları gerekir
• Tier 1 — süreç içi alt aracılar · ekipler: Claude Code alt aracılar · aracı ekipleri; tek terminal oturumu, ek araç gerekmez; başlangıç noktası burasıdır
• Tier 2 — yerel orkestratör: bağımsız worktree'lerde birden çok aracı çalıştırır, dashboard · diff inceleme · birleştirme denetimini korur; bilinen kod tabanlarında 3 ila 10 aracı için idealdir; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
• Tier 3 — bulut tabanlı asenkron aracılar: görevleri atayıp dizüstü bilgisayarı kapatır, sonra PR beklersiniz; bulut VM'lerde çalışır; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
• 2026'da geliştiricilerin çoğu üç katmanın tamamını kullanacak: Tier 1 (etkileşimli işler), Tier 2 (paralel sprintler), Tier 3 (gecelik backlog işleme)

Araç odağı

• Conductor by Melty Labs

  • Mac'te çoklu aracı orkestrasyonuna başlamanın en hızlı yolu; her biri bağımsız git worktree içinde birden çok Claude Code · Codex aracısını paralel çalıştırır
  • Görsel dashboard ve diff öncelikli inceleme arayüzü sunar; yalnızca API maliyeti vardır (ücretsiz); yalnızca macOS'te çalışır (Apple Silicon · Intel)
  • Aynı repoda 3 ila 8 özelliği paralel yürütüp görsel gözetim gerektiğinde idealdir

• Claude Code Web

  • claude.ai/code adresinden erişilir; tamamen tarayıcı tabanlıdır, terminal gerekmez; GitHub reposunu bağlayıp görev açıklaması girersiniz → Anthropic tarafından yönetilen bulut VM'de çalışır
  • Ara yönlendirme, otomatik PR oluşturma ve iOS uygulaması üzerinden erişim desteklenir
  • Ekipler (terminal), aracıyla birlikte çalışmak içindir; Web (tarayıcı), işi devredip başından ayrılmak içindir

• GitHub Copilot Coding Agent

  • IDE içindeki Copilot agent mode'dan (senkron · etkileşimli) farklıdır; GitHub'daki Copilot Coding Agent tamamen asenkrondur
  • Her GitHub issue'sunu @copilot'a atayabilir veya Agents panelinden başlatabilirsiniz → GitHub Actions ortamında taslak PR oluşturur
  • Etiketlemeden önce kendi inceleme döngüsünü çalıştırır; Claude Code · Codex gibi üçüncü taraf aracılara da aynı panelden erişilebilir; Slack, Jira, Linear, Azure Boards üzerinden tetiklenebilir

• Jules by Google

  • Google'ın Gemini tabanlı asenkron bulut kodlama aracısı; GitHub reposunu bağla → görev açıklamasını gir → Jules planı oluştursun → onaydan sonra bulut VM'de çalışsın → tüm akıl yürütme süreci ve terminal günlüklerini içeren bir PR döndürsün
  • Sesli değişiklik günlüğü, ara görevleri durdurma ve GitHub issue'larını doğrudan aktarmaya yarayan Jules Tools CLI sunar
  • Reponun AGENTS.md dosyasını ek yapılandırma olmadan otomatik olarak okur

• OpenAI Codex Web

  • Her görev, GitHub reposu önceden yüklenmiş bağımsız bir sandbox container içinde çalışır
  • Web, CLI (açık kaynak), macOS uygulaması, IDE uzantısı ve GitHub entegrasyonunu ChatGPT hesabına bağlayan bir yüzey ekosistemine sahiptir
  • Doğrulanabilir Kanıt (Verifiable Evidence) özelliği: her görev için terminal günlükleri ve test çıktılarından alıntılar döndürerek çalışma geçmişinin denetlenmesini sağlar

• Cursor Cloud Agents + Glass

  • Aracılar web, masaüstü uygulaması, Slack, Linear, GitHub, API, PWA (cursor.com/agents kurulumu) üzerinden başlatılabilir
  • Glass: Cursor'ın yeni arayüzü; aracı yönetimini ana ekran haline getirir, mevcut editörü ise gerektiğinde erişilen yardımcı bir araca dönüştürür
  • Tüm ekosistemde kontrol düzleminin ana deneyim haline geldiği ve editörün bunun altında tek bir enstrüman olduğu deseni yansıtır

• Vibe Kanban

  • "doomscrolling gap" sorununu çözer; yani aracı çalışırken ortaya çıkan 2 ila 5 dakikalık boşluk; görev kartı oluşturup "In Progress" sütununa sürüklediğinizde her biri için kendi worktree'si · branch'i oluşturulur
  • Board içinde diff incelemesi yapılabilir ve çalışan aracılara geri bildirim gönderilebilir; Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI ve daha fazlasını destekler; çapraz platformdur (Mac, Windows, Linux), ücretsizdir, BYOK

Ölçeği büyütmeye yönelik ipuçları

• Çoklu model yönlendirmesi

  • Her görev için en pahalı modele gerek yok; rol bazlı yönlendirme için MODEL_ROUTING.md dosyası oluşturun:
    • Planlama·mimari → daha ucuz Gemini/Claude/OpenAI modelleri
    • Uygulama → Sonnet, Opus veya Codex
    • İnceleme → özel güvenlik modelleri

• Worktree yaşam döngüsü betikleri

  • Tekrarlanan işleri üç shell alias ile otomatikleştirin:
    • agent-spin <feature>: worktree + branch oluştur + aracıyı başlat
    • agent-merge <feature>: rebase + inceleme + PR oluştur
    • agent-clean: tamamlanmış worktree'leri kaldır
  • Yaklaşık 12 satır bash; Conductor bunu görsel olarak yönetir

• Yalnızca insanlar tarafından yazılmış AGENTS.md'ye izin verin

  • ETH Zurich Gloaguen ve diğerlerinin araştırması, LLM tarafından üretilen AGENTS.md dosyalarının fayda sağlamadığını; ortalamada başarı oranını yaklaşık %3 düşürdüğünü ve çıkarım maliyetini %20'den fazla artırdığını gösteriyor
  • Geliştirici tarafından yazılmış bağlam dosyaları yaklaşık %4 performans artışı sağlar
  • Aracıların doğrudan AGENTS.md içine yazmasına asla izin vermeyin; ekip lideri her satırı onaylamalıdır
  • Bunu net bölümlerle kısa tutun: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY

Kalite kapıları: güven ama doğrula

• Üç kalite kapısı

  • Plan onayı: Ekip üyesi kodlamaya başlamadan önce plan yazar → lider inceler, onaylar veya reddeder → uygulama; kötü bir planı düzeltmenin maliyeti, kötü bir kodu düzeltmekten çok daha düşüktür
  • Hook'lar: yaşam döngüsü olayları için otomatik kontroller; TeammateIdle hook'u, aracı işi bırakmadan önce tüm testlerin geçtiğini doğrular; TaskCompleted hook'u, tamamlandı olarak işaretlemeden önce lint ve testleri çalıştırır; hook başarısız olursa aracı geçene kadar çalışmayı sürdürür
  • AGENTS.md üzerinden bileşik öğrenme: keşfedilen kalıpları, uyarıları ve stil tercihlerini yakalar; tüm aracılar bunu oturum başında okur ve her oturumda buna ekleme yapılır

• Darboğaz doğrulamaya kayıyor

  • Aracılar etkileyici çıktıları şaşırtıcı hızlarda üretebilir; zor olan, bu çıktının doğru olduğundan emin olmaktır
  • Değişiklikten önce geçen testler, değişikliğin yol açtığı regresyonları yakalayacaklarını garanti etmez
  • Aracılar teknik olarak geçerli ama önemli durumları kaçıran testler yazabilir
  • Bağlam penceresi sınırları nedeniyle, büyük codebase'lerde çalışan aracılar mevcut görünümün dışındaki kritik kısıtları kaçırabilir
  • Tek bir geliştirici için can sıkıcı bir edge case olan kararsız bir ortam, aynı kararsız testle aynı anda karşılaşan 40 aracı olduğunda sistemik bir engelleyiciye dönüşür
  • Doğrulama altyapısı üretim kapasitesine yetişene kadar insan incelemesi isteğe bağlı ek maliyet değil, bir güvenlik sistemidir

Ralph Loop ve kendini geliştiren aracılar

• Ralph Loop kalıbı

  • Geoffrey Huntley ve Ryan Carson tarafından yaygınlaştırıldı; “uyurken teslimat” yaklaşımının arkasındaki kalıp; Carson'ın bağımsız aracı ralph (snarktank/ralph) çekirdek döngüyü uygular, Antfarm projesi ise OpenClaw üzerinde çoklu aracı orkestrasyonu ekler
  • 5 adımlı döngü: Pick (tasks.json içinden bir sonraki görevi seç) → Implement (değişiklikleri yap) → Validate (test·type·lint çalıştır) → Commit (kontroller geçerse commit at ve görev durumunu güncelle) → Reset (aracı bağlamını sıfırla, sonra sonraki göreve geç)
  • Temel içgörü: her yinelemede sıfırlama yaparak kafa karışıklığının birikmesini önlemek; küçük ve kapsamı net görevler, tek bir devasa prompt'a göre daha az halüsinasyon ve daha temiz kod üretir
  • Güvenlik önlemleri: otomatik yeniden deneme için hataları geri bildirim olarak verin, ancak 3'ten fazla kilitlenmede durdurup yeniden atayın; her zaman feature branch üzerinde çalışın; yineleme, süre ve token üst sınırları belirleyin; aracı PR oluşturur → merge öncesi insan incelemesi
  • Bağlam sıfırlamaları arasında 4 bellek kanalı korunur: git commit geçmişi, ilerleme günlüğü, görev durum dosyası (tasks.json), uzun vadeli anlamsal bellek olarak AGENTS.md

• Aracıları zamanla daha akıllı hale getirmek

  • REFLECTION.md ile öz değerlendirme: her görevden sonra “şaşırtıcı olan neydi, AGENTS.md'ye eklenecek bir kalıp, bir prompt iyileştirmesi” yazmayı zorunlu kılın; lider gözden geçirir ve onaylanan öğrenimleri birleştirir
  • Token bütçeleri ve sonlandırma ölçütleri: aracı başına üst sınır belirleyin (ör. frontend 180 bin token, backend 280 bin token); bütçenin %85'inde otomatik duraklatın ve lideri bilgilendirin; aynı hatada 3'ten fazla kilitlenirse sonlandırın ve yeni bir aracıya yeniden atayın
  • Beads / kalıcı bellek: Gastown'un “beads” kalıbı — her kararın ve sonucun tam kökeniyle birlikte değiştirilemez, git tabanlı kaydı; aracılar geçmiş beads'leri görev grafiği ve SQL ile adreslenebilir veri düzlemi üzerinden sorgular; basit vektör tabanlı RAG değil, yapılandırılmış ve sorgulanabilir kurumsal bellek

Tüm bunları çalıştıran disiplin

• İnsani darboğaz bir hata değil, bir özellikti

  • Kod insanlar hızında yazılırken acı erken hissedilir; test başarısızlıkları, code review yorumları, tekrarların fark edilmesi — acı anlıktır, bu yüzden ilerlerken düzeltilir
  • Orkestre edilen aracı ordularında doğal bir darboğaz yoktur; küçük hatalar (code smell, tekrarlar, gereksiz soyutlamalar) yetişilemeyecek bir hızla bileşik biçimde büyür
  • Döngünün dışına çıktığınız için, mimari yeni özelliklere izin vermeyecek hale gelene kadar acıyı hissetmezsiniz
  • Tüm kalite kapılarının (plan onayı, hook'lar, token bütçeleri, insan incelemesi) var olma nedeni budur: bunlar olmadan, aracı destekli kodlama sizi kendi kendinize çıkmaz sokağa sokar

• Görevleri devredin ama muhakemeyi elinizde tutun

  • Aracılara bırakılması gerekenler: net geçer/kalır ölçütleri olan kapsamı belirli görevler, boilerplate, migration'lar, test iskeleti, doğrudan denemeye vaktiniz olmayan yaklaşımların keşfi
  • Sizde kalması gerekenler: mimari ve API tasarımı (aracılar eğitim verilerinde çok sayıda kötü mimari öğrenmiştir ve enterprise kalıplarını startup'lara aynen uygulayabilir), neyin yapılmayacağına karar vermek (Hayır demek, aracılarda olmayan bir özelliktir), tüm sistem bağlamıyla aracı çıktısını incelemek
  • Kendi sisteminizi anlama yetinizi kaybederseniz, onu düzeltme, genişletme ve arızaları tespit etme yetinizi de kaybedersiniz

• Spesifikasyon kaldıraçtır

  • 50 aracıyı paralel biçimde orkestre ederken, muğlak düşünce yalnızca hızı düşürmez; düzinelerce paralel çalışmanın tamamına yayılıp büyür
  • Sıradan çıktı ile olağanüstü çıktı arasındaki fark neredeyse tamamen spesifikasyonun kalitesine bağlıdır
  • Muğlak spesifikasyonlar hataları tüm filoya yayar; net mimari, entegrasyon sınırları, edge case'ler ve değişmezler içeren kesin spesifikasyonlar ise sistemi baştan sona hassas uygulamaya dönüştürür
  • Kodu yazmanın mekanik işi otomatikleşiyor; sistemi anlamanın bilişsel işi ise özerk çalışanlardan oluşan tüm filoya çarpan etkisiyle yayılıyor

Fabrika modeli

• Artık sadece kod yazmaktan değil, yazılım üreten bir fabrika kurmaktan söz ediyoruz
• 6 adımlı üretim hattı: Plan (kabul kriterleri olan spesifikasyon yaz) → Spawn (ekip oluştur ve aracıları ata) → Monitor (her 5–10 dakikada ilerlemeyi kontrol et ve engelleri kaldır, başlarında bekleme) → Verify (testleri çalıştır ve code review yap; doğrulama darboğazdır) → Integrate (branch'leri birleştir ve çakışmaları çöz) → Retro (AGENTS.md'yi yeni kalıplarla güncelle; bileşik öğrenme)
• Pratik ipuçları:
  • WIP limiti koyun: anlamlı biçimde inceleyebileceğinizden fazla aracı çalıştırmayın; ideal nokta 3–5'tir
  • Sonlandırma ölçütlerini tanımlayın: aynı hatada 3'ten fazla kilitlenirse durdurun ve yeniden atayın
  • Eşzamansız check-in'ler: her 5–10 dakikada ilerlemeyi kontrol edin; aracıların özerk çalışmasına izin verin
  • Bir dosya, bir sahip: iki aracının aynı dosyayı düzenlemesine izin vermeyin; çakışmalar hızı öldürür

Bugün başlayabileceğiniz 5 kalıp

1. Alt aracılara ayırma: Task aracıyla, belirli bir brief ve dosya sahipliği olan odaklı alt aracılar oluşturun; kurulum gerekmez; bugün başlayın
2. Aracı ekibiyle paralellik: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 etkinleştirin; 1 lider + 3 ekip üyesi oluşturun; paylaşılan görev listesiyle koordinasyon sağlayın
3. Git worktree ile izolasyon: Her aracıya kendi worktree’sini verin; birleştirme çakışması olmaz; Conductor bunu otomatik halleder
4. Güven için kalite kapıları: Riskli değişikliklerde plan onayı isteyin; görev tamamlandığında test çalıştıran hook’lar ekleyin; doğrulama olmadan aracı çıktısına güvenmeyin
5. AGENTS.md ile bileşik öğrenme: Kalıpları, dikkat edilmesi gereken noktaları ve stil tercihlerini belgelendirin; her oturum bunları okuyup güncellesin; bilgi bileşik şekilde güçlenir

[kurthong]

Mühendislerin bir özelliği mi bilmiyorum ama neden kulağa hoş gelen şeyleri bu kadar yüzeysel biçimde uzun uzun anlatıyorlar, anlamıyorum. Ben de ilgilendiğim bir konu olduğu için dikkatlice okudum ama ortada bir içerik yok.

[stroke33]

Haak Cline Code'u kullanmanın nihai nedeni: çoklu ajanla kendi orkestrasyonumu kurmak

Şu anda 5 ajan çalıştırıyorum ama tokenlar inanılmaz hızlı tükeniyor, ağlayacağım.