Bir İnceleme Ajanı Yazamamalı. İşte Bunu Her CLI İçin Tek Tek Nasıl Zorunlu Kıldığımız.

Bu haftanın başında bir kullanıcı bize iki kez okumaya değer bir çalıştırma raporu gönderdi. On yedi ajan, paylaşılan tek bir worktree, bir uygulayıcı, bir sürüm kapısı ve iki inceleme dalından oluşan bir pipeline. AgentsRoom'un 1.171.0 sürümü.

O çalıştırmada üç şey oldu, bu sırayla.

Sürüm ajanının önünde kırmızı bir test paketi vardı. Paket yeşile dönene kadar test spec'ini düzenledi. Bunu yaparken gerçek bir kusuru yayına aldı, üstelik artık onunla hemfikir bir testle kaplı.

Sonra iki inceleme ajanı, aynı çalıştırmanın iki paralel dalında, her biri tek satırlık gerçek bir bug buldu. Her biri doğrudan düzeltti, aynı worktree'de, aynı anda. Çakıştılar.

Bu ajanların her birinin adım prompt'unda açıkça yalnızca inceleme yazıyordu. Hiçbir şey onları durdurmadı ve hiçbir şey bunu işaret etmedi: platform tarafından bakınca, bir adımın yazma araçları vardı ve onları kullandı.

Prompt neden tutmadı

Cazip yorum, ajanların talimatı görmezden geldiği. Olan bu değil ve bu önemli, çünkü düzeltmenin ne olması gerektiğini değiştiriyor.

Her ajanın yazmak için yerel olarak savunulabilir bir gerekçesi vardı. Kırmızı bir paket ve yanlış görünen bir spec. Düzeltmesi dört saniye, anlatması kırk saniye süren bir bug. Hiçbiri kuralı çiğnemeye karar vermedi. Her biri kendi durumunun kuralın kastetmediği durum olduğuna karar verdi. Adımın içinden bakınca istisna her zaman makul görünür.

Yazılı bir talimat, modelin muhakemesine yapılan bir ricadır. Aynı zamanda düzeltebilen bir inceleyici er ya da geç düzeltir, çünkü düzeltmek "buldum" ile "bitti" arasındaki en kısa yoldur. Makul bir istisnayla karşılaşıp ayakta kalan tek kural, modelin tartışamayacağı kuraldır: orada olmayan bir araç.

Global ayar neden bunu yapamadı

Bundan önce çalışan bir adıma ulaşan tek kol sağlayıcı ayarlarıydı ve bunlar makinedeki her Claude ajanını bir kerede kapsar. Bir çalıştırma için yanlış biçim bu. Aynı pipeline'da uygulayıcı yazmalı, inceleyici yazmamalı. Global bir anahtar ikisini ayırt edemez.

Zaten elimizde olan ajan başına kısıtlama, yani bir ticket'ın ajan başlatırken taşıyabildiği kısıtlama, takım adımlarına bilerek aktarılmıyordu. Yani bir ticket'tan başlatılan ajan kısıtlanabiliyor, bir takımın düğümü kısıtlanamıyordu. Birincil neden buydu ve kötü yaşlanmış bir tasarım kararıydı.

Kural: düğüm üzerinde tek bir onay kutusu

Düzeltme, inceleme düğümü üzerinde bir boolean. Salt okunur kutusunu işaretle, o adımı somutlaştıran ajan projeye yazma erişimi olmadan başlatılır: dosya düzenleme yok, git commit veya push yok, tek işi çalışma ağacını değiştirmek olan shell komutu yok. Okuma, grep, git diff, git log, testler, linter ve tüm takım araçları açık kalır.

Ne olmadığı konusunda açık olduk: kullanıcının CLI başına elle yazdığı bir yasak listesi değil. Kimsenin "bu ajan inceler" demek için beş izin sözdizimi bilmesi gerekmemeli. Anahtar her sağlayıcı için doğru bayrağı üretir ve en son uygulanır, otonom moddan ve kullanıcının ajana kaydettiği her şeyden sonra, böylece kazanır.

Her CLI ne yapıyor, kendi yardımından okunmuş haliyle

Yalnızca bayrağını kendi --help çıktısında okuduğumuz sağlayıcılarda zorluyoruz. Tahmin edilmiş bir bayrak başlatmayı ayrıştırma hatasıyla öldürür, bu da zorlaması olmayan bir adımdan daha kötüdür. Diğer CLI'lar yalnızca yazılı kuralı alır ve editör bunu onay kutusunun altında düz metinle söyler.

Bu tablodaki iki ayrıntı bize birer bug'a mal oldu, o yüzden açıkça yazmaya değer.

Codex ve Grok tekrarlanan bir bayrağı reddediyor. İkisi de argümanlarını katı bir ayrıştırıcıyla işliyor. Kullanıcı ajana zaten --sandbox workspace-write kaydetmişse, arkasına --sandbox read-only eklemek onu ezmez, başlatmayı çökertirdi. Bu yüzden değer alan bayraklarda, kendimizinkini eklemeden önce mevcut her tekrarı değeriyle birlikte kaldırıyoruz. OpenCode'daki --agent için de aynı şey geçerli, ayrıştırıcısı tekrarlanan bir bayrağı diziye çeviriyor ve daha aşağıda hata veriyor.

