Geliştirici, Claude Code oturumlarını spec ve review alışverişi yapan PM ve mühendis rollerine bölüyor

İki rollerli kurulum nasıl çalışıyor

Claude Code oturumları, Ağustos'tan bu yana 2.1.224 sürümüyle gelen cross-session messaging adlı özellik sayesinde birbiriyle iletişim kurabiliyor; bu bilgi bir dev.to paylaşımından. Bir oturum akranlarını ListAgents çağrısıyla buluyor ve onlara SendMessage üzerinden metin gönderiyor. Diğer oturuma yalnızca Claude'un onun için yazdığı metin iletiyor — asla konuşma geçmişi veya dosyalar değil.

Paylaşımın yazarı bunu rind-ui adlı headless bir UI bileşen kütüphanesine uyguladı; depodaki CLAUDE.md içinde tanımlı farklı görevleri iki oturuma atadı. Bir oturum PM rolünü oynuyor: her bileşeni bir spec olarak yazıyor — gereksinimler, senaryolar ve görevler içeren bir OpenSpec değişikliği — ve herhangi bir kod var olmadan önce o spec'i doğruluyor. Diğer oturum mühendisi oynuyor: tek bir spec'i uyguluyor ve işi tamamlandığında, dokunduğu her dosyayı listeyerek review istemek üzere PM'ye mesaj gönderiyor.

Oturumlardan hiçbiri diğerinin bağlamına sahip değil; her biri depoyu ve aldığı mesajları görüyor. Yazar bunu bir avantaj olarak görüyor: review yapan kişi uygulayıcının gerekçelerini hiç görmediği için koda soğuk yaklaşıyor; bu da gelecekteki bir bakımcının yaklaşımına daha yakın.

Döngünün sonlanmasını sağlayan kurallar

İş akışının ilk sürümü her değişiklik için üç review turuna izin veriyordu. Yazar bunu ikiye indirdi; çünkü sorun araması söylenen bir review sürekli sorunlar bulmaya devam eder, dolayısıyla döngünün açık bir bitiş noktasına ihtiyacı var.

Bulgular artık üç şiddet derecesinden birini taşıyor: critical (davranışı, veriyi, güvenliği veya erişilebilirliği bozar), error (bir spec gereksinimini ihlal eder ya da gerçek bir bug) ve warning (diğer her şey, zayıf testlerden cila işlerine kadar). Yalnızca critical ve error bulguları hemen düzeltiliyor; warning'ler docs/review-backlog.md adlı bir backlog dosyasına düşüyor. Her değişiklik iki geçiş alıyor ve her ikisi de tüm depo yerine yalnızca değişikliğin kendi diff'ine odaklanıyor — önce critical ve error bulgularının göreve dönüştüğü bir review, sonra düzeltmelerin ardından bir doğrulama geçişi. Doğrulama sırasında ortaya çıkan yeni sorunlar, geri kalanını inşa etmek için kritik olmadıkça backlog'a gidiyor.

Satırlara sabitlenmiş bulgular

Paylaşım, agent'ların yazdığı kodu okumak için bir araç olarak konumlanan Reado adlı IDE'nin blogunda yer alıyor ve o ürün iş akışının merkezinde duruyor. PM, bulguları sohbette paylaşmak yerine bunları tam satırlara sabitlenmiş Reado yorumları olarak bırakıyor; her biri tiplendirilmiş (bug, refactor, performance) ve görev olarak işaretlenmiş. Bunlar depo içindeki .reado/ dizininde Markdown dosyaları olarak saklanıyor ve böylece her iki oturum — ve insan — tek bir paylaşımlı listeye sahip oluyor.

Mühendis her görevi --verify test komutuyla eşleştirilmiş bir task-done komutuyla kapatıyor ve Reado, o görevi yalnızca bu kontrol geçerse tamamlanmış olarak kaydediyor; kanıtlanmamış bir düzeltme unverified olarak işaretli kalıyor. Yazar şimdiye kadar 128 görev rapan ediyor — 115 bug, 5 refactor, 3 performans sorunu ve 5 not — ve hepsi geçen bir verify komutuyla kapatılmış.

İnsanın kendi rolü de buna göre daralmış: oturumlar spec, uygulama, review, düzeltme ve doğrulama döngüsünü kendi başlarına tamamlarken, yazar yalnızca her biten değişikliğin gerçekten merge edilip edilmeyeceğine karar veriyor.

Maliyet, kapsam ve yatay ölçekleme

Bu örüntüye iki uyarı eşlik ediyor. İlki maliyet. Her spec yazılıyor, uygulanıyor, review'dan geçiriliyor, düzeltiliyor ve doğrulanıyor; her adım çok sayıda kod okuyor ve yazar birden fazla kez token'ın bitmesini yaşıyor. Retrospektif öğüdü, daha az zorlayıcı adımları Sonnet gibi daha ucuz bir modele yönlendirmek ve en güçlü modeli spec yazma ile review yapma gibi yargı ağırlıklı işler için saklamak.

İkincisi kapsam. Kurulumun, kapsamı iyi tanımlanmış projelerde en iyi çalışdığı bildiriliyor — rind-ui, test yardımcısı eklenmiş eksiksiz bir bileşen kütüphanesi olarak buna uyuyor — çünkü pek az karar açık kalıyor. Bir karar açık kaldığında ise PM tahmin etmek yerine insana soruyor.

PM rolü de beklentinin ötesinde yatay genişledi: tek bir PM oturumu sırayla birden fazla proje için spec yazabiliyor ve birden çok mühendis oturumunu işle besleyebiliyor. Sonunda üçüncü bir oturum diğer ikisine katılarak dokümantasyon sitesini kurdu ve kütüphane npm'de yayınlandı.

Neden önemli

Cross-session messaging, Claude Code'u tek bir agent'tan atanmış rollere sahip küçük bir takımı andıran bir şeye dönüştürüyor. Bu bir benchmark değil, tek bir geliştiricinin anlatısı — üstelik Reado'nun kendi blogunda yayınlayan bir yazardan — ama çok agent'lı kodlama için somut bir yönetişim örüntüsü çiziyor: tarafsız review için ayrılmış bağlam, review döngülerini sonlanmaya zorlayan şiddet kuralları ve kendi beyanı yerine komutlarla kanıtlanan düzeltmeler. Yazarın defalarca karşılaştığı token faturası, örüntünün ne kadar yayılabileceğinin pratik sınırı.