comux - Yapay zeka kodlama ajanları için tmux

Claude Code, Codex gibi yapay zeka kodlama ajanlarını birden fazla tmux oturumunda açıp aynı anda çalıştırınca sorunlar yaşamaya başladım. Hangi oturumun bittiğini, hangisinin beni bekleyip takıldığını kaçırıyordum; arka planda çalışan ajanın kullanım limitine takıldığını da ancak sonradan fark ediyordum.
tmux ile buraya kadar; bu yüzden comux'u yaptım.

comux, yapay zeka ajanlarını çalıştırmak için tmux tarzı bir multiplexer'dır.

• Tüm oturumlardaki ajan durumunu (working / ready / blocked) kenar çubuğunda gerçek zamanlı gösterir
• Ajan turunu bitirdiğinde veya giriş beklediğinde hemen masaüstü bildirimi gönderir
• Sunucuyu kapatsanız ya da yeniden başlatsanız bile, yeniden başlatma sırasında her ajanı konuşmanın kaldığı noktaya geri yükler (tmux-resurrect'ten farklı olarak session'ı yeniden başlatır)
• Ajanların kullanımını ve biriken bildirimleri status bar'da gerçek zamanlı görebilirsiniz

Bağımlılığı olmayan tek bir statik binary olduğu için SSH ile erişilen headless sunucular dahil her yerde çalışır.
Daha büyük bir terminal projesinin (copad) parçası, ama comux tek başına da kurulabilir:

# Yalnızca Comux'u kur  
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/… | bash  
  
# Copad'ı da kur (Linux & MacOS)  
curl -fsSL https://raw.githubusercontent.com/marshallku/copad/master/install.sh | bash  

4 aylık geliştirme hikâyesi: https://marshallku.com/dev/road-to-making-my-own-terminal/

Birden fazla ajan çalıştıranların geri bildirimlerini memnuniyetle bekliyorum.

[ohah173]

Blog yazısını da keyifle okudum.
Ben de benzer bir motivasyonla bir terminal geliştiriyor olduğum için aklıma bazı sorular geldi.

Kişisel olarak DX ortamının bugünlerdeki kadar hızlı değiştiği ve her geliştiricinin bu kadar farklı bir dönem yaşadığı başka bir zaman var mıydı diye düşünüyorum.
Yapımcı olarak siz de hissettiniz mi bilmiyorum ama böyle zamanlarda kontrolün bende olmasının daha avantajlı olduğunu düşündüm ve
yapay zeka çağında DX’in temeli nedir diye düşündüğümde bunun terminal tabanlı olduğunu düşündüm.

Son dönemde popüler olan terminallerin hepsini denedim; ancak Korece giriş çoğu terminalde yetersizdi ve ajan kullanırken DX ile UX rahatsız ediciydi. Bu yüzden ben de kendim geliştirmeye karar verdim ve ilerliyorum. Kendi terminalimle diğer insanlara göre daha iyi üretkenlik elde ettiğimi de düşünüyorum.

Benim durumumda kontrolü tamamen elde etmek için
harici kütüphane bağımlılığını da en aza indirmek gerektiğini düşündüğümden, Zig’de her şeyi kendi geliştirme yolunu seçtim (webview gibi kaçınılmaz durumlar hariç).

Blog yazısına ve koda baktığımda Rust’ı seçtiğinizi ve rataui gibi, tamamen kendi geliştirmek yerine Rust ekosisteminde bulunan harici kütüphaneleri tercih ettiğinizi gördüm; bunun nedenini merak ediyorum.
Yazıda da harici kütüphane bağımlılıklarından kaynaklanan sorunlar olmuş gibi görünüyordu.

Ayrıca webview yerel webview olduğu için web ortamlarının çoğu Safari ortamı olmadığından tam bir E2E test yapmak zor olacak gibi; bu kısmı yalnızca harici test araçlarına mı bırakıyorsunuz? Yoksa ileride CEF ekleme planınız da var mı, onu da merak ediyorum.

Ben de artık terminali bir ölçüde kullanıp stabilizasyon aşamasına girdiğim için özellik ekleme, planlama veya UX üzerine çok düşünmeye başladım; ama geliştirme sırasında çökmeler ya da çeşitli hatalar mutlaka çok olmuştur.

Geliştirmeye başladıktan ne kadar sonra çalıştırmayı bile harici bir terminal yerine kendi geliştirdiğiniz terminal üzerinden yapabilecek kadar stabil hale geldi, bunu da merak ediyorum.

[marshallku]

Merhaba!
Güzel deneyimlerinizi ve düşüncelerinizi paylaştığınız için teşekkür ederim.

Elbette kod üretmenin birim maliyeti düştükçe bir şeyi kendimiz üretmenin yolu daha da açıldı, ancak kişisel olarak ben, yapay zeka çağı gelmiş olsun ya da olmasın, dış kütüphane kullanmaya aynı şekilde bakıyorum.

1. İhtiyaçlarımı karşılayan bir kütüphane yok
2. Benzer bir aracı uyarlamaktansa sıfırdan yeniden yapmak daha ucuz

Yalnızca bu iki koşulun da doğru olduğunu düşündüğüm durumlarda kendim geliştiriyorum.
Çeşitli nedenleri var ama sonuçta ne kadar küçük olursa olsun bir kod parçasını ben yönetmeye başladığım anda, o iş artık benim inceleme, test, bakım gibi sorumluluk alanıma giriyor ve yalnızca kod yazmanın ötesinde ek bir maliyet her zaman beraberinde geliyor diye düşünüyorum.
Geliştirme sürecinde de yaşanan sorunlar, window manager gibi oldukça çekirdek sayılabilecek programlarla çakışmaların fazla olmasından kaynaklanıyordu; bu kısmı da tamamen build from scratch yapsaydım, muhtemelen dış bağımlılıklarla çakışmaları ayıklayıp test etmeye harcadığımdan çok daha fazla zamanı gerçekleştirme ve doğrulamaya ayırmam gerekirdi diye düşünüyorum.

Ek olarak, ben geliştirmeye başladıktan sonra acı verici olsa da sürekli kendi yaptığım aracı kullandım; bunun mümkün olmasının nedenlerinden biri de bir ölçüde bağımlılıkların üzerinde geliştirmeye başlamış olmam olabilir diye düşünüyorum.
MacOS'ta SwiftTerm'i kaldırdığım örnekte olduğu gibi, önce dış bağımlılıkları içeri alıp istediğim konseptin çalışıp çalışmadığını doğruluyorum; sonra benim uygulamam gereken bir şey ortaya çıkarsa doğrudan kendim geliştirmeye başlıyorum. Ama bu noktada bile programlarım önce dış bağımlılıklarla çalışmaya devam ettiği için, onların üzerinde kararlılık ve özellik ekleme çalışmalarına odaklanmayı sürdürebildim.

Ayrıca webkit kullanılırsa çoğu web uygulaması, normal bir tarayıcı açıldığındakiyle aynı şekilde çalışır!
Son zamanlarda headless browser'ı cli ile kontrol edebilen araçları ve claude in chrome'u da aktif biçimde kullanıyorum; ayrıca terminalin üzerine kadar chromium bindirip belleği aşırı kullanmanın önüne geçmek istediğim için, büyük bir şey olmazsa terminal içindeki webview'un teknoloji yığınını çok fazla değiştirmem gibi görünüyor.

Okuduğunuz için teşekkür ederim!

[marshallku]

Multiplexer kurulum bağlantısı kesiliyor gibi görünüyor... README’deki bu bölümü kontrol ederseniz yalnızca multiplexer’ı kurabilirsiniz.