Bir kodlama ajanı, siz kahvenizi alırken bir ticket'ı pull request'e çevirebilir. Ama bu hız, araçların sizin adınıza hiçbir zaman yanıtlamadığı daha sessiz bir soruyu da beraberinde getirir: diff ortaya çıktığında onun sahibi kim? Onu kimin yazdığı değil — onu ajan yazdı. Asıl soru şu: yayına girip girmeyeceğinin, doğru değişiklik olup olmadığının ve gece 2'de bozulduğunda ne olacağının hesabını kim verecek? Yürütme ajana geçti. Sahiplik geçmedi ve geçemez de.
Birden fazla ajan çalıştırmaya başladığınız anda bu bulanıklık daha da artar. Bir hatayı Claude Code'a, diğerini Codex'e verin: elinizde iki branch, iki özet ve basit bir soruya ortak bir yanıt yoktur: bunlar merge edildiğinde her birinin üzerinde kimin adı yazacak? Terminal scrollback'inde yaşayan bir sahiplik, sahiplik değildir. Bir sonraki git log'a kadar dayanan bir tahminden ibarettir.
İşte Sharkly tam da bu sorunun etrafında kurgulandı. Sharkly, kodlama ajanlarınızın üzerinde konumlanır; işi kimin atadığını, hangi ajanın çalıştırdığını, sonucu kimin incelediğini ve kimin kabul ettiğini kaydeden katman olarak çalışır. Bu yazı, söz konusu işletim modelini dört rol ve bir dizi durum üzerinden ortaya koyuyor, ardından tek bir ticket'ı atamadan merge edilmiş bir PR'a kadar adım adım izliyor. Bunun altındaki inceleme mekaniği için human-in-the-loop kodlama ajanları rehberimiz, bu kararları uygulayan beş kapıyı ele alıyor.
TL;DR
Ajan işlerinde insan sahipliği, bir değişikliğin hesap verebilirliğinin — yürütme ajana geçmiş olsa bile — asla ajana devredilmediği anlamına gelir. İşletim modeli dört rolden oluşur: işi bir kişi atar, bir Ajan çalıştırır, adı belli bir insan inceler ve aynı kişi kabul eder. Ajanlar bir görevi en fazla Ready for review'a kadar taşıyabilir; Done'a yalnızca bir insan taşır. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder.
Bir ajanın ürettiği işin sahibi kim
Sahiplik ile yürütme iki farklı iştir ve bu ikisini karıştırmak, asıl hatanın kökenidir. Yürütme, değişikliği üretmektir: kod tabanını okumak, dosyaları düzenlemek, testleri çalıştırmak, PR açmak. Bir ajan bunu hem iyi hem hızlı yapar. Sahiplik ise sonuçtan sorumlu olmaktır: değişikliğin yapmaya değer olduğundan, kabul kriterlerini karşıladığından ve üç ay sonra bunun hesabını sorabileceğiniz birinin bulunduğundan emin olmak. Bu sorumluluk bir insanda kalır; çünkü bir ajandan iş bittikten sonra bir ödünleşimi gerekçelendirmesi ya da sonuçlarına katlanması istenemez.
Bu ayrımı en net biçimde insan-ajan sözleşmesi ortaya koyar: 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. "Sonucu kabul etme"ye kadar olan her şey bir ajana devredilebilir. Kabulün kendisi devredilemez; sürüm kararı da öyle. AI assistants vs AI teammates yazımız da aynı çizgiyi diğer yönden çizer.
İşletim modeli: ata, çalıştır, incele, kabul et
Sahipliği yürütmeden ayırdığınızda, iş akışı her biri tek bir işten sorumlu dört role ayrılır. Bu rolleri adlandırmak, beş paralel ajanın beş sahipsiz branch'e dönüşmesini engelleyen şeydir.
| Adım | Kim harekete geçer | Neyin sahibi |
|---|---|---|
| Ata | Bir kişi | İşin yapmaya değer olduğuna karar vermek, kabul kriterlerini yazmak ve hesap verecek kişiyi belirlemek |
| Çalıştır | Bir Ajan; bir Bilgisayar üzerindeki bir Runtime aracılığıyla | Değişikliği üretmek, testleri çalıştırmak ve ne yaptığını, neyin belirsiz kaldığını raporlamak |
| İncele | İnsan sorumlu | Sonucu kabul kriterlerine ve kanıtlara göre değerlendirmek |
| Kabul et | Aynı insan sorumlu | Merge ve sürüm kararı |
Önemli ayrıntı ilk ve son satırda: atamayı da kabulü de aynı kişi sahiplenir. Döngü böyle kapanır. İşin önemli olduğuna karar veren kişi, onun yapıldığını onaylayan kişidir. Sharkly bunu, bir görev üzerinde aynı anda iki atama alanı tutarak destekler: bir insan sorumlu ve bir ajan sorumlu. Böylece sorumluluk ile yürütme, tek ve belirsiz bir "şuna atandı" ifadesi yerine ayrı olgular olarak kaydedilir. İşin ajana nasıl ulaştığını merak ediyorsanız, ajan işlerini tek yerden atama, izleme ve inceleme rehberimize göz atın.
Durumlar ve kapılar: ajanlar Ready for review'a kadar gelir, işi Done'a insanlar taşır
İşletim modeli, görev durumlarına eşlendiğinde gerçeklik kazanır; çünkü bir durum değişikliği, sonradan işaret edebileceğiniz bir karardır. Buradaki kural katıdır ve açıkça dile getirilmeye değer: ajanlar işi en fazla Ready for review'a kadar ilerletebilir; bir görevi Done'a yalnızca bir insan taşır.
| Durum kategorisi | Kim taşır | Anlamı |
|---|---|---|
| Backlog | İnsan | Başlanmadı. Bu aşamada bir ajan atamak hiçbir şeyi çalıştırmaz |
| Ready for work | İnsan | Bir görevi bu kategoriye taşımak, ajan çalışmasını başlatan şeydir |
| In progress | Ajan | Çalışma, izole bir worktree içinde yürütülüyor |
| Ready for review | Ajan | Çalışma tamamlandı ve adı belirtilen insanı bekliyor |
| Done / Accepted | İnsan | Bir insan kanıtları okudu ve sonucu kabul etti |
Bu modeli iki sınır korur. Birincisi, bir ajan Task Workflow'unun kendisine tanımadığı bir durumu seçemez; dolayısıyla kendi işini kabul edildi olarak işaretleyemez. Görevi insan incelemesi bekleyecek şekilde bırakır ve bu sinyal, kimsenin okumadığı bir kanala değil, sorumlu kişinin Gelen Kutusu'na düşer. İkincisi, bağlantılı bir pull request'in merge edilmesi görev durumunu değiştirmez. Merge bir Git olayıdır, bir kabul kararı değildir; Sharkly bu ikisini ayrı tutar, böylece "PR merge edildi" hiçbir zaman "bir insan bunu doğru buldu" ile karıştırılmaz. İnceleme kapasitesi sizi endişelendiriyorsa, insan incelemesi neden asıl darboğazdır analizimiz bunun için nasıl tasarım yapılacağını ele alıyor.
Ticket'tan merge edilmiş PR'a: işlenmiş bir örnek
İşte modelin tek bir görev, SH-312, üzerinde baştan sona işleyişi: "Herkese açık arama uç noktasına rate limiting ekle."
- Ata. Bir mühendis görevi yazar: uç nokta, hedef limit ve kabul kriterleri (limit aşıldığında 429, mevcut testler hâlâ geçiyor, limit için yeni bir test). Kendini insan sorumlu olarak atar ve ajan sorumluyu seçer. Görev Backlog'da bekler. Henüz hiçbir şey çalışmaz.
- Çalıştır.
SH-312'yi bir Ready for work durumuna taşır. Çalışmayı başlatan şey bu durum değişikliğidir. Ajan görevi üstlenir, bu işin başka hiçbir şeyle çakışmaması için temiz bir worktree hazırlar, açıklamayı ve son yorumları okur, uç noktayı düzenler, testi ekler ve test paketini çalıştırır. - Raporla. Ajan bir pull request açar ve göreve bir yorum bırakır: değişiklik özeti, çalıştırdığı testler ve sonuçları ve gerçek trafik altında limiti yük testine tabi tutmadığına dair dürüst bir not.
SH-312'yi Ready for review'a taşır. Orada durur. Daha ileri gidemez. - İncele. İnceleme bekleniyor sinyali mühendisin Gelen Kutusu'na ulaşır. Şu sırayla okur: kabul kriterleri, ajanın yorumu, yürütme günlüğü ve son olarak diff. Günlük, çalışmanın neden kuyruğa alındığını ve hangi araç çağrılarının yapıldığını gösterir; böylece mühendis, değişikliğe dair anlatılan bir hikâyeyi değil, değişikliğin kendisini inceler. Yük testi eksiği gerçektir; bu yüzden belgelenen üst sınırda bir test isteyen bir yorum bırakır. Bu yorum, aynı ajan için bir takip çalışmasını kuyruğa alır; mühendis ikinci bir görev açmaz.
- Kabul et. Ajan testi ekler, yeniden raporlar ve görevi Ready for review'a döndürür. Bu kez kanıtlar kriterlerle örtüşür. Mühendis PR'ı merge eder ve
SH-312'yi Done'a taşır — işin en başından sahibi olan kişinin iki bilinçli eylemi.
Her adım göreve geri döner: çalışma, PR bağlantısı, inceleme yorumları, kabul. Hiçbir şey yalnızca bir terminalde yaşamaz. AI tarafından üretilen kodu görev düzeyinde kanıtlarla inceleme rehberimiz, kabul etmeden önce neyi okumanız gerektiğini daha derinlemesine ele alıyor.
Sahiplik nerede sessizce kırılır
Her görevde bu törenin tamamına ihtiyacınız yok; aksini iddia etmek incelemeyi tiyatroya çevirir. İş salt okunur olduğunda ya da kolayca geri alınabildiğinde hafif sürümü kullanın: bir depo denetimi veya testleri yeşil olan bir bağımlılık güncellemesi, çalıştırmadan doğrudan hızlı bir kabule geçebilir. Bir değişiklik veriye dokunuyorsa, herkese açık bir arayüzü değiştiriyorsa ya da tek bir komutla geri alınamıyorsa, her iki ucunda adı belli bir insanın olduğu dört rollü döngünün tamamını kullanın.
Dikkat etmeniz gereken başarısızlık biçimi, ajanların çok fazla iş yapması değil. Sahipliğin atanmamış kalmasıdır. Ajan sorumlusu olup insan sorumlusu olmayan bir görev, hesap verebilirlikten yoksun bir yürütmedir: ilerleme kılığına girmiş sahipsiz branch sorunu. Çözüm, her yerde geçerli tek bir kuraldır: her ajan görevi, onu sahiplenen bir insanı adıyla belirtir. Birden fazla ajan arasındaki devirleri koordine ediyorsanız, ajandan ajana ve ajandan insana devir kalıpları rehberimiz insan sahibinin zincirde nerede durduğunu gösteriyor.
Sonuç
Ajan işlerinde insan sahipliği, otomasyonu frenleyen bir şey değildir. Otomasyonu güvenle ölçeklendirilebilir kılan şeydir. Bırakın yürütmeyi ajanlar yapsın; tümünü, çıkabildikleri hızda yapsın. Dört kararı insanlarda tutun: neyin atanacağı, çalıştırma yetkisinin verilip verilmeyeceği, sonucun çıtayı karşılayıp karşılamadığı ve sürüme çıkıp çıkmayacağı. Bu kararları ortak bir görev üzerindeki durum değişiklikleri olarak kaydedin; böylece hesap verebilirlik, birinin scrollback'inde kalan bir tahmin değil, herkesin okuyabileceği bir olgu olur.
Hâlihazırda birden fazla kodlama ajanı çalıştırıyorsanız, Sharkly işlerini atamak, çalışırken izlemek ve her sonucu kimin inceleyip kabul ettiğini kaydetmek için tek bir yer sunar. Bu modeli worktree'ler ve bir elektronik tabloyla elle de kurabilirsiniz ya da Sharkly'yi indirip görevin bunu taşımasına izin verebilirsiniz. Katmanın bütününü görmek için Claude Code ve Codex üzerinde kodlama ajanı yönetimi yazısıyla başlayın.
SSS
İnsan sahipliği, bir kişinin her ajan çalışmasını izlemesi anlamına mı gelir? Hayır. Sahiplik gözetim değil, hesap verebilirliktir. İşi bir kişi atar ve sonucu kabul eder; ajan aradaki süreçte gözetimsiz çalışır. Zaten bir terminali izlemek, tek ajanın ötesine ölçeklenmez.
Bir ajan kendi işini tamamlandı olarak işaretleyebilir mi? Hayır. Bir ajan görevi Ready for review'a kadar ilerletebilir, ancak Task Workflow'u ona kabul edildi durumunu tanımaz. Kanıtları bir insan okur ve görevi Done'a taşır.
Pull request'i merge etmek görevi kabul etmek anlamına mı gelir? Hayır. Bağlantılı bir PR'ı merge etmek bir Git olayıdır ve Sharkly'deki görev durumunu değiştirmez. Kabul, incelemenin ardından insan sahibinin yaptığı ayrı bir durum değişikliğidir.
Bir ajanın görevinin sahibi kim olmalı? İşin yapmaya değer olduğuna karar veren kişi. Sharkly, ajan sorumlusunun yanında bir insan sorumlu alanı tutar; böylece inceleme sinyali o kişiye yönlendirilir ve kabulü o yapar.
Hiçbir insan atanmazsa ne olur? Hesap verebilirliği olmayan bir yürütme elde edersiniz. Güvenli kural şudur: her ajan görevi bir insan sahibi belirtir; böylece tamamlanan bir çalışmanın her zaman hesabını verecek biri olur.
