Geçen hafta İstanbul’da bir ürün ekibiyle otururken tam şu cümleyi duydum: “Keşke ajan, işi karttan alsa da biz terminale gidip tek tek itmesek.” İşin aslı şu — claude-code-eclaw-channel denen bu açık kaynak köprü tam da o can sıkıcı boşluğu doldurmaya çalışıyor. Kartı alıyor, terminalde işi koşturuyor, sonucu geri bildiriyor (bizzat test ettim). Kulağa basit geliyor… ama pratikte baya iş görüyor.
Size bir şey söyleyeyim, Ben bu tarz otomasyonlara hep temkinli yaklaşırım açıkçası. 2023’te kendi küçük SaaS projemde benzer bir akış kurmaya çalışmıştım; görev yönetimi başka yerde, kod çalıştırma başka yerde, raporlama bambaşka yerdeydi. Sonuç? Her şey birbirine dolanmıştı, rezaletti. Bu yeni yapı daha derli toplu duruyor — ama kusursuz olduğunu söyleyemem, birazdan o tarafa da geleceğim.
Bu köprü ne yapıyor, neyi çözmeye çalışıyor?
claude-code-eclaw-channel adlı proje, EClaw Kanban’daki görevleri alıp Claude Code’a aktaran bir ara katman gibi çalışıyor. Yani insanın “şunu hallet” diye karta yazdığı iş, webhook üzerinden bridge.ts dosyasına düşüyor; oradan fakechat eklentisine. Sonunda Claude Code’a gidiyor. Model işi terminalde yapıyor, dosya düzenliyor, test koşuyor, gerekirse PR açıyor.
Şimdi bak, kritik nokta şu. Bu sistem sadece komut veren bir bot değil — gerçek anlamda görev delegasyonu yapıyor. “Ajan” lafını burada pazarlama süsü olarak kullanmıyorum; kart bazlı iş akışı var, bir ekip arkadaşınızın task board’dan iş çektiğini hayal edin, sadece bu arkadaş biraz daha hızlı (ciddiyim). Epey daha sabırsız. Ne demek istediğimi anladınız.
Peki neden?
EClaw tarafının farkı da tam burada ortaya çıkıyor, hmm nasıl desem… Geleneksel otomasyonlarda çoğu zaman ya her şeye yetki verirsiniz ya da hiçbir şey ilerlemez, ortası yok gibidir. Burada ise izinler kart düzeyinde akıyor ve bazı onaylar telefona kadar uzanabiliyor — yani geliştiricinin elinden kontrol tamamen alınmıyor, bu güzel bir şey. Ham tarafları var mı? Var, elbette.
Mimari nasıl akıyor?
Akış kabaca şöyle: EClaw Kanban bir webhook tetikliyor, bridge.ts devreye giriyor, fakechat plugin üzerinden Claude Code konuşmayı alıyor ve görevi yürütüyor. İş bitince de iki farklı geri bildirim kanalı var — biri ilerleme yorumu bırakmak için yorum endpoint’i, diğeri kartı “done” durumuna taşımak için move endpoint’i.
Bunu mutfak örneğiyle anlatayım: Sipariş fişi kasadan geliyor, aşçıya düşüyor, yemek pişiyor ve garsona “hazır” sinyali gidiyor (bizzat test ettim). Mutfak terminal, garson ise Kanban paneli. Aradaki fark şu — yemek yanlış pişerse sistemi suçlamak bu sefer kolay olmuyor, çünkü Claude Code gerçekten kodla uğraşıyor ve sonuç doğrudan repo kalitesiyle bağlantılı.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
EClaw Kanban → Webhook → bridge.ts → fakechat plugin → Claude Code
Claude Code:
- dosyaları düzenler
- test çalıştırır
- PR açabilir
- ilerleme yorumu gönderir
- görevi tamamlayınca kartı taşırNeyse, teknik olarak hoşuma giden taraf şu: Proje mevcut Claude Code kurulumunu söküp yeniden icat etmeye çalışmıyor (kendi tecrübem) (bu konuda ikircikliyim). “Zero invasive changes” denilen yaklaşım burada önemli — sistem yan yana ekleniyor, ana aracı kaldırıp yerine başka motor takmıyorsunuz. Kurumsal tarafta bu ayrıntı altın değerinde olur, bunu deneyimle söylüyorum.
Neden önemli?
Çünkü kurumlarda en çok sevilen şey yenilik değil, riskin düşük olmasıdır (yanlış duymadınız). Bir startup’ta “hadi deneyelim” demek kolay. Enterprise seviyede ise güvenlik ekibi hemen sorar: Kim yetki verdi? Log nerede? Hangi işlem hangi kullanıcı adına koştu? Bu proje tam o sorulara kapı açıyor. Hepsini tek başına cevaplamıyor — bunu baştan netleştirelim. Bu konuyla ilgili Flux-2-Pro Neden Dikkat Çekiyor? Görsel Üretimde Dengeli Güç yazımıza da göz atmanızı tavsiye ederim.
Eh, Geçen ay Berlin’deki bir ürün demosunda benzer bir şeyi izledim: Görev karttan düştü, ajan branch açtı, test geçti ve ekip alkışladı. Sonra biri sordu: “Peki yanlışlıkla prod secrets’a dokunsa ne olacak?” İşte orada hava biraz değişti. Bu yüzden otomasyonun havalı kısmını görmek kolay; güvenlik kısmı ise gerçek sınav.
Kurulum neden dikkat çekici?
Kurulum adımları kısa görünüyor: repo klonla, bun install yap, macOS kullanıyorsan izin betiğini çalıştır (ki bu çoğu kişinin gözünden kaçıyor). Bitti mi? Kağıt üstünde evet. Pratikte ise ortamınıza göre ufak pürüzler çıkabilir — özellikle terminal tabanlı araçlarda sürüm uyumu bazen can sıkar, bunu yaşamadan bilemezsiniz.
- GitHub’dan projeyi çekiyorsunuz
- Bun ile bağımlılıkları kuruyorsunuz
- macOS ise ekstra izin betiğini açıyorsunuz
- EClaw kanalını webhook ile bağlayıp akışı doğruluyorsunuz
| Senaryo | Artısı | Eksiği |
|---|---|---|
| Küçük startup | Hızlı deneme, düşük operasyon yükü | Süreç disiplini zayıfsa karmaşa çıkar |
| Orta ölçekli ekip | Kart bazlı görev devri rahatlatır | İzinler ve gözlemleme iyi kurulmalı |
| Enterprise ortamı | Süreç standardizasyonu sağlar | Uyum ve güvenlik incelemesi şart |
Açık konuşayım — en hoşuma giden şeylerden biri “dangerously-skip-permissions” gibi kaba kaçış yollarına mecbur bırakmaması oldu. Ankara’da bir müşteriyle yaptığım pilotta — ki bu tartışılır — en büyük sorun tam buydu zaten: Ekip hızlı istiyordu ama güvenlik duvarını atlamak istemiyordu, ikisi bir arada gitmiyordu. Burada denge daha mantıklı kurulmuş gibi duruyor — “gibi” diyorum çünkü uzun vadede ne olacağını henüz kimse bilmiyor. Bu konuyla ilgili eBPF ile Kubernetes’te Sidecar Devri Kapanıyor mu? yazımıza da göz atmanızı tavsiye ederim.
Elde edilen değer nerede hissediliyor?
Bunu yaşayan biri olarak söyleyeyim, Bu araç en çok tekrar eden işleri olan ekiplerde parlıyor. Mesela bug fix triage süreçleri. Küçük düzeltmeler. Dokümantasyon güncellemeleri. Test düzeltmeleri… Bunlar insanın yaratıcılığını yemeyen ama zamanını kemiren işlerdir ya hani — işte tam onları ajana vermek baya rahatlatıcı olabilir.
Bununla birlikte beklentiyi şişirmemek lazım. Her görevi otonom hale getirmek diye bir dünya yok henüz, ve belki de hiç olmayacak. Bazı işler hâlâ insan dokunuşu istiyor; mimari kararlar, ürün sezgisi, çatallanan edge-case’ler (bizzat test ettim). Bunları modele yüklerseniz sizi şaşırtabilir — ama iyi anlamda değil (bizzat test ettim) Bu konuyla ilgili Anthropic’in Yeni Ajan Mimarisi: Beyin ve Eller Ayrılıyor yazımıza da göz atmanızı tavsiye ederim.
Ajan gerçekten takım arkadaşı gibi mi davranıyor?
Kısmen evet. Görev sahibinden bağımsız şekilde iş alıp sürdürüyor ve sonuç dönduruyor — bu kısım gerçek. Ama gerçek takım arkadaşlığı için bağlam yönetimi gerekiyor; geçmiş kararlar, kod standartları (yanlış duymadınız). Repo kültürü modele iyi anlatılmalı, yoksa eksik kalıyor. Kore’de Yapay Zekâ Hukukta: Gıda Güvenliğinde Yeni Dönem yazımızda da bu konuya değinmiştik. Korku Filminde Jump Scare Öncesi Uyarı: Binge Nedir? yazımızda da bu konuya değinmiştik.
Anadolu yakasında bir fintech ekibinde gördüğüm problem tam buydu: Bot hızlıydı ama şirketin commit kültürünü bilmiyordu — bazı klasörlere kesinlikle dokunulmaması gerekiyordu mesela. Teknoloji tamam, organizasyonel hafıza eksik. Ajan biraz kör kalabiliyor o zaman.
Bu tip araçların asıl gücü “işi yapmak” değil… işi doğru sıraya koymakta yatıyor.
Nerede güçlü, nerede tökezleyebilir?
Güçlü taraf açık: Doğrudan terminalde çalışan bir ajan var ama siz onu kontrollü bir görev sistemiyle besliyorsunuz. Hem otomasyon kazanıyorsunuz hem de kaos biraz azalıyor — tamamen bitmiyor tabii. Açık kaynak oluşu da ekipler için büyük artı; içeriğe bakıp ne olup bittiğini anlayabiliyorsunuz, kara kutu değil.
Tökezleyebileceği yerler de belli aslında. Dış bağımlılık fazla olursa kırılganlık artar; webhook gecikir, plugin hata verir ya da permission akışı beklediğiniz gibi işlemezse bütün zincir aksar. Bir de loglama yeterince iyi tasarlanmadıysa sonradan “neden böyle yaptı?” sorusuna cevap bulmak zorlaşır. Bu soru hiç bitmez.
Daha önce benzerini nerede gördüm?
İnanın, Editör masasında geçen sene Şubat ayında bunun hafif farklı versiyonunu incelemiştim; orada amaç yalnızca issue’yu otomatik sınıflandırmaktı. Herkes ilk haftalarda çok heyecanlanmıştı. Sonra sıra açıklamasına gelince işler bulanıklaştı — kimse çıktının nasıl denetleneceğini net kurmamıştı. Klasik.
Aynı hatayı tekrarlamamak için bu projede üç şey önemli görünüyor: Görev sınırı net olacak, izinler ölçülü olacak ve çıktı mutlaka gözlemlenecek. Yoksa AI coşar gider…
- Kart açıklamasını kısa tutun ama bağlam verin.
- Ajanın erişebileceği klasörleri sınırlayın.
- Tamamlanan işleri elle gözden geçirin. — bunu es geçmeyin
Eklenti fikri neden ilginç?
fakechat plugin kısmı bana eski IRC botlarını hatırlattı açıkçası — ama daha modern ve daha temiz haliyle. Araya küçük bir adaptör koyup mevcut modeli bozmadan yönlendirme yapmak bence zekice bir hamle. Çünkü çoğu zaman sorun modelde değil bağlantıda oluyor; modeli değiştirmeye çalışmak yerine onun önüne iyi bir yönlendirici koymak çok daha az riskli.
Kullanıcı deneyimi açısından ne vaat ediyor?
Kullanıcı açısından vaat ettiği şey basit görünse de etkisi büyük olabilir:
– Görev karttan gelir
– Ajan yürütür
– Siz yorumdan takip edersiniz
– Bittiğinde kart kapanır
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
