Kodlama Ajanları için Onay Kapıları: Merge Etmeden Önce Onları Nerede Durdurmalısınız?

Pull request açabilen bir kodlama ajanı işe yarar. Kimse izlemezken pull request'i merge edebilen bir kodlama ajanı ise commit erişimi olan bir risk unsurudur. Bu iki cümle arasındaki uçurum, asıl sorunun tamamıdır. Bir ajan bir dala push yapabildiğinde, testleri çalıştırabildiğinde ve merge'e tıklayabildiğinde, soru artık “bu işi yapabilir mi” olmaktan çıkar ve “yetkisi nerede bitiyor” sorusuna dönüşür.

Çoğu ekip bu soruyu farkında olmadan yanıtlar. Ajan, çalışma zamanına verilen izinlere sahiptir; inceleme, çalıştırmanın başlatıldığı terminalde yapılır ve kimin neyi onayladığının kaydı bir kişinin terminal geçmişinde kalır. Bu düzen, iki depoda üç ajan çalıştırana ve bir Cuma günü dağıtımı kimsenin okumadığı bir şeyi canlıya alana kadar idare eder. Onay kapısı çözümdür; ama yalnızca herkesin uymasını umduğunuz bir alışkanlık değil, paylaşılan bir sistemde gerçek bir kontrol noktası olduğunda.

İşte o paylaşılan sistemi Sharkly sağlıyor. Kodlama ajanlarınız zaten var; Sharkly onların çalıştırmalarını durumları, Atananları ve bir kişinin bilinçli olarak yapması gereken bir inceleme adımı olan Görevlere dönüştürür. Bu makale, bunun arkasındaki çalışma modelini ele alıyor: işi kim atar, kim çalıştırır, kim inceler, kim kabul eder ve bir ajanın kendi değişikliğini incelenmeden merge etmemesi için durma noktası tam olarak nereye aittir.

Onay kapısı aslında nedir

Onay kapısı, bir görevin yaşam döngüsünde otomatik yürütmenin durduğu ve bir kişinin sonraki adıma karar vermesini beklediği noktadır. Bir uyarı değil, kaydırıp geçebileceğiniz bir log satırı değil: işin, bir insan onu ilerletinceye kadar beklediği bir durum.

En çok önem taşıyan ayrım, bir ajanın bir değişikliği önermesi ile o değişikliği merge etmesi arasındadır. Pull request açmak bir öneridir. Onu merge etmek ise üretimle ilgili bir karardır. Bunlar birbirinden farklı yetki eylemleridir ve ekip muhakemesinin bulunması gereken yer ikincisidir. Sharkly bu sınırı açıkça ortaya koyar: GitHub bağlı olsa bile bir pull request'in merge edilmesi Görev durumunu değiştirmez. Merge, kayda geçen bir insan eylemi olarak kalır; ajanın işi bitirmesiyle tetiklediği bir yan etki değildir.

Bu sınırı aklınızda tutun, çünkü çoğu “ajan prod'u bozdu” hikâyesi aslında öneri ile merge arasında eksik bir kapıya dair bir hikâyedir.

Çalışma modeli: ata, çalıştır, incele, kabul et

Sharkly bir görevi, her birinin tek bir işi olan dört role böler. Sözleşme nettir: Ajanlar araştırır, yürütür, test eder ve raporlar; Kişiler yön belirler, yetki verir ve sonucu kabul eder.

• Ata. Bir kişi ihtiyacı tanımlar ve Atananı belirler. Bir Görev iki ayrı atama taşır: üzerindeki Kişiler ve işi yürüten tek bir yürütme Atananı (Ajan ya da Crew). Birini değiştirmek diğerini değiştirmez.
• Çalıştır. Yürütme Atananı işi izole bir git worktree içinde yapar, böylece paralel çalıştırmalar birbirinin dosyalarına dokunmaz. İlerleme, engeller ve sonuçlar Göreve geri döner.
• İncele. Ajan işi bitirdiğinde, Görevi kapatmak yerine insan incelemesini bekleyen bir hâlde bırakır. Diff, test çıktısı ve değişiklik özeti bir terminale değil, Göreve eklenir.
• Kabul et. Bir kişi kanıtları okur ve karar verir: değişiklik talep et ya da kabul edip merge et. Kabul, son hamledir ve bunu yalnızca bir kişi yapar.

