Bir terminal ve Claude Code ile başlıyorsunuz. Sonra ikinci bir görev geliyor, ikinci bir terminal açıp Codex'i onun üzerinde başlatıyorsunuz. Bir frontend düzeltmesi üçüncüsüne gidiyor. Derken üç pencere arasında Alt+Tab yapıp hangisinin sizden bir şey beklediğini, hangisinin on dakika önce bir soru sorduğunu ve hangisinin sessizce işini bitirip diğer ikisine dikkat harcarken boş boş beklediğini hatırlamaya çalışıyorsunuz. Ortada yanan bir şey yok. Ama artık ajanlar arasında işi yönlendiren şey sizsiniz ve bu iş, ajanların hiçbirinden daha kötü ölçekleniyor.
Maliyet terminaller değil. Sizsiniz. Ajanlar elle çalıştığında, sırada ne olacağına dair her karar tek bir yerde yaşar: kafanızın içinde. Sıradaki görevi hangi ajan alacak, son diff güvenli mi, siz başka bir pencereyi okurken ne başarısız oldu. Bu koordinasyon gerçek bir iştir, karşılığı ödenmez ve eklediğiniz ajan sayısından daha hızlı büyür.
Bu makale, kodlama ajanlarını elle çalıştırmanın gerçekte neye mal olduğunu, faturanın birikene kadar nerede saklandığını ve bu maliyetin çoğunu ortadan kaldıran iş akışını ele alıyor. Sharkly, ajanlarınızın üzerinde duran yönetim katmanıdır: Claude Code'u, Codex'i ya da hâlihazırda kullandığınız hangi çalışma zamanı varsa onu korursunuz; Sharkly ise görevleri, izolasyonu ve incelemeyi bir terminal duvarına yaymak yerine tek bir paylaşılan yerde tutar.
TL;DR
Kodlama ajanlarını elle çalıştırmak bedava görünür, çünkü bunun için ücret alan bir araç yok. Gerçek maliyet dikkatinizdir: ajanlar arasındaki yönlendirici, her birinin ne yaptığının hafızası ve her pencereye yetişmek zorunda kalan tek inceleyici siz olursunuz. Bu maliyet iki üç ajanda küçük kalır, beşi geçince katlanarak artar. Elle yapmaya devam edebilir ya da mevcut ajanlarınızı, işi atayan, her çalıştırmayı izole eden ve her sonucu incelenmek üzere bir Göreve döndüren Sharkly gibi bir görev katmanından geçirebilirsiniz.
Sorun terminaller değil, sizsiniz
Akılda tutmaya değer bir tanım: terminal, ajanın çalıştığı yerdir; görev ise üzerinde çalıştığı iştir. Ajanları elle yönettiğinizde, ikisini birbirine bağlayan tek şey sizsiniz. Terminal çıktıyı gösterir. Görevin ne olduğunu, tamamlanıp tamamlanmadığını ya da sırada ne olacağına kimin karar verdiğini bilmez. Bütün bunları hafızanızdan, tek tek pencerelerden siz sağlarsınız.
İşte bu yüzden "çok fazla terminal" hastalığın kendisi değil, bir belirtidir. Bir ajanı tmux ile beş bölmeye dağıtmak koordinasyonu azaltmaz; yalnızca düzenler. Hangi bölmenin hangi göreve ait olduğu, hangisinin çalışmakta olduğu ve hangisinin bitip bir insanın bakması gerektiği haritası hâlâ sizdedir. Bu harita paylaşılan hiçbir yerde yaşamaz; siz uzaklaştığınız anda eskir ve bir ekip arkadaşının ona ihtiyaç duyduğu anda yoktur.
Ajanları elle çalıştırmak gerçekte neye mal olur
Fatura dikkatle ödenir ve dikkatin ölçülebilir bir bedeli vardır. İlgisiz görevler arasında geçiş yaptığınızda kaldığınız yerden anında devam edemezsiniz. Gloria Mark ve meslektaşlarının CHI 2008'de yayımlanan, kesintiye uğrayan bilgi işi üzerine araştırması, insanların bir işten koparıldıktan sonra kesintiye uğrayan göreve dönmesinin ortalama yirmi dakikadan fazla sürdüğünü ortaya koydu. American Psychological Association'ın görev değiştirme araştırması özeti ise görevler arasında geçiş yapmaktan kaynaklanan üretkenlik kaybını yüzde 40'a kadar çıkarıyor. Bir ajan her işini bitirdiğinde ve siz başka bir pencereye döndüğünüzde, bu verginin bir türünü ödersiniz.
Ajanları elle çalıştırmak, bu geçişi ana döngünüz hâline getirir. Maliyetin biriktiği yerler şunlar:
| Gizli maliyet | Elle çalıştırıldığında nasıl görünür | Neden katlanarak artar |
|---|---|---|
| Yönlendirme | Her yeni görevi hangi ajanın alacağına hafızanızdan karar verirsiniz | Daha fazla ajan, kafanızda tutmanız gereken daha fazla eşleştirme demektir |
| Bağlamı yeniden yükleme | Ne yaptığını hatırlamak için her terminali yeniden okursunuz | Her geçiş, o göreve geri dönme süresini baştan başlatır |
| Durum kayması | Her terminal kendi branch'ini, ortam değişkenlerini ve yarım kalmış düzenlemelerini taşır | Tek bir dizindeki iki görev sessizce birbirini bozar |
| Biriken inceleme | Her çalıştırmayı gerçekleşirken gören tek kişi sizsiniz | Bitmiş iş, onu inceleyebilecek tek kişiyi bekler |
| Paylaşılan kayıt yok | Durum sizin oturumunuzda yaşar, bir ekip arkadaşının görebileceği hiçbir yerde değil | Uzaklaşın, ilerleme görünmez olur; kimse işi devralamaz |
Bunların hiçbiri bir çökme olarak ortaya çıkmaz. Yoğun geçmiş gibi hissettiren ama sekiz yerine üç birleştirilmiş PR üreten bir gün olarak ortaya çıkar; sorun olarak işaret edebileceğiniz tek bir an yoktur.
Arıza modları, katlanarak büyüyene kadar gizlenir
İki ajanda, tüm haritayı kısa süreli bellekte tutabilirsiniz ve maliyet neredeyse sıfırdır. Bunu açıkça söylemek gerekir, çünkü çoğu tavsiye sorunu tam da burada abartır: tek bir makinede bir ya da iki ajan çalıştırıp bir sonrakini başlatmadan önce her birini inceliyorsanız, henüz bir yönetim katmanına ihtiyacınız yoktur. Hareketli parça sayısını sıfırda tutun.
Denklem, işler zaman veya durum açısından örtüşmeye başladığında değişir. Aynı checkout'ta üç ajan çalıştırırsanız, aynı depodaki birden fazla kodlama ajanı yazısında ele alınan izolasyon sorunuyla karşılaşırsınız: iki ajan aynı dosyalara dokunur ve biri diğerinin üzerine sessizce yazar. Bunu her görev için bir worktree ile, yani kodlama ajanı worktree'lerinde izlenen disiplinle çözersiniz ve bu kez bir birleştirme sorununu bir kayıt tutma sorunuyla değişirsiniz: hangi dizin hangi göreve karşılık gelir, hangisini silmek güvenlidir, hangisinin incelemesi bir insan tarafından sürdürülmektedir. Bunu daha fazla terminalle çözerseniz başladığınız yere dönersiniz, yalnızca daha fazla pencereyle.
Son maliyet sessiz olanıdır. Her çalıştırma özel bir terminalde gerçekleştiğinde, biten işin gidecek yeri sizin dikkatinizden başka bir yer değildir. İnceleme darboğaz hâline gelir, çünkü ajanın çalışmasını izleyen tek kişi sizsiniz ve diff'in iyi olup olmadığını söyleyebilecek tek kişi de sizsiniz. Ajanların çıktısını incelemek tek bir insanda sıraya giriyorsa, paralel ajanların bir faydası olmaz. En iyi kodlama ajanının neden onları nasıl yönettiğinizden daha az önemli olduğu yazısında anlatılan tuzak tam da budur: model hızlandı, ama inceleme kuyruğunuz hızlanmadı.
Yönetim katmanı neyi ortadan kaldırır
Bir görev panosu, elle yaptığınız kısmı ortadan kaldırır: ajanlarla iş arasındaki bağ dokusu olmayı. Sharkly'de çalıştırmayı sahiplenen birim Görev'dir. Bir Görevi bir Ajana atarsınız; Sharkly bağlı bir Bilgisayarda onun için izole bir worktree hazırlar, ajan oturumunu orada çalıştırır ve diff'i, günlükleri ve varsa engelleri o Göreve döndürür. Kafanızda tuttuğunuz yönlendirme, izolasyon ve kayıt böylece Görevin özellikleri hâline gelir.
Bu, iş bölümünü temiz tutar. Ajanlar araştırır, yürütür, test eder ve raporlar; insanlar yön belirler, yetki verir ve sonucu kabul eder. Sharkly, Claude Code'un, Codex'in ya da hâlihazırda kullandığınız çalışma zamanının yerini almaz; yürütmeyi onlar gerçekleştirir. Sharkly bunların etrafına paylaşılan görevi, bağlı Bilgisayarı ve inceleme katmanını ekler; böylece bağlam, ilerleme, engeller, sonuçlar ve insan incelemesi, yalnızca sizin görebildiğiniz beş oturuma dağılmak yerine talepten sürüme kadar görünür kalır. Aynı anda birkaç çalıştırmayı izlemeniz gerektiğinde, bir ajan kontrol paneli tam da bunun içindir ve ekiplerin neden bir terminal daha yerine Claude Code ile Codex'in üzerindeki katmanı istemeye başladığı da bu yüzdendir.
Zaten birkaç ajan çalıştırıyorsanız, Sharkly'nin üzerine kurulduğu iş akışı tam da budur. Terminaller arasında elle yönlendirmeye devam edebilir ya da mevcut kodlama ajanlarınızı Sharkly üzerinden çalıştırıp haritayı panonun tutmasına izin verebilirsiniz.
Elle yönetmek ne zaman sorun değil, ne zaman değil
Dürüst karar kuralı kısa:
- Ajanları elle çalıştırın: bir ya da iki ajanınız varsa, tek bir makinede ve bir sonrakini başlatmadan önce her birini inceliyorsanız. Herhangi bir aracın getireceği ek yük henüz buna değmez.
- Bir görev katmanına geçin: üçüncü bir ajan devreye girdiğinde, iş birden fazla depoya yayıldığında ya da sizden başka birinin nelerin çalıştığını görmesi gerektiğinde. Koordinasyon maliyetinin tek bir kişinin kafasına sığmamaya başladığı nokta burasıdır.
Sinyal, terminal sayısı değildir. Kendinizi "dur, o hangi penceredeydi?" diye sorarken yakaladığınız andır. Bu soru, koordinasyon vergisinin bir cümle olarak ortaya çıkmasıdır ve bir görev panosunun sona erdirmek için var olduğu ajan kaosunun ta kendisidir.
SSS
tmux ya da bir terminal çoklayıcı yeterli değil mi? Pencereleri düzenler; koordinasyonu ortadan kaldırmaz. Hangi bölmenin hangi göreve ait olduğu, neyin bittiği ve kimin inceleyeceği hâlâ sizde. Bir çoklayıcı ekran alanı sorununu çözer. Ajanları elle çalıştırmanın maliyeti piksel değil, dikkattir.
Canım yanmaya başlamadan önce elle kaç ajan çalıştırabilirim? Çoğu kişi bir ya da iki ajanda sorun yaşamaz, üç ile beş arasında bunu hissetmeye başlar; özellikle birden fazla depoya yayıldığında. Kesin sayı, her görevin ne kadar sürdüğüne ve her birinin ne kadar inceleme gerektirdiğine bağlıdır. İpucu, yönlendirme ve pencereleri yeniden okumanın gününüzün gerçek incelemeden daha büyük bir kısmını almaya başlamasıdır.
Bir görev panosu ajanlarımı hızlandırır mı? Hayır ve Sharkly bunu iddia etmiyor. Ajanlar aynı hızda çalışır. Değişen şey sizin ek yükünüzdür: yönlendirme, izolasyon ve inceleme artık kafanızda yaşamayı bırakıp işin görünür ve incelenebilir olduğu bir Göreve dönmeye başlar.
Oturumlar arasında bağlamı korumaya ne demeli? Özel terminaller, siz onları kapattığınız anda bağlamı kaybeder. Bir çalıştırmayı bir Göreve bağlamak, hedefi, diff'i ve tartışmayı bir arada tutar; bu da oturumlar arasında bağlamı koruma sorununun hafızayla değil, kayıt düzeyinde çözülmesi demektir.
Bu şekilde Claude Code ve Codex'i birlikte kullanmaya devam edebilir miyim? Evet. Sharkly araçların etrafındaki işi yönetir; araçların yerini almaz. Bu düzeni görmek için Claude Code ve Codex birlikte nasıl çalıştırılır yazısına bakın.
