Tek bir Codex ajanı çalıştırmak kolaydır. Bir terminal açarsınız, bir görevi tanımlarsınız ve çalışmasını izlersiniz. Sorunlar üçüncü ajanla başlar. Bir ajan auth modülünü yeniden düzenlerken, bir diğeri kararsız bir testi düzeltiyor, üçüncüsü bir migration taslağı hazırlıyor ve her biri kendi scrollback'ine sahip ayrı bir terminal sekmesinde yaşıyor. On dakika sonra hangi sekmede hangi görevin olduğunu, migration'ın bitip bitmediğini ya da test düzeltmesinin hangi branch'e düştüğünü hatırlayamazsınız. Ajanlarda sorun yok. Bozulan şey, sizin onları takip edebilme yeteneğiniz.
İşte "birden fazla Codex ajanını yönetmek"in arkasındaki gerçek sorun bu. Sorun eşzamanlılık değil; Codex ayrı çalışma dizinlerinde rahatça paralel çalışır. Sorun, bu işin durumunun — her ajanın ne yaptığı, neyin bittiği, neyin başarısız olduğu ve neyin incelemenizi beklediği — terminal sekmelerine, worktree klasörlerine ve kendi hafızanıza dağılması. Bunlardan birini kaybederseniz, ipin ucunu kaybedersiniz.
Sharkly tam da bu boşluk için var. Kodlama ajanlarınız zaten var; Sharkly her ajan çalışmasına tek bir paylaşılan kayıt vererek onları bir ekibe dönüştürür. Bu makale önce manuel kurulumu ele alıyor, çünkü neyi otomatikleştirdiğinizi anlamalısınız; ardından bir görev panosunun nerede hak ettiği yeri bulduğunu gösteriyor. Sonunda bugün uygulayabileceğiniz bir kontrol listesi olacak.
"Takibi kaybetmek" gerçekte ne anlama gelir
Takibi kaybetmek belirsiz bir şey değildir. Belirli bir başarısızlıktır: iş durumunuzun tek bir evi yoktur. Birkaç Codex oturumunu elle çalıştırdığınızda, her görevle ilgili gerçek aynı anda dört yere bölünür. Talimat, yazdığınız terminalde yaşar; değişiklikler bir Git çalışma dizininde yaşar; durum kafanızda yaşar; sonuç ise henüz açmadığınız bir pull request'te yaşar. Bu dördünü senkron tutan hiçbir şey yoktur. Terminali kapatın, talimat gider. Sekme değiştirin, durum bir tahminden ibarettir. Ne kadar çok ajan eklerseniz, "ne oluyor"un o kadar çok kopyasını tutarsınız ve bunları bir arada tutan tek entegrasyon noktası sizsinizdir.
Yani birden fazla Codex ajanını yönetmenin amacı dar ve açıkça ifade etmeye değer: her ajanın görevini, ilerlemesini, değişikliklerini ve inceleme durumunu özel terminal oturumlarına bölmek yerine tek bir yerde tutmak. Aşağıdaki her şey bu tek ölçüte göre değerlendirilir.
Adım 1: Her ajanı bir worktree ile izole edin
İlk başarısızlık modu çakışmadır. İki Codex ajanını aynı klasöre yönlendirin; birbirlerinin düzenlemelerinin üzerine yazarlar, birbirlerinin dosyalarını stage ederler ve kimsenin okuyamayacağı bir diff üretirler. Git worktree'leri bunu temiz bir şekilde çözer: her ajana aynı deponun kendi branch'inde kendi checkout'unu verir.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
Şimdi her dizinin içinde bir Codex oturumu başlatın. Her ajan yalnızca kendi dosyalarını görür, kendi branch'ine commit yapar ve diğerlerinin alanına giremez.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
Burada adlandırılması gereken başarısızlık modu: worktree'ler dosya çakışmalarını çözer, takibi çözmez. Artık neredeyse aynı isimlere sahip üç klasörünüz var ve hangisinin hangi görevi tuttuğuna dair hiçbir kayıt yok. Görevi kodlayan bir adlandırma kuralı benimseyin (agent/<task>), çünkü bir hafta sonra repo-2 ve repo-3 hiçbir şey ifade etmez. Daha derin mekanikleri istiyorsanız, yapay zeka kodlama ajanları için Git worktree'leri ve birden fazla Codex görevini aynı anda çalıştırma yazılarındaki daha geniş desene bakın.
Adım 2: Oturumları görünür tutun
Üç sekmede üç ajan, yanlışlıkla bir Cmd+W'ye basıp çalışan bir görevi öldürmenizden ve scrollback'ini kaybetmenizden bir adım uzaktasınız demektir. tmux gibi bir terminal multiplexer, her oturumu adlandırılmış pencerelerde canlı tutar; bunlardan ayrılıp daha sonra yeniden bağlanabilirsiniz.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
Adlandırılmış pencereler (auth, flaky, migration), ham bir sekmenin çöpe attığı etiketi geri getirir. Ctrl-b d ile ayrılın, dizüstünüzü kapatın, sabah yeniden bağlanın; oturumlar hâlâ orada.
Burada adlandırılması gereken başarısızlık modu: tmux oturumları çalışır durumda tutar; hangilerinin size ihtiyacı olduğunu söylemez. Yirmi dakika önce biten bir ajanla hata almış bir ajan dışarıdan aynı görünür: sessiz bir pencere. Durumunu öğrenmek için yine her pencereyi ziyaret edip son yüz satırı okumanız gerekir. Bu yoklama maliyeti, eklediğiniz her ajanla büyür ve manuel kurulumun zamanla daha ağır hissettirmesine yol açan vergidir.
Adım 3: Durumu ve incelemeyi kalıcı bir yere kaydedin
Son manuel parça, insanların atladığı parçadır: her ajanın ne ürettiğini ve kabul edip etmediğinizi yazmak. Scrollback bir kayıt değildir. Kaybolur, görevler arasında aranabilir değildir ve bir ekip arkadaşı onu okuyamaz. Hafif sürümü, elle güncellediğiniz düz bir kontrol listesidir.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
İşin tamamı minyatür haliyle budur: ilerlemenin, engellerin, sonuçların ve insan incelemesinin talepten sürüme kadar görünür kaldığı kalıcı bir yer. Bunu sadakatle tutarsanız, uzun süre bir terminalden birkaç ajanı yönetebilirsiniz. İşin püf noktası, senkron motorunun siz olmanız ve her şey değiştiğinde onu elle güncellemenizdir. Ajan çıktısını denetlenebilir kılmak hakkında daha fazlası için yapay zeka kodlama ajanlarının tamamladığı işler nasıl takip edilir yazısına bakın.
Kendin-yap kurulumunun ölçeklenmeyi bıraktığı yer
Manuel yaklaşımın ne zaman yeterli olduğu konusunda dürüst olun. İyi kapsamlandırılmış görevlerde bir veya iki Codex ajanı için worktree'ler artı bir adlandırma kuralı artı elle tutulan bir durum dosyası gerçekten yeterlidir. İhtiyacınız olmayan araçları eklemeyin; hareketli parçalar neredeyse sıfırdır ve her şey kafanıza sığar.
Denklem öngörülebilir bir noktada değişir. Bunu şu durumlarda hissedersiniz:
- Üç veya daha fazla ajan çalıştırıyorsunuz ve yoklama maliyeti (her pencereyi ziyaret et, sonunu oku, durumu hatırla) ajanların kazandırdığından daha fazla zaman yiyor.
- İş birden fazla depoya yayılıyor, dolayısıyla worktree'ler tek başına artık tek ve temiz bir resim oluşturmuyor.
- Başka biri "ajanlar şu anda ne yapıyor?" diye soruyor ve tek dürüst cevap terminalinizde ve hafızanızda yaşıyor.
Bunların her biri, makalenin başındaki aynı kök nedene dayanır: paylaşılan bir evi olmayan iş durumu. Manuel kurulum bunu ölçeklenmeyen tek yerde, yani sizde tutar. Ekipler bu duvara en hızlı çarpar; bu yüzden paralel yapay zeka kodlama ajanlarını yönetmek için en iyi araçlar hep aynı hamlede buluşur: işe terminalin dışında bir ev verin.
Bir görev panosu ne katar
Bir görev panosu, yönetim birimini "bir terminal oturumu"ndan "bir Task"a değiştirir. Sharkly'de, Codex'i zaten çalıştırdığınız Computer'ı bağlar, ardından bir pencereye yazmak yerine bir Task'ı bir Codex Agent'ına atarsınız. Agent kendi izole worktree'sinde çalışır ve yürütme, ilerleme, engeller ve sonuçlar Task'a döner. Yoklamayı bırakırsınız; pano neyin bittiğini ve neyin başarısız olduğunu zaten bilir.
İş bölümü kasıtlıdır ve bir sınır olarak ifade etmeye değer: Sharkly, Codex'in yerini almaz. Yürütmeyi Codex yapar. Sharkly bunun etrafına paylaşılan görev, Computer, bağlam ve inceleme katmanını ekler. Ajanlar araştırır, yürütür, test eder ve raporlar; insanlar yön belirler, yetki verir ve sonucu kabul eder. Otomasyon, yargınızın gerektiği yerde, yani kodda değil inceleme kapısında durur.
Manuel durum dosyasının peşinde olduğu şey buydu; kalıcı ve paylaşılan hale getirilmiş hali. Terminalin size veremeyeceği üç şey bundan doğar:
- Yoklama olmadan durum. Her Task, siz bir pencereyi ziyaret etmeden çalışıyor, bitti, engellendi veya inceleme bekliyor durumunu gösterir.
- Depolar arası tek resim. Birçok depodan ve birçok Agent'tan gelen Task'lar tek bir Space'te oturur; böylece daha fazla ajan, bakmanız gereken daha fazla terminal anlamına gelmez. Ekiplerin Claude Code ve Codex'i birlikte çalıştırmasının nedeni de aynıdır: tek bir yerden.
- Tutan bir inceleme adımı. Sonuçlar, değişiklik özeti ve kanıtları ekli halde bir insan denetimindeki kapıda bekler; böylece beklediğini unuttuğunuz için hiçbir şey merge edilmez.
Bunların hepsini worktree'ler ve disiplinle elle kurabilir ya da ajan sayısı arttığında iş akışını yönetmek için Sharkly'yi kullanabilirsiniz. Codex olduğu gibi kalır; yönetim omuzlarınızdan iner. Zaten birkaç Codex ajanı çalıştırıyorsanız, Sharkly'nin etrafında tasarlandığı sorun tam da budur.
Bugün uygulayabileceğiniz kontrol listesi
Manuelde kalsanız da bir panoya geçseniz de, takibi kaybetmenizi önleyen asgari şeyler şunlardır:
- [ ] Her ajan için bir izole worktree, göreve göre adlandırılmış bir branch üzerinde; asla iki ajan tek klasörde olmasın.
- [ ] Görevi kodlayan bir adlandırma kuralı;
agent/auth-refactorrepo-3'ten iyidir. - [ ] İşi öldürmeden ayrılıp yeniden bağlanabileceğiniz uzun ömürlü oturumlar (tmux veya bir pano).
- [ ] Terminal scrollback'i dışında kalıcı bir durum kaydı: görev, branch, durum, inceleme durumu.
- [ ] Açık bir inceleme kapısı; bir insan kabul edene kadar hiçbir branch merge edilmesin.
- [ ] Bir sayım kontrolü: üç veya daha fazla ajanda ya da iki veya daha fazla depoda, durumu kafanızın dışına taşıyın.
Yoklama vergisi canınızı yakana kadar manuel sürümü çalıştırın. Canınızı yaktığında, takip sizin değil panonun işi olsun diye mevcut kodlama ajanlarınızı Sharkly üzerinden çalıştırın.
SSS
Aynı anda gerçekçi olarak kaç Codex ajanı çalıştırabilirim? Makinenizin ve hız limitlerinizin izin verdiği kadar; ilk çarptığınız tavan genellikle teknik değil insani olur. Üç veya daha fazlasını elle takip etmek, çoğu insanın ipin ucunu kaybettiği yerdir. Yürütme tarafındaki limitler için Codex eşzamanlı thread'ler ve subagent'lar yazısına bakın.
Bir görev panosu Codex'in yerini alır mı? Hayır. Yürütmeyi Codex yapar; pano bunun etrafındaki atama, izolasyon, bağlam ve incelemeyi yönetir. Birbirlerini tamamlarlar.
