Üç kodlama ajanını aynı anda ilk kez çalıştırdığınızda, artık yavaş olan kısım yürütme olmaktan çıkar. Bir hatayı Claude Code'a, bir refaktörü Codex'e, bir test kapsamı açığını üçüncü bir Runtime'a verirsiniz ve kırk dakika sonra üç dal hazırdır. Sonra asıl bekleme başlar, çünkü üçü de artık sizi beklemektedir. İlk diff'i okur, onaylarsınız; diğer ikisi boş boş bekler. Paralel yürütmeniz ama seri incelemeniz var; yani paralellik size neredeyse hiçbir şey kazandırmaz.
Ajanları paralel çalıştırmada ustalaşan her ekibi yakalayan tuzak budur. Darboğaz ortadan kalkmaz; sadece yer değiştirir: "bir ajan kodu ne kadar hızlı yazabilir" sorusundan "bir insan sonucu ne kadar hızlı okuyup değerlendirip kabul edebilir" sorusuna. Dördüncü bir ajan eklemek işi daha da kötüleştirir: bitmiş işlerden oluşan daha uzun bir kuyruk, ama hâlâ tek bir gözden geçiren.
Çözüm, daha hızlı incelemek ya da daha fazla güvenmek değil. Çözüm, incelemeyi kafanızın içinde yaşayan bir sonradan akıl yerine iş akışının açık bir parçası olarak tasarlamak. Bu yazının ele aldığı iş akışı bu ve Sharkly'nin etrafında kurulduğu sorun da bu: her ajan çalıştırmasının hedefini, diff'ini, kanıtını ve incelemesini tek bir Task içinde tutmak; böylece inceleme kuyruğu bir yığın açık tarayıcı sekmesi olmaktan çıkıp görüp yönetebileceğiniz bir şeye dönüşür.
Paralel ajanlar darboğazı neden incelemeye taşır
İnceleme bir kuyruktur. Bitmiş ajan çalıştırmaları belli bir hızda gelir, bir kişi bunları belli bir hızda temizler ve gelenler temizlenenden fazlaysa kuyruk sınırsız büyür. Hikâyenin tamamı bu ve ham ajan veriminin optimize edilecek yanlış sayı olmasının nedeni de bu. Bir saatte on ajan bitiyorsa ve siz dikkatli bir şekilde saatte üç değişikliği kabul edebiliyorsanız, yükleme rampasında elinde pano tutan tek bir kişinin durduğu bir fabrika kurmuşsunuz demektir.
Çoğu araç bunu gizler. Bir yığın pull request size işi gösterir; ama hangi öğelerin gerçekten bir karar beklediğini, hangilerinin hâlâ çalıştığını, hangilerinin çoktan birleştirildiğini göstermez. Kuyruk gerçektir, ama sekmelere, bildirimlere ve hafızaya dağılmıştır. İlk tasarım hedefi onu görünür kılmaktır, çünkü göremediğiniz bir darboğazı yönetemezsiniz. İnceleme kapasitesi matematiği üzerine bir yan yazı, eşzamanlılık arttıkça neler olduğunu ele alıyor.
İşletim modeli: kim atar, kim çalıştırır, kim inceler, kim kabul eder
Durumlara dokunmadan önce dört işi adlandırın. Bunlar birbirinden farklı işlerdir ve onları karıştırmak incelemeyi kaotik hissettiren şeydir.
Birileri işi atar: bir niyeti, kabul kriterleri olan kapsamlı bir Task'a dönüştürür. Bir şey onu çalıştırır: bir Computer üzerindeki bir Agent, bir Runtime'da yürütür, bir değişiklik ve ne yaptığının kaydını üretir. Birileri sonucu inceler: diff'i ve kanıtları okur, kriterleri karşılayıp karşılamadığına karar verir. Birileri onu kabul eder: birleştirme ve yayınlama kararını verir; bu, "kod iyi görünüyor" kararından farklı bir karardır.
Sharkly sözleşmeyi, yapışkan bir nota yazmaya değer tek bir cümleyle ortaya koyuyor: ajanlar araştırır, yürütür, test eder ve raporlar; insanlar yön belirler, yetki verir ve sonucu kabul eder. Otomasyon, ekip muhakemesinin gerektiği yerde durur. Atama ve kabul, tasarım gereği insana aittir. Çalıştırma Agent'a aittir. İnceleme ise mühendislik gerektiren iştir, çünkü kuyruğun oluştuğu yer orasıdır.
İşe yarar bir sınır: birleştirilmiş bir PR, kabul edilmiş bir sonuçla aynı şey değildir. Birleştirme bir git işlemidir. Kabul ise bir kişinin değişikliğin Task'ın istediğini yaptığına karar vermesidir. Bu ikisi tek bir tıklamada birleştiğinde, inceleme kalitesi gözden geçirenin o dakikadaki enerjisine düşer.
Roller, durumlar ve inceleme kapıları
Task'lara, ajanların ve insanların arasında hareket ettiği küçük bir durum kümesi tanımlayarak kuyruğa bir şekil verin. Bir Task, işin ana birimidir: hedefi, konuşmayı ve çalıştırmayı barındırır. Durumların amacı, ajanların bir Task'ı inceleme kapısına kadar ilerletebilmesi ve o kapıyı ancak bir insanın geçirebilmesidir.
| Status | Who moves it here | Meaning |
|---|---|---|
| Backlog | Kişi | Kapsamı belirlendi, başlatılmadı. Burada hiçbir çalıştırma gerçekleşmez. |
| Ready | Kişi | Çalıştırılmasına izin verildi; bir Agent bunu üstlenebilir. |
| In progress | Agent | İzole bir worktree'de bir çalıştırma yürütülüyor. |
| Ready for review | Agent | Çalıştırma tamamlandı, değişiklik ve kanıtlar eklendi, bir kişiyi bekliyor. |
| Changes requested | Kişi | Bir yorumla geri gönderildi; bir takip çalıştırması aynı Task üzerinde devam eder. |
| Done | Kişi | Kabul edildi, birleştirildi, yayınlandı. |
Kapı, Ready for review durumuna giriş ve Done durumuna çıkıştır. Ajanlar kapıya kendi başlarına ulaşabilir; ancak kapıdan geçemezler. On ajanı güvenle çalıştırmanızı sağlayan tek kural budur: Ready for review sütununu paralel olarak doldururlar ve siz onu, kaliteyi dürüst tutan her hızda boşaltırsınız. Sütunun uzunluğu, görünür hale gelmiş darboğazınızdır.
İşte dürüst karar çifti. Kullanıcılara giden ya da para, kimlik doğrulama, veri taşıma veya genel API'lere dokunan her değişikliği kapıya bağlayın. Elden çıkarılacak deneysel çalışmaları, zaten yeniden üreteceğiniz üretilmiş boilerplate'i ya da kimsenin henüz erişemediği bir flag arkasındaki işi kapıya bağlamayın. Her şeye kapı koymak, insana hiç ihtiyaç duymayan değişiklikler için darboğazı tekrar gözden geçirene taşır. Onay kapıları yazısı, daha yüksek riskli işlerde durma noktasının nereye konacağını ele alıyor.
İncelemeyi ölçeklenecek şekilde tasarlayın
Paralel ajan çıktısını incelemek, bir ekip arkadaşınızın PR'ını incelemekle aynı şey değildir. Elinizde çok daha fazlası vardır, bunlar dalgalar halinde gelir ve nasıl üretildiğine dair genellikle daha az şey bilirsiniz. Üç hamle, gözden geçirenin öğe başına maliyetini düşük tutar.
Kanıtları hafızanıza değil Task'a ekleyin. Bir çalıştırma; değişiklik özetini, typecheck ve test çıktısını, derleme sonucunu ve bilinen sınırları kayda geçmiş şekilde döndürmelidir. Bir Ready for review öğesini açtığınızda, ne olduğunu yeniden kurgulamak yerine bir dava dosyası okursunuz. Task düzeyinde kanıtlarla inceleme yapmak ile güveni yeniden kazanmak için her şeyi kendiniz baştan çalıştırmak arasındaki fark budur.
Kararı inceleyin, tuş vuruşlarını değil. Makinenin kontrol edebileceği özellikler, biçimlendirme, tip güvenliği, testlerin geçip geçmediği, Task size ulaşmadan önce makineler tarafından kapıya bağlanmalıdır. Google'ın kod inceleme rehberi de aynı ayrımı yapıyor: bir aracın doğrulayabileceği şeyi otomatikleştirin ki insan dikkatini tasarıma ve uyuma harcasın. Kıt olan muhakemeniz "derlendi mi" sorusuna değil, "doğru değişiklik mi" sorusuna gider.
Devam eden işi sınırlayın. Aynı anda kaç Task'ın In progress durumunda olabileceğine dair katı bir sınır, Ready for review sütununun asla aşamayacağınız bir duvara dönüşmesini engeller. Bu, ajanlara uygulanmış kanban WIP limiti fikridir: beş çalıştırma zaten sizi beklerken altıncısını başlatmak verimi artırmaz, kuyruğu gizler. Ayrıca çalışan ajanları izlemek de yardımcı olur; böylece kapıya ulaşmadan önce takılmış bir çalıştırmayı yavaş olanından ayırt edebilirsiniz.
Uçtan uca bir örnek: ticket'tan birleştirilmiş PR'a
Gerçekçi görünen bir Task alalım, SH-312: "Genel arama endpoint'ine hız sınırı uygula." Bir kişi bunu Backlog'da kabul kriterleriyle şekillendirir (anahtar başına dakikada N istekten sonra 429, belgelenmiş header, bir test) ve Ready durumuna taşır.
Üç Agent aynı Space üzerinde paralel çalışıyor. Biri SH-312'yi alır, yapılandırılmış repository'yi bir Computer'a klonlar ve izole bir worktree içinde çalışır; böylece dalı, uçuştaki diğer iki çalıştırmayla asla çakışmaz. Sınırlayıcıyı yazar, bir test ekler, typecheck'i ve test paketini çalıştırır, başlığında Task ID'yi taşıyan bir PR açar ve SH-312'yi değişiklik özeti, geçen test çıktısı ve not edilen bir bilinen sınırla (sayaç proses içinde, instance'lar arasında paylaşılmıyor) Ready for review durumuna taşır.
On beş sekme değil, Task'ı açarsınız. Kanıt tam oradadır ve asıl işe yarayan kısım bilinen sınır notudur: testler geçiyor, ama instance'lar arasında paylaşılan durum, sizin vermeniz gereken bir tasarım kararıdır. Bir yorum bırakır ve Task'ı Changes requested durumuna taşırsınız. Bu yorum, aynı Task üzerinde bir takip çalıştırması başlatır; Agent sayacı paylaşılan bir depoya çevirir ve güncellenmiş kanıtlarla geri döner. Bu sefer kabul edersiniz. SH-312'yi Done durumuna taşımak, bir git merge'ünün sessiz yan etkisi değil, adınızın yazılı olduğu bir durum değişikliği olarak kaydedilen sizin kararınızdır.
Bu arada diğer iki Agent Ready for review içinde bekliyor. Kuyruk gelen kutunuz değil bir sütun olduğu için, konuyu kaybetmeden onları da sırayla temizlersiniz.
İnsanlar için koruduğunuz çizgi
Paralel ajanlar, inceleme kısıt haline gelene kadar bir verim hikâyesidir; sonrasında ise bir kuyruk hikâyesine dönüşürler. Pek çok ajandan değer elde eden ekipler incelemeyi tasarlanmış bir altyapı olarak ele alır: açık durumlar, ajanların ulaşabileceği ama geçemeyeceği bir kapı, Task üzerinde kanıt, insan kontrollerinden önce makine kontrolleri ve uçuşta olabilecek iş miktarına bir sınır.
Bunu worktree'ler, bir dal adlandırma kuralı ve disiplinle elle kurabilirsiniz. Ya da iş akışını Sharkly'nin yönetmesine izin verebilirsiniz: atanabilir Agent'lar, çalıştırmayı ve kanıtlarını taşıyan Task'lar ve Ready for review'ın boşalttığınız bir sütun olduğu bir board; böylece ajanlar araştırır, yürütür, test eder ve raporlarken son kararı insanlar verir. Zaten birkaç ajan çalıştırıyorsanız, görevlerini ve sonuçlarını hafızaya güvenmek yerine yönetebileceğiniz tek bir yer burasıdır.
SSS
İnceleme seriyse, ajanları paralel çalıştırmak zaman kazandırır mı? Yalnızca bitmiş çalıştırmaların sizin kabul edebileceğinizden daha hızlı gelmeye başladığı noktaya kadar. O noktadan sonra ek ajanlar, hiçbir şeyi daha erken sevk etmeden inceleme kuyruğunu büyütür. Kazanç, incelemeyi görünür kılmaktan ve yalnızca insan gerektiren şeylere kapı koymaktan gelir.
Her ajan değişikliği insan incelemesinden geçmeli mi? Hayır. Kullanıcılara giden ya da kimlik doğrulama, veri, para veya genel API'lere dokunan değişikliklere kapı koyun. Düşük riskli veya yeniden üretilebilir işlerin yalnızca makine kontrollerinden geçmesine izin verin. Her şeye kapı koymak, insana hiç ihtiyaç duymayan değişiklikler için darboğazı tekrar gözden geçirene taşır.
PR'ı birleştirmek, işi kabul etmekle aynı şey değil mi? Hayır. Birleştirme bir git işlemidir; kabul ise bir kişinin değişikliğin Task'ın kriterlerini karşıladığına karar vermesidir. İkisini ayrı tutmak, hacim yüksekken inceleme kalitesini korur. İnsan kararının nerede tutulacağını görmek için insan döngüde kodlama ajanları yazısına bakın.