Buradaki değer, Sharkly'nin ajanı çalıştırması değil. Değer, dört rolün o anda açık olan terminale sıkışmak yerine tek bir yerde görünür kalmasıdır. İnceleme tarafının daha ayrıntılı hâli için human-in-the-loop coding agents yazısına bakın.

Kapıyı bir alışkanlık değil, bir durum hâline getirin

Hatırlamak zorunda olduğunuz bir kapı, eninde sonunda atlayacağınız bir kapıdır. O yüzden onu görev yaşam döngüsüne işleyin.

Sharkly'nin durumları, kategorileri aracılığıyla sistem anlamı taşır. Backlog bir bekleme durumudur: oradaki bir Görev, kendisine bir Ajan atanmış olsa bile yürütülmez. Onu işe hazır bir kategoriye taşımak, yürütmenin başlamasını sağlar. Completed ise son durumdur ve oraya ulaşmak bir insan hamlesidir; Ajanın kendine bahşettiği bir şey değildir.

Görev durumu, Ajanın çalışma durumundan kasten ayrı tutulur. Yaşam döngüsü durumu In Progress okunurken, alttaki Ajan çalışıyor, bir insan yanıtı bekliyor, insan incelemesi bekliyor ya da bir hata bildiriyor olabilir. Kapının ta kendisi bu ayrımdır: Ajan çalıştırmasını bitirip “insan incelemesi bekleniyor” bilgisini yüzeye çıkarabilir; Görev ise hiçbir zaman canlıya alındığını ima eden bir duruma geçmez. İş Göreve geri döner ve biri onu kabul edene kadar orada durur.

Birden fazla ajanı aynı anda çalıştırmayı güvenli kılan da budur. İzole worktree'lerdeki beş paralel ajan aynı inceleme sütununa düştüğünde, başlarında beklemeniz gereken beş terminal yerine onları tek bir yerden değerlendirebilirsiniz.

Uygulamalı bir örnek: ticket'tan merge edilmiş PR'a

Sharkly'nin SH-312 biçimindeki tanımlayıcısını kullanarak tek bir Görevi baştan sona izleyelim.

1. Oluştur. Bir kişi SH-312 numaralı hata görevini açar: “Arama, filtre değişikliğinden sonra eski sonuçları döndürüyor.” Açıklama; hedefi, yeniden üretim adımlarını ve kabul kriterlerini içerir. Atanan: arama deposuna bağlı bir Claude Code Ajanı.
2. Şekillendir. Ajan kod tabanını ve ilgili geçmişi araştırır, kapsamı doğrular ve planını Göreve geri yazar. Kişi planı okur ve SH-312'yi Backlog'dan hazır bir duruma taşır; başlama sinyali budur.
3. Çalıştır. Ajan Görevi üstlenir ve yeni bir worktree'de çalışır. Düzeltmeyi yazar, typecheck ve test paketini çalıştırır ve başlığında SH-312 geçen bir pull request açar; böylece Sharkly PR'ı Göreve bağlar.
4. Kapıda dur. Ajan merge etmez. Değişiklik özetini, geçen test çıktısını ve bilinen kısıtları ekler, ardından SH-312'yi insan incelemesi bekler hâlde bırakır. İş Göreve geri dönmüştür.
5. İncele. Bir kişi SH-312'yi açar, diff'i ve kanıtları tek bir görünümde okur ve düzeltmenin paylaşılan bir sorgu yardımcı fonksiyonuna dokunduğunu fark eder. Daha dar kapsamlı bir değişiklik isteyen bir yorum bırakır. Hazır bir Ajan Atananı olan bir Görevde bu yorum, çalıştırmayı yeniden kuyruğa alır; böylece değişiklik talebi döngüsü özel bir sohbette yeniden başlamak yerine kayıtlarda kalır.
6. Kabul et ve merge et. İkinci çalıştırma incelemeden geçer. Kişi pull request'i onaylar, merge eder ve SH-312'yi Completed'a taşır. Merge işlemi Görevi otomatik olarak kapatmadığı için kabul ve merge, tek bir otomatik zincir değil, kayda geçmiş iki insan kararıdır.

