Gerçek bir görev için bir kodlama ajanını başlatıyorsunuz, dizüstü bilgisayarı kapatıp öğle yemeğine çıkıyorsunuz. Kolay kısım bu. Zor kısım ise geri döndüğünüzde bulduğunuz şey: başından itibaren ekrandan kaymış bir terminal, yazılışını izlemediğiniz bir diff ve önemli olan tek soruya net bir cevap olmaması: İş, tutulmaya değer kadar iyi mi?
Bir ajanı gözetimsiz çalıştırmanın iki yarısı var ve çoğu kurulum yalnızca ilkini çözüyor. İlk yarı, kimse izlemezken süreci canlı ve üretken tutmaktır. İkinci yarı ise inceleme kuyruğu: geri döndüğünüzde insan kararı bekleyen tamamlanmış, yarım kalmış ve başarısız çalıştırmalar yığını. İkinci yarıyı atlarsanız gözetimsiz ajanlar, darboğazı kod yazmaktan olanları yeniden kurgulamaya taşımaktan başka bir şey yapmaz.
Bu makale her iki yarıyı da ele alıyor: gözetimsiz bir çalıştırmayı kendiniz nasıl kuracağınız, her adımdaki hata modu ve bu kendin-yap kurulumunun nerede ölçeklenmeyi bıraktığı. Bir terminal beşe çıktığında, Sharkly gibi bir görev panosu kodlama ajanlarınızın üzerinde konumlanır. İşi yapmaya Claude Code, Codex veya Gemini CLI devam eder; Sharkly ise görevi, çalıştırmayı ve incelemeyi, çoktan kapattığınız terminallere dağılmak yerine tek bir yerde tutar.
Gözetimsiz ajan çalıştırmak gerçekte neyi kapsar
Gözetimsiz çalıştırma, aktif olarak izlemediğiniz bir makinede bir kodlama ajanının bir görevi yürütmesi ve çıktısının sonradan incelenmek üzere kaydedilmesidir. Bu tanımın yük taşıyan üç parçası var: ajanın siz olmadan bitirebileceği bir görev, bağlantınız koptuğunda çalışmaya devam eden bir makine ve sonrasında okuyabileceğiniz bir kayıt.
İnsanların hafife aldığı kısım kayıttır. Bir ajanı canlı izlerken log sizsiniz: yanlış dosyayı seçtiğini görürsünüz, araya girersiniz, rotayı düzeltirsiniz. Gözetimsizde bunların hiçbiri olmaz. Ajanın yaptığı her şey, saatler sonra, ne istediğinizi hiç hatırlamadan soğukkanlılıkla inceleyebileceğiniz bir biçimde ayakta kalmalıdır. Ajanlar araştırır, yürütür, test eder ve raporlar. İnsanlar yön belirler, yetki verir ve sonucu kabul eder. Bu sözleşme ancak geri döndüğünüzde rapor gerçek ve eksiksizse geçerli olur.
Yani amaç “ajanı bensiz çalıştırmak” değil. Amaç, “ajanı bensiz çalıştırmak ve bana inceleyebileceğim bir şey bırakmasını sağlamak.” Bunlar farklı problemler ve gözetimsiz iş akışlarının genellikle kırıldığı nokta ikincisidir.
Gözetimsiz bir çalıştırmayı kendiniz kurma
İşte her adımda sizi ısıran hata moduyla birlikte asgari manuel sürüm.
1. adım: işi izole edin. Çalıştırmaya kendi checkout'unu verin ki editörünüzle veya başka bir ajanla çakışmasın.
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
Hata modu: bunu atlarsanız aynı dizindeki iki çalıştırma birbirinin commit'lenmemiş değişikliklerinin üzerine yazar. İzolasyon sınırının neden tek başına branch'ler değil de worktree'ler olduğunu görmek için görev başına tek checkout yazısına bakın.
2. adım: süreci ayırın. SSH oturumunuz veya terminaliniz kapanacak ve ön planda çalışan bir süreç onunla birlikte ölecek (SIGHUP). Süreci nohup ya da bir tmux oturumuyla canlı tutun:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
Hata modu: düz bir ön plan kabuğunda çalıştırırsanız kapağı kapatmak, çok dosyalı bir düzenlemenin ortasında ajanı öldürür ve geride bozuk bir ağaç bırakır. nohup yaşam süresini düzeltir ama geri dönmenin bir yolunu sunmaz; tmux ise yeniden bağlanıp neler olduğunu görmenizi sağlar.
3. adım: her şeyi kaydedin. Yukarıdaki > run.log 2>&1 isteğe bağlı değil. En ham haliyle inceleme kuyruğu odur.
Hata modu: kaydedilmiş bir log olmadan “neden durdu?” sorusunu yanıtlayamazsınız. En yaygın sessiz takılma, kimsenin yanıtlamayacağı etkileşimli bir istemde sonsuza kadar bekleyen bir ajandır; çünkü gözetimsiz, “evet” yazacak kimsenin olmaması demektir. Etkileşimsiz bir modda çalıştırın ve görevin ihtiyaç duyduğu dar eylem kümesini önceden onaylayın.
4. adım: etki alanını sınırlayın. Oradan ayrılmadan önce ajanın kendi başına neleri yapabileceğine ve nelerin size ihtiyaç duyduğuna karar verin. Dosya kapsamını kısıtlayın, force-push'u yasaklayın ve gözetimsiz bir çalıştırmanın korumalı bir branch'e merge etmesine asla izin vermeyin.
Hata modu: doğrudan main'e push eden aşırı yetkili bir çalıştırma, verimlilik kazancı değil bir olaydır. Onay kapıları, ajanın son güvenli noktada durup beklemesi için vardır.
5. adım: ne zaman ve nasıl bittiğini bilin. Çıkış kodunu kontrol edin ve log'u elle yoklamamak için kendinize bir bildirim gönderin:
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
Hata modu: tamamlanma sinyali olmadan “gözetimsiz”, “terminali her yirmi dakikada bir kontrol ediyorum”a dönüşür; bu da fazladan gecikmeyle birlikte gözetimli çalışmaktan başka bir şey değildir.
Kendin-yap kurulumunun ölçeklenmeyi bıraktığı yer
Bir ajan, bir worktree, bir log dosyası: bu işe yarar ve tek bir çalıştırma için daha ağır bir şeye ihtiyacınız yok. Kurulum, birden fazlası olduğu anda bozulur.
Üç görevde üç ajan çalıştırın; artık üç worktree'niz, üç log dosyanız, üç çıkış kodunuz ve bir bakışta yanlış okuyacağınız üç tamamlanma e-postanız var. İzolasyon hâlâ geçerli. Dağılan şey inceleme kuyruğu. Hiçbir şey hangi çalıştırmanın temiz bittiğini, hangisinin testlerde başarısız olduğunu ve hangisinin sessizce bir istemde beklediğini söylemez. Bunu elle, log'ları tek tek okuyarak yeniden kurarsınız; ki bu tam da devretmeye çalıştığınız iştir.
Gerçek maliyet budur ve gözden kaçırması kolaydır çünkü her parça tek başına iyi görünür. Birkaç paralel çalıştırmayı izlemek, sayı bir ekranın gösterebileceğini aştığında gerçek bir sorun haline gelir. Bir log dosyası “bu çalıştırma ne yazdırdı” sorusunu yanıtlar, “altı çalıştırmamdan hangi üçü şu anda bana ihtiyaç duyuyor” sorusunu değil. Kaydedilmeye değer durum ve hata sinyalleri kendiliğinden bir kuyruk oluşturmaz. Kuyruk ise siz yokken çalışmanın bütün amacıdır: ham çıktı dizini değil, kararların sıralanmış bir listesini istersiniz.
Bir görev panosu neyi değiştirir
Sorunun ikinci yarısının çözüldüğü yer bir görev panosudur. Gözetimsiz çalıştırma yine bağladığınız bir Computer üzerinde gerçekleşir ve kodlamayı mevcut Runtime'ınız yapar. Değişen şey, sonucun nereye düştüğüdür.
Sharkly'de iş, çalıştırma ve inceleme tek bir Task üzerinde yaşar. Task'ı bir Agent'a atarsınız; bu, tekrar tekrar yazdığınız tek seferlik bir istem değil, talimatların, Runtime'ın ve depoların kaydedilmiş bir yapılandırmasıdır. Agent, Task'ı üstlenir, izole bir worktree'de çalışır ve yürütmesi, engelleri ve sonuçları Task zaman çizelgesine döner. Geri döndüğünüzde altı log dosyasını grep'lemezsiniz. Panoyu açar ve kuyruğu okursunuz: ne bitti, ne başarısız oldu, ne sizi bekliyor.
Bu, açıkça belirtilmeye değer sınır. Sharkly, Claude Code, Codex veya diğer yürütme araçlarının yerini almaz. Ekibinizin zaten kullandığı araçların etrafına paylaşılan görev, Computer, bağlam ve inceleme katmanını ekler. Kodu yine ajan yazar. Sharkly, siz yokken kodun değişiklik özeti ve test sonuçları ekli olarak görebileceğiniz bir yere döndüğünden ve nihai kabulün insan kararı olarak kaldığından emin olur. Otomasyon, muhakemenin gerektiği yerde durur.
Tüm bunları worktree'ler, nohup ve bir mail komutuyla elle kurabilirsiniz. Dürüst karar kuralı şu: ara sıra tek bir ajan çalıştırıyorsanız manuel kurulum yeterlidir ve Sharkly ihtiyacınız olmayan bir ek yüktür. Birkaç ajan görevler ve depolar arasında çalıştığında ve inceleme kuyruğu sabahınızı harcadığınız şey haline geldiğinde denklem değişir. Tek bir ekosisteme bağlanmak yerine birden fazla kodlama ajanı kullanmaya devam etmek istiyorsanız, Sharkly tam da bu kuyruk problemi etrafında tasarlandı.
Asıl darboğaz inceleme kuyruğu
Sorgulanmaya değer varsayım şu: insanlar gözetimsiz çalıştırmayı optimize edip incelemeyi sonradan akla gelen bir şey olarak görüyor. Bu ters. Siz uyurken ajanları paralel çalıştırmak, ancak ertesi sabah çıktılarını incelemek işi kendiniz yapmış olsaydınız harcayacağınızdan daha hızlıysa bir kazançtır. Beş ajan gece boyunca bitirdiğinde ve beş diff'in tamamını incelemek ikisini yazmaktan uzun sürdüğünde, paralellik hiçbir şey üretmemiştir.
O halde önce inceleme kuyruğunu tasarlayın. Bir çalıştırma size ulaşmadan önce “tamam”ın neleri içermesi gerektiğine karar verin: geçen testler, bir typecheck, bir değişiklik özeti ve bilinen sınırlara dair bir not. Kuyruğu bitiş zamanına göre değil riske göre sıralayın; böylece auth'a dokunan çalıştırma, bir yazım hatasını düzelten çalıştırmadan önce dikkatinizi alır. “Değişiklik iste”yi “onayla” kadar ucuz hale getirin, çünkü gözetimsiz çalıştırmaların yarısı neredeyse doğru ama tam doğru olmayacak. İnceleme, her paralel ajan iş akışında darboğazdır ve ajanların fiziksel olarak nerede çalıştığı — sunucunuzda, dizüstü bilgisayarınızda ya da her ikisinde — çıktılarının temizleyebileceğiniz bir kuyruk olarak gelip gelmemesinden çok daha az önemlidir.
Bugün uygulayabileceğiniz bir kontrol listesi
Bir ajandan uzaklaşmadan önce şunları doğrulayın:
- İzolasyon: çalıştırmanın kendi worktree'si var, sizin çalışma checkout'unuz değil.
- Yaşam süresi: süreç bir bağlantı kopmasına dayanır (
nohup,tmuxveya yönetilen bir Computer), böylece kapağı kapatmak onu düzenleme ortasında öldürmez. - Kayıt: stdout ve stderr, soğukkanlılıkla okuyabileceğiniz kalıcı bir log'a veya bir Task zaman çizelgesine gider.
- Etkileşimsizlik: ajan, yanıtlayacak kimsenin olmadığı bir istemde takılıp kalmaz.
- Etki alanı: dosya kapsamı sınırlı, force-push kapalı ve hiçbir gözetimsiz çalıştırma korumalı bir branch'e merge etmiyor.
- Tamamlanma sinyali: yoklama yapmadan, ne zaman bittiği ve geçip geçmediği size bildirilir.
- İnceleme sözleşmesi: tamamlanan her çalıştırma testler, bir değişiklik özeti ve bilinen sınırlarla gelir ve kabul etme sizde kalır.
İlk altısı çalıştırmayı gözetimsiz yapar. Sonuncusu ise yapmaya değer kılar. Hâlihazırda birkaç ajan çalıştırıyorsanız ve zamanınız sabah incelemesine gidiyorsa, mevcut kodlama ajanlarınızı Sharkly üzerinden çalıştırın; böylece kuyruk dağınık halde değil, düzenli olarak size gelsin.