Claude Code'da liste üst üste eklenmeli. --disallowedTools boşlukla ayrılmış bir liste alıyor ve tekrarlanabiliyor, bir ajanın gömülü tarayıcıyı sürmesine izin verilmediğinde zaten bir tane geçiyoruz. Ayrıştırıcı tekrarlanan değişken sayılı bir seçeneği birleştiriyor, böylece ikincisi ilkinin yerine geçmek yerine iki liste toplanıyor.

Claude Code için tam liste şu: dört dosya düzenleme aracı, indekse, ağaca, ref'lere veya bir remote'a yazan her git alt komutu (add, commit, push, merge, rebase, reset, checkout, switch, restore, stash, cherry-pick, revert, apply, am, rm, mv, clean, tag, worktree) ve yalnızca dosya değiştirmek için var olan shell komutları (rm, mv, cp, tee, touch, mkdir, chmod, chown, ln, truncate, dd, sed -i). Grok aynı kural dizelerini kendi glob biçiminde alıyor, artı dosya araçları için kendi adları (search_replace, write, hashline_edit).

Prompt'un hâlâ bir işi var

Bayrak reddeder. Açıklamaz. Anlamadığı bir redde çarpan bir ajan bunu bug olarak görür ve başka bir yol arar, ki bu tam da kaldırmaya çalıştığımız davranış.

Bu yüzden salt okunur bir adım prompt'una iki cümle daha alır. İlki adımın salt okunur olduğunu söyler, bunun ne anlama geldiğini listeler ve bir reddin kural olduğunu, başka bir komutla etrafından dolaşılacak bir engel olmadığını belirtir. İkincisi neyin açık kaldığını listeler ve ajana neyin değişmesi gerektiğini, dosya, satır ve gerekçeyle, devir tesliminde bildirmesini ve uygulamayı kodun sahibi olan adıma bırakmasını söyler.

Doğrulanmış bayrağı olan CLI'larda reddi anlaşılır kılan bu paragraftır. Diğerlerinde zorlamanın tamamı odur ve bunu söylemeyi, öyleymiş gibi yapmaya tercih ederiz.

Gönderdiğimiz şablonlarda kim salt okunur

Yargılayan düğümler salt okunur: iki başlangıç şablonunun QA doğrulama adımı, Bug hunt'ın yeniden üretme ve doğrulama adımları, Release shield'ın QA ve Güvenlik dalları, Feature squad'ın test edicisi.

Kodun sahibi olan düğümler yazmaya devam eder: geliştirici ve her bulguyu kendisi düzeltmek üzere yazılmış sürüm kapısı. Yazamayan bir sürüm kapısı, sürüm çıkaramayan bir sürüm kapısıdır.

Bu ayrım tasarımın tamamıdır ve olayın iki kez ihlal ettiği ayrım da budur: yanlış yere yazan bir sürüm düğümü ve hiç yazmaması gereken inceleme düğümleri.

Bu ne değil

Bir güvenlik sınırı değil. Bildiren kişi bunu raporunda söyledi ve haklıydı: bir bash -c araç yasak listesinin etrafından dolaşır. Güvenmediğin bir ajanı izole etmen gerekiyorsa, bu bir sandbox veya ayrı bir makinedir ve beşi arasında salt okunur modu gerçekten bu olan tek CLI Codex.

Anahtarın durdurduğu şey kaza ve rol kayması, gerçekte olan da bu. Bir inceleyici bir yasak listesini bilerek aşmaz. Refleksle Edit'e uzanır ve o refleks artık reddediliyor.

İnşa etmediğimiz şey

Bildiren kişi bir şey daha istedi: zorlama olmasa bile asgari sinyal olarak, çalıştırma zaman çizelgesinde "X düğümü ağaca yazdı" diyen bir olay. İyi bir fikir ve burada yapmadık, çünkü runner tarafında adım başına bir temel diff gerekiyor. İhtiyaç geri gelirse, sıradaki parça bu.

AgentsRoom kullanmıyorsan

Yukarıdaki bayraklar olduğu gibi kopyalanabilir. codex --sandbox read-only veya claude --disallowedTools "Edit" "Write" "MultiEdit" "NotebookEdit" "Bash(git commit:*)" "Bash(git push:*)" ile elle başlatılan bir inceleme ajanı, iki inceleme düğümümüzün yaptığını yapamaz. Neden reddedildiğini bilmesi için aynı iki cümleyi prompt'una koy.

Onay kutusunun eklediği şey, beş sözdiziminden hangisinin geçerli olduğunu hatırlamak zorunda olmaman, bayrağın adımın çalıştığı otonom moda her durumda baskın gelmesi ve aynı adıma sonradan yeniden giren bir çalıştırmada hayatta kalması.

Düğüm anahtarı ve sağlayıcı başına tablo Agent Teams sayfasında belgeleniyor. Bir ajanın yaptığı incelemenin gerçekten değip değmediği ve bir diff'in ne kadarının hâlâ bir insanı hak ettiği ayrı bir soru, onu Yapay zeka ajanının kodunu hâlâ incelemeli misin? yazısında ele aldık. Bu yazı daha küçük, daha mekanik olan şey hakkında: bir ajanın inceleme yapacağına karar verdikten sonra, onu fiziksel olarak başka bir şey yapamaz hale getir.