Bu zincirdeki her adım daha sonra incelenebilir; izlenebilir bir gereksinimden koda iş akışının amacı da budur: birinin terminal geçmişinde kazı yapmadan “bunu kim, hangi kanıta dayanarak onayladı” sorusunu yanıtlayabilirsiniz.

Kapıyı nereye koymamalı

Daha fazla kapı otomatik olarak daha güvenli değildir; insanları tıklayıp geçmeye alıştıran bir sürtünme yaratır. Kapıyı, yanlış bir merge'ün maliyetinin gerçek olduğu yere koyun. Tek bir Ajana atanmış küçük, iyi tanımlanmış ve düşük riskli bir değişiklik için merge öncesi inceleme durağı yeterlidir; üstüne bir Crew ya da ek onay adımları eklemenize gerek yoktur. Etki alanı büyük olduğunda incelemeyi ağırlaştırın: paylaşılan kod, migration'lar, kimlik doğrulamaya veya faturalandırmaya dokunan her şey.

Asla kaldırmayacağınız tek kapı merge kapısıdır. Bir Ajan gün boyu araştırabilir, yazabilir, test edebilir ve öneride bulunabilir. Değişikliğinin ana dalınıza ulaşıp ulaşmayacağı bir insan kararıdır ve Ajan çoğu zaman haklı olsa bile bu böyle kalmalıdır. Sharkly'nin görev düzeyindeki incelemesini mevcut branch protection ayarlarınızla birleştirin ki platform, iş akışının amaçladığını uygulasın; ekibinizin hâlihazırda kullandığı araçları da koruyun: GitHub'ı bağlayın ve sürecinizi baştan kurmadan ticket'ı bir AI ajanına atayın.

Hâlihazırda birkaç kodlama ajanı çalıştırıyor ve hangisinin bittiğini, hangisinin başarısız olduğunu, hangisinin sizi beklediğini takip edemiyorsanız, Sharkly'yi denemenizin sebebi o inceleme sütunudur. Mevcut ajanlarınızı onun üzerinden çalıştırın ve merge kararını ait olduğu yerde tutun.

SSS

Sharkly bir ajanın kendi başına merge etmesini engelleyebilir mi? Evet. Bir pull request'in merge edilmesi Sharkly'de Görev durumunu değiştirmez; bu yüzden bir çalıştırma, değişikliği canlıya almak yerine “insan incelemesi bekleniyor” noktasında sona erer. Bunu, depo düzeyinde zorunlu incelemeleri uygulamak için GitHub branch protection ile birleştirin.

Görev durumu ile ajan durumu arasındaki fark nedir? Görev durumu, yaşam döngüsü kategorisidir (Backlog, Started, Completed vb.). Ajan durumu ise çalıştırmanın şu anda ne yaptığıdır: çalışıyor, insan yanıtı bekliyor, inceleme bekliyor veya hata. Bir Görev In Progress'te beklerken Ajan sizi bekliyor olabilir.

İncelenen her görev için bir Crew'e ihtiyacım var mı? Hayır. Küçük ve kapsamı net işlerde Görevi tek bir Ajana atayın ve merge öncesi inceleme kapısını kullanın. Crew'i, birkaç üyeyi koordine edecek bir lider Ajana ihtiyaç duyan hedefler için saklayın.