Döngüde insan (human-in-the-loop) kodlama ajanları genellikle bir ayar olarak tanımlanır: aracın düzenleme yapmadan önce soru sorduğu mod. Bu bir döngüdür ve en küçüğüdür. Tek bir geliştiricinin terminalinde, tek bir oturum boyunca çalışır ve oturum bittiğinde buharlaşıp gider. Herkes Claude Code'u Manual modda bıraktığı için insan gözetimi olduğunu düşünen bir ekip, sonuçların değil tuş vuruşlarının gözetimine sahiptir.
Bu kılavuz, inceleme iş akışını beş kapı hâlinde ortaya koyuyor: çalışma zamanının içindeki izin isteminden paylaşılan kayıttaki kabul kararına kadar. Ayrıca her kapıda kimin karar verdiğini ve bu kararın nereye yazıldığını söylüyor. Çalışma zamanı kapıları, araçların kendi dokümantasyonundan geliyor. Ekip kapıları ise Sharkly'yi kullanıyor, çünkü Sharkly bunları birinin terminal geçmişi yerine Task üzerinde kaydediyor. Önce pratiğin tanımını arıyorsanız, AI agent project management rehberimiz bu iş akışının içinde yaşadığı döngüyü ele alıyor.
TL;DR
Kodlama ajanları için döngüde insan inceleme iş akışının beş kapısı vardır: çalışma zamanının izin modu; iş Task'lara dönüşmeden önceki plan onayı; bir çalıştırmanın ne zaman başlayabileceğine karar veren yürütme sınırı; incelemeyi adı belli bir kişiye yönlendiren dikkat sinyali; ve o kişinin bir durum değişikliği olarak kaydettiği kabul. Yalnızca ilk kapı bir araç ayarıdır. Diğer dördü ekip kararlarıdır ve gerçek olabilmek için paylaşılan bir kayda ihtiyaç duyar. Agent'lar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder.
1. Kapı: Çalışma zamanının içindeki izin modu
Her ciddi kodlama ajanı bir onay kadranıyla gelir. Claude Code'un izin modları, düzenlemelerden, shell komutlarından ve ağ erişiminden önce soran ve Manual olarak etiketlenen default modundan başlar; acceptEdits, plan ve sizin yerinize classifier adlı ikinci bir modelin eylemleri incelediği auto modundan geçerek yalnızca izole konteynerler için bypassPermissions moduna kadar uzanır. Geçiş yapmak için Shift+Tab veya --permission-mode kullanın. Codex de aynı fikri /permissions komutuyla sunar; bu komut, dosyaları ne zaman düzenleyebileceğini veya komutları sormadan ne zaman çalıştırabileceğini ayarlar.
Bu kapı gerekli ama yetersizdir. Oturum başına ve geliştirici başınadır, gereksinimi değil makineyi korur ve bir ekip arkadaşının okuyabileceği hiçbir kayıt bırakmaz. Pro, Max ve Team planlarında Claude Code artık varsayılan olarak auto modda başlıyor; bu makul bir seçim, çünkü classifier yorgun bir insanın "evet"e tıklamasından daha hızlı ve daha tutarlı. Buradan çıkarılacak ders kadranla savaşmak değil. Kadranı inceleme yerine koymayı bırakmaktır.
2. Kapı: Plan onayı
İlk ekip düzeyi kapı, henüz hiç kod yokken devreye girer. Sharkly'nin Agent sohbetinde Plan modu, Agent'ın incelemeniz için eylemler önermesini sağlar; planlanan Task ve alt görevler yalnızca bir kişi öneriyi onayladıktan sonra oluşturulur. Başlatmadan onaylayabilir ya da onaylayıp başlatabilirsiniz.
Kapsam burada belirlenir ve bu ucuzdur: önerilen bir alt görevi düzenlemek bir dakika sürer, istenmeyen bir refactor'ı incelemek ise bir öğleden sonra. Yalnızca analiz istiyorsanız Explore seçili kalsın. Bir liderin hedefi yorumlaması ve diğer Agent üyelerini dahil etmesi gerektiğinde Crew kullanın; işi tek bir rol karşılıyorsa tek bir Agent kullanın ve töreni atlayın. Bir AI agent ile sohbet etme veya Task atama rehberimiz üç modu ele alıyor.
3. Kapı: Yürütme sınırı
Bir Agent'a atanan Task, Backlog'da olduğu sürece başlamaz. Onu kategorisi çalışmaya hazır olan bir duruma taşımak, çalıştırmayı başlatan şeydir; completed, canceled ve duplicate kategorileri ise hiçbir zaman ilk çalıştırmayı başlatmaz. Dolayısıyla durum kategorisi, bir kişinin bilinçli olarak işlettiği bir kapıdır ve panoda görünür.
Bu kapıyı salt bir formaliteden fazlası yapan iki şey var. Her çalıştırma izole bir dizin alır ve depo destekli çalıştırmalar yeni bir worktree hazırlar; böylece onaylanmış bir çalıştırma, kimsenin onaylamadığı bir çalıştırmaya zarar veremez. Ayrıca çalıştırma; Task açıklamasını, son yorumları ve Agent'ın seçebileceği durumları kısıtlayan Task tipi Workflow'u taşır. Workflow ona bu durumu vermiyorsa bir Agent kendi işini kabul edildi olarak işaretleyemez. AI kodlama ajanlarıyla Git worktree'leri yazımız izolasyonu açıklıyor.
4. Kapı: Dikkat sinyali
Bir Agent bir çalıştırmayı iki faydalı yerden birinde bitirir: bir sonuçla ya da bir soruyla. Sharkly ikisini de adlandırır. Bir Agent, bir Task'ı insan yanıtı bekliyor veya insan incelemesi bekliyor durumunda bırakabilir; başarısız veya engellenmiş işler ise bir dikkat öğesi olarak ortaya çıkar. Bu sinyaller, sorumlu kişi için Inbox'ta, Primary bölümünde yer alır; çalıştırma hataları ise tüm abonelere değil, atanmış kişiye gider.
Buradaki kapı yönlendirmedir ve çoğu ekibin farkında olmadan yanlış yaptığı kapı da budur. Bir kanala giden inceleme, kimseye gitmez. Task üzerinde, yürütme günlüğü bir tık uzakta olacak şekilde insan atanana giden inceleme ise daha sonra hesap sorulabilecek birine gider. AI agent inbox rehberimiz kuyruk mekaniğini ele alıyor.
İşin devam etmesi de yanıt vermekle olur. Hazır bir Agent atanmış olan bir Task'a bir üyenin yaptığı yorum başka bir çalıştırmayı kuyruğa alabilir; böylece inceleme geri bildirimi ikinci bir süreç başlatmak yerine aynı işi sürdürür. Bir kişiden bahsetmek veya tümünü etiketlemek tek başına bir Agent'ı başlatmaz; bu da insandan insana bir konuşmanın Agent'ı uyandırmasını engeller.
5. Kapı: Kayıt üzerinde kabul
Kabul, kanıtları okuduktan sonra bir kişinin Task durumunu değiştirmesidir. Şu sırayla okuyun: açıklamadaki kabul kriterleri, Agent'ın çalıştırdığı kontrolleri ve hâlâ belirsiz olanı belirten yorumu, yürütme günlüğü, ardından diff. Günlük; çalıştırmanın neden kuyruğa alındığını, ne zaman başlayıp bittiğini, araç çağrılarını ve Runtime olaylarını, tetikleyici kaynağını ve hata ayrıntılarını kaydeder; bir değişikliği incelemek ile bir değişiklik hikâyesini incelemek arasındaki fark budur.
Bu kapıyı iki kural korur. Bağlantılı bir pull request'i merge etmek Task durumunu değiştirmez; böylece bir merge hiçbir zaman kabul sanılmaz. Ve tamamlanmış bir Automation çalıştırması, çalıştırmayı tanımlar; sonraki tüm sonuçların doğru olduğuna dair bir vaat değildir. İkisi de doğrudan ürün dokümantasyonundan geliyor ve ikisi de ekiplerin bitmiş ile doğruyu karıştırmayı sürdürmesi yüzünden var.
İş akışı tek bir tabloda
| Kapı | Yanıtladığı soru | Kim karar verir | Nereye kaydedilir |
|---|---|---|---|
| İzin modu | Bu oturum ona dokunabilir mi? | Geliştirici | Hiçbir paylaşılan yere |
| Plan onayı | Doğru parçalama bu mu? | Öneri üzerinde bir kişi | Onaylanan alt görevler |
| Yürütme sınırı | Bu Task şimdi çalışabilir mi? | Onu Backlog'dan çıkaran kişi | Activity'de durum değişikliği |
| Dikkat sinyali | Kim bakmalı ve neye? | Sharkly bunu atanana yönlendirir | Inbox Primary ve Task |
| Kabul | Sonuç doğru mu? | İnsan atanan | Adı belli bir kişinin yaptığı durum değişikliği |
Kapılar ne zaman daha geniş açılmalı
Her Task beş durak hak etmez ve aksini varsaymak, incelemenin tiyatroya dönüşme yoludur. Depo denetimi gibi salt okunur işler 1. ve 5. kapıya ihtiyaç duyar. İzole bir worktree'deki geri alınabilir işler, örneğin testlerle birlikte bir bağımlılık güncellemesi, plan onayını atlayabilir. Zamanlamayla çalışan Automation'ların talimatları, bir kişinin ne zaman incelemesi veya karar vermesi gerektiğini belirtmeli ve kimse bu zamanlamaya bağımlı hâle gelmeden önce elle çalıştırılıp incelenmelidir; Sharkly'deki Automation'lar rehberimiz bunu ele alıyor.
Herkese açık bir arayüzü değiştiren, verilere dokunan veya tek bir komutla geri alınamayan her şey için beş kapıyı da koruyun. Ve her yerde tek bir kuralı elden bırakmayın: her Agent Task'ında adı belli bir insan atanan olsun. Sharkly, insan sorumluluğunu Agent yürütmesinden bilinçli olarak ayırır; böylece bir Task'ta aynı anda hem atanmış insanlar hem de atanmış bir Agent bulunabilir. Hesap verebilirlik devredilmez ve kayıt, onu kimin taşıdığını göstermelidir.
Döngüde insan ne değildir
Terminali izleyen bir kişi değildir. Arkasında yorgun bir inceleyicinin durduğu bir izin istemi değildir. Ve Completed yazan bir durum da değildir. Automation, ekip muhakemesinin gerektiği yerde durur ve eksiksiz bağlam ile incelenebilir kanıtlarla birlikte bir teslim geri döndürür. Bu cümle iş akışının tamamıdır; kapılar yalnızca bunun uygulandığı yerlerdir. Sharkly, Claude Code, Codex veya diğer yürütme araçlarının yerini almaz; bu kararları yazıya döken katmandır.
SSS
Claude Code'daki auto modu, insanı döngüden çıkarır mı? İnsanı izin isteminden çıkarır. Classifier, eylemleri isteğinize göre inceler; sonucun gereksinimi karşılayıp karşılamadığını incelemez. 2'den 5'e kadar olan kapılar hâlâ insanlara aittir.
Bir Agent'ı çalışırken nasıl durdururum? Kuyruğa alınmış veya çalışan bir yürütme iptal edilebilir. Bir Task'ı Canceled veya Duplicate durumuna taşımak da etkin çalıştırmaları durdurur; Completed durumuna taşımak durdurmaz, bu yüzden Agent hâlâ çalışıyorsa önce iptal edin.
İnceleyici kim olmalı? Task'taki insan atanan. Sharkly, inceleme bekliyor ve hata sinyallerini o kişiye gönderir; bu yüzden her Agent Task'ı bir kişiyi adlandırmalıdır. Sharkly'deki Agent'lar rehberimiz iki atama yuvasını açıklıyor.
İnceleme geri bildirimi yeni bir Task olmadan Agent'a geri dönebilir mi? Evet. Task'a yapılan bir yorum, atanmış Agent için bir takip çalıştırmasını kuyruğa alabilir ve art arda hızlı gelen yorumlar birleştirilir; böylece yinelenen çalıştırmalar oluşmaz.
