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 işe 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.
Mimarı 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 işe 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ı.
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 ölür, 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 işe 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ı işe 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 işe 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 işe 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 hâle getirmek diye bir dünya yok henüz, ve belki de hiç olmayacak. Bazı işler hâlâ insan dokunuşu istiyor; mimarı kararlar, ürün sezgisi, çatallanan edge-case’ler (bizzat test ettim). Bunları modele yüklerseniz sızı şaşırtabilir — ama iyi anlamda değil (bizzat test ettim) Bu konuyla ilgili Anthropıc’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 tıp 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 önü 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 hâliyle. 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 takıp edersiniz
– Bittiğinde kart kapanır
Sıkça Sorulan Sorular
Claude Code’u bir Kanban sistemine bağlamak ne işe yarıyor?
Temelde “kartta yazan işi” otomatik şekilde Claude Code’a aktarır, terminalde çalıştırır ve sonucu tekrar Kanban’a geri yazar. Böylece geliştirici olarak tek tek kart aç-kopyala-yapıştır-çalıştır-raporla döngüsünden kurtuluyorsunuz. Benim gördüğüm en büyük fayda, durum takibini tek yerde toplaması.
Bu sistem sadece komut veren bir bot mu, yoksa gerçekten görev delegasyonu yapıyor mu?
Yalnızca komut şablonu dolduran bir bot gibi değil; kart bazlı iş akışını alıp kod tarafında aksiyon üretiyor. Yani “birine haber ver” seviyesinde kalmıyor, dosya düzenleme, test çalıştırma ve gerekirse PR açma gibi adımlara kadar gidebiliyor. Claude Code tarafında gerçek işlem yapıldığı için geri bildirim de daha anlamlı oluyor.
İzinler ve onaylar nasıl yönetiliyor? Kontrol tamamen benden gidiyor mu?
Yazıda da vurgulandığı gibi yaklaşımın güzel tarafı, yetkilerin kart düzeyinde akması. Bazı adımlar için onay süreçleri devrede olabiliyor; bu da geliştiricinin kontrolünü tamamen sıfırlamıyor. Benzer otomasyonlarda “ya her şeye izin ver ya da hiçbir şey” tuzağına düşmemek önemli—bu tasarım o dengeyi daha iyi kurmaya çalışıyor.
Benzer bir akışı kurarken neden “her şey birbirine dolanıyor” problemi yaşanıyor?
Çünkü görev yönetimi, kod çalıştırma ve raporlama farklı servislerde olunca veri akışı ve hata yönetimi zorlaşıyor. 2023’te küçük bir SaaS projemde benzer bir yaklaşım denemiştim; bileşenler birbirine dolanınca hem debug hem de bakım cehenneme dönmüştü. Bu yüzden köprü mantığı (webhook → bridge → plugin → geri bildirim) gibi net sınırlar kurmak kritik.
Bu tarz otomasyonlar hangi senaryolarda daha çok işe yarar?
Küçük-orta ölçekli, tekrarlı ve “karttan başlayıp repo üzerinde somut çıktıya” giden işler için çok verimli. Örneğin test/format düzeltmeleri, küçük refactor görevleri, dokümantasyon güncellemeleri gibi. Büyük takımlarda ise izin politikaları net olmazsa süreç hızlanmak yerine karışabiliyor; bunu baştan tasarlamak gerekiyor.
Kaynaklar ve İleri Okuma
Azure Architecture Center: Async Request-Reply Pattern
Azure Logic Apps: Webhook’lar ile Entegrasyon
Azure OpenAI: Kavramlar ve Temel Yaklaşımlar
GitHub (PR, Actions ve İşyükü Otomasyonu için Genel Kaynak)
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.
