Çok Ajanlı Kod İnceleme İş Akışı: İki İnceleyici, Tek Son Yazıcı
Birden fazla AI kodlama oturumu kullandığımda sürekli aynı sınırlamayla karşılaşıyorum. Deneyimlerime göre paralel oturumlar farklı kod yollarını buluyor, ancak anlaşmazlıkları ayrı başlıklarda sıkışıp kalıyor. Bir incelemeyi başka bir oturuma kopyalayıp hangi modelin dosyayı doğru anladığına karar vererek mesaj veri yolu haline geliyorum.
Daha iyi tasarım, üç farklı role sahip bir çok ajanlı kod inceleme iş akışıdır. İki AI oturumu aynı dosya revizyonunu bağımsız olarak inceler. Bulgularını paylaşır ve birbirlerinin kanıtlarını sorgular. Üçüncü bir oturum karar kaydını alır, tek bir yama yazar ve kontrolleri çalıştırır.
İnceleme sırasında dosyayı paylaşılan, değiştirilemez bir girdi olarak ele alın. İnceleme bir sonuca ulaştığında yazma erişimini tek bir oturuma verin.
Bu yaklaşım, mevcut hibrit AI kod inceleme döngümden→ farklıdır; bu döngüde bir model yazar, ikinci model ise her düzeltmeyi inceler. Bu döngü zaten inceleyiciye yararlı bir bağımsızlık sağlar. Bir sonraki deney yazma işlemini geciktiriyor: önce iki oturum da inceleme yapıyor, üçüncü oturum ise ancak anlaşmazlıkları bir karar kaydı oluşturduktan sonra kod yazmaya başlıyor.
Bu model, mevcut ajan araçlarının desteklediği yapıya oldukça yakındır. OpenAI'nin Codex alt ajan belgeleri, okuma ağırlıklı keşif, test, önceliklendirme ve inceleme için paralel ajanları önerirken, paralel yazma ağırlıklı iş akışlarının çakışmalar ve koordinasyon yükü oluşturduğu konusunda uyarır. Eksik olan parça, inceleyiciler ile yazıcı arasında birinci sınıf tartışma ve sentez katmanıdır.
Çok ajanlı bir kod inceleme iş akışının neden tek bir yazıcıya ihtiyacı var?
Paralel analiz, birden fazla rakip yama oluşturmadan farklı hata hipotezleri sunar.
Bir inceleyici davranışı ve değişmezleri izleyebilir. Diğeri güvenlik sorunlarını, yarış koşullarını, eksik testleri veya API sözleşmesi ihlallerini arayabilir. Aynı commit SHA ve görevle başlarlar, ancak farklı inceleme brifingleri alırlar. Bu ayrım, her iki oturumun da aynı ilk fikrin peşinden gitme olasılığını azaltır.
Anthropic, Etkili ajanlar oluşturma yazısında benzer bir üretim modelini açıklar: birden fazla model çağrısı kodu farklı bakış açılarından inceleyebilir; orkestratör-işçi iş akışı ise işleri devreder ve sonuçları sentezler. Anthropic ayrıca ekiplerin ajan karmaşıklığını yalnızca ölçülen sonuçları iyileştirdiğinde artırmasını önerir. Üç oturum, tek oturumdan daha fazla token ve zaman harcar; dolayısıyla bu iş akışının var olmak için bir gerekçeye ihtiyacı vardır.
Eşzamanlı değişiklikler nadiren bu gerekçedir. İki ajan aynı çalışma kopyasını düzenlerse sistemin eski bağlamı, çakışan parçaları ve kısmen uygulanmış varsayımları çözmesi gerekir. Git zaten daha güvenli bir temel sunar: bağlantılı worktree'ler, ayrı oturumların aynı depo geçmişini paylaşırken yalıtılmış `HEAD` ve index durumlarını kullanmasına olanak tanır.
İnceleyiciler deneyler için worktree kullanabilir, ancak aday yamadan yalnızca entegratör sorumlu olmalıdır.
Her AI oturumu neyi üstlenmeli?
| Oturum | Erişim | Gerekli çıktı | Yapmaması gereken |
|---|---|---|---|
| --- | --- | --- | --- |
| İnceleyici A | Salt okunur anlık görüntü | Davranış riskleri, bozulmuş değişmezler, satır referansları, önerilen testler | Son dalı düzenlemek |
| İnceleyici B | Salt okunur anlık görüntü | Güvenlik, eşzamanlılık, uç durumlar, karşı örnekler | Kanıt olmadan İnceleyici A'nın sonucunu kopyalamak |
| Entegratör | Özel yazma erişimi | Kabul edilen yama, gerekçeleriyle reddedilen bulgular, test sonuçları, son diff | Kararlaştırılan kapsamın ötesinde yeniden yazmak |
Üçüncü ajan otomatik olarak daha akıllı değildir. Avantajı sahiplikten gelir. Sınırlandırılmış kanıt alır, çatışma çözümünü açık hale getirir ve denetlenebilir tek bir diff üretir.
Ayrıca inceleyicilerin ilk geçişlerinde birbirlerinden habersiz olmalarını sağlardım. Çok ajanlı tartışma üzerine kontrollü bir çalışma, çoğunluk baskısının bağımsız düzeltmeyi bastırabileceğini buldu. Erken iletişim, iki inceleyiciyi tekrarlanan tek bir görüşe dönüştürebilir. Önce bağımsız bulgular gelmeli; tartışma, her ikisi de ilk kanıtlarını kayda geçirdikten sonra başlamalıdır.
İnceleyiciler tek bir dosyayı nasıl tartışmalı?
Serbest biçimli sohbet insanlar için yararlıdır, ancak bir kodlama iş akışının kısa ve öz bir bulgu günlüğüne ihtiyacı vardır. Her iddia, entegratörün özel bir düşünce zincirini yeniden oynatmadan doğrulayabileceği kadar kanıt taşımalıdır.
{ "id": "F-03", "revision": "8a31f2c", "file": "src/auth/session.ts", "lines": "84-103", "claim": "A refresh failure can leave the previous session active", "evidence": "The error branch returns before clearSession()", "risk": "stale authorization state", "proposed_test": "refresh 401 clears the active session", "confidence": "high", "status": "disputed" }
İkinci inceleyici bulguyu kabul edebilir, erişilebilir kod argümanıyla çürütebilir veya kapsamını daraltabilir. Günlük her iki konumu da korur. Sadece uzlaşma doğruluğu kanıtlamaz; kendinden emin bir paragraf da yeniden üretilebilir bir testin önüne geçmemelidir.
Ajan protokolleri bu yöne ilerliyor. Google'ın Agent2Agent protokolü, işbirliğini görevler, mesajlar, durum ve yapıtlar üzerinden modeller. Yerel bir kodlama sisteminin protokolün tamamına ihtiyacı yoktur; ancak sözleşmesini ödünç alabilir: yapılandırılmamış bir döküm yerine türü belirlenmiş mesajlar, kararlı kimlikler, açık durum ve kalıcı yapıtlar kullanın.
AI eş inceleme köprüm→, bir diff'i, odak sorularını ve ikinci bir model için yapılandırılmış bir kararı zaten paketliyor. Üç oturumlu bir iş akışı bir sonraki katmana ihtiyaç duyar: yazıcıya ulaşmadan önce aynı bulgu kimliklerine referans verebilen, itiraz edebilen ve bunları çözebilen iki inceleme paketi.
Yazıcı düzenleme yapmadan önce ne almalı?
Entegratör iki uzun sohbet geçmişini almamalıdır. Küçük bir devir paketine ihtiyacı vardır:
Yazıcı daha sonra mevcut dosyayı yeniden okur ve revizyonunu devir paketiyle karşılaştırır. Uyuşmazlık yazma işlemini durdurur. Bu tek kontrol, dünkü dosyanın geçerli bir incelemesinin bugünkü koda karşı bozuk bir yamaya dönüşmesini engeller.
İzinlerin deterministik hale gelmesi gereken yer de burasıdır. “Yalnızca bu dosyayı düzenle” gibi bir istemin, diğer tüm yolları salt okunur yapan bir araç politikasından daha zayıf olduğunu deterministik AI ajan izinleri→ yazımda savunmuştum. Bu iş akışında izin modeli rol ayrımını zorunlu kılmalıdır: inceleyiciler yazamaz ve entegratör yeni bir karar olmadan kapsamı genişletemez.
Tartışma yazılım yamalarını iyileştirir mi?
Kanıtlar bu yönü destekliyor, ancak her ekibin tam olarak iki inceleyici ve bir yazıcı kullanması gerektiğini kanıtlamıyor.
Çok Ajanlı Tartışma Yoluyla Dil Modellerinde Olgusallığı ve Akıl Yürütmeyi İyileştirme, birden fazla model örneğinin birkaç tur boyunca yanıtlar önerebildiğini, eleştirebildiğini ve geliştirebildiğini; bunun da makalenin akıl yürütme ve olgusallık görevlerindeki sonuçları iyileştirdiğini gösteriyor. Bu deneyler Git çakışmalarını veya üretim pull request'lerini test etmedi.
Daha yakın bir kodlama örneği 2025 tarihli SWE-Debate ön baskısında ortaya çıktı. Ajanları rakip hata yerelleştirme izlerini tartışıyor, bir düzeltme planını birleştiriyor ve bu planı ayrı bir yama oluşturma ajanına iletiyor. Makale, SWE-bench Verified üzerinde 500 görevden 207'sinin çözüldüğünü, yani %41,4 oranını; en güçlü listelenen temel yöntemleri için ise %38,8 oranını bildiriyor. Karşılaştırma ölçütü ve mimari önerdiğim iş akışından farklı, ancak ayrım dikkat çekici: önce çeşitli analiz, ardından tek bir değişiklik aşaması.
Dürüst bir sonraki adım, gerçek pull request'ler üzerinde küçük ve kontrollü bir değerlendirmedir. Tek bir kodlama ajanını, 10 ila 20 hata boyunca üç oturumlu iş akışıyla karşılaştırın. Geçerli bulguları, yanlış pozitifleri, birleştirme çakışmalarını, kabul edilebilir bir yamaya ulaşma süresini ve ilk taslaktan sonra yakalanan regresyonları ölçün. Daha fazla ajan mesajı bir başarı ölçütü değildir.
Yazıcı tek bir denetlenebilir yamayı nasıl üretir?
Entegratör dar kapsamlı bir döngü izlemelidir:
Son inceleme tasarım tartışmasını baştan başlatmamalı, yamayı incelemelidir. Her inceleyici iki soruyu yanıtlar: yazıcı kabul edilen kararı uyguladı mı ve yama yeni bir risk oluşturdu mu?
OpenAI'nin mevcut Codex uygulaması, ajanların aynı yerel Git durumuna dokunmadan paralel çalışabilmesi için ayrı thread'ler ve worktree'ler kullanıyor; geliştiricilerin her diff'i incelemesine ve yorumlamasına da olanak tanıyor. Codex uygulaması duyurusu, yalıtım katmanının mevcut olduğunu gösteriyor. Paylaşılan bir bulgu günlüğü ve açık bir entegratör rolü, paralel görevleri koordineli bir inceleme odasına dönüştürür.
Hangi başarısızlıklar devam eder?
Tek bir yazıcı düzenleme yarışlarını ortadan kaldırır, model hatasını değil.
İki inceleyici, özellikle aynı model, istem ve bağlamı kullandıklarında aynı kör noktayı paylaşabilir. Entegratör doğru argüman yerine daha ikna edici argümanı seçebilir. Depo yorumları güvenilmeyen talimatlar içerebilir. Başarılı bir test paketi, kullanıcıların bağlı olduğu davranışı gözden kaçırabilir.
İş akışının korumalara ihtiyacı vardır:
21,54 milyar kod ajanı etkinlik token'ı→ sonrasındaki önceki sonucum hâlâ geçerli: modelin etrafındaki sistem, daha fazla zekânın yararlı işe mi yoksa daha hızlı temizliğe mi dönüşeceğine karar verir.
Üç oturumlu bir iş akışı ne zaman değerlidir?
Yanlış bir yamanın maliyetli olduğu veya kodun birden fazla makul yoruma sahip olduğu durumlarda kullanın: kimlik doğrulama, izinler, ödemeler, migration'lar, eşzamanlılık, herkese açık API'ler ve olay düzeltmeleri. Kıdemli bir mühendisin normalde farklı risk alanlarını incelemeleri için iki uzmandan yardım isteyeceği durumlarda da yararlı olabilir.
Biçimlendirme, oluşturulan dosyalar, basit yeniden adlandırmalar ve açık bir test oracle'ına sahip değişiklikler için kullanmayın. Anthropic'in çok ajanlı ekibi, koordinasyon karmaşıklığının hızla arttığını ve üretim araştırma sisteminin açık görev devrine ve uzmanlaşmış sonuçları sentezleyen bir lider ajana dayandığını buldu. Kodlama da aynı disiplini gerektirir, ancak belirsiz yazma işlemlerine daha az tolerans gösterir.
Kodlama ajanlarının içlerinden biri imleci almadan önce kanıtları tartışmasını istiyorum. İki oturum aynı dosyayı incelemeli, anlaşmazlıklarını açıkça ortaya koymalı ve tek bir karar kaydı bırakmalı. Üçüncü oturum aday yamayı yazmalı ve onu depo karşısında kanıtlamalıdır.
Bu adayın hâlâ testlere, diff incelemesine ve insanın sürüm kararına ihtiyacı vardır. Üç AI oturumu yamaya giden yolu iyileştirebilir; yamayı gerçeğe dönüştürmez.
SSS
İki AI ajanı aynı dosyayı aynı anda düzenleyebilir mi?
Düzenleyebilir, ancak paylaşılan yazma işlemleri eski bağlam ve çakışan düzenlemeler oluşturur. Her iki ajanın da aynı revizyonu salt okunur modda analiz etmesine veya deneyleri ayrı worktree'lerde yalıtmasına izin verin; ardından son dala özel yazma erişimini tek bir entegratöre verin.
Her iki inceleyici de aynı modeli kullanmalı mı?
Kullanabilirler, ancak farklı istemler, roller veya model aileleri ilişkili kör noktaları azaltabilir. Çeşitlilik doğruluğu garanti etmez; bu nedenle iş akışı hâlâ kanıt ve test gerektirir.
İnceleyiciler anlaşamadığında ne olur?
Her iki konumu da bulgu günlüğüne kaydedin. Entegratör iddiayı yeniden üretmeli, önerilen testi çalıştırmalı veya sorunu insan incelemesi için çözümlenmemiş olarak işaretlemelidir. Çoğunluk oylaması, doğrulanabilir kanıtın zayıf bir alternatifidir.
Üçüncü AI oturumu insan kod incelemesinin yerini alır mı?
Hayır. Üçüncü oturum sentezden ve aday yazma işleminden sorumludur. Bir insan hâlâ yamanın daha geniş sisteme, ürün amacına ve sürüm riskine uyup uymadığına karar verir.
Bu iş akışı birden fazla dosyadaki değişiklikleri ele alabilir mi?
Evet. İncelenen her dosyayı aynı depo revizyonuna sabitleyin, açık sahiplik atayın ve tek bir entegrasyon dalı kullanın. İnceleyiciler yalıtılmış worktree'lerde çalışabilir; entegratör ise son yamayı bir araya getiren tek oturum olarak kalır.