WrongStack 把 Jev 评估接入决策层
作者吐槽给 coding agent 堆 mode、skill、plugin、MCP 的疲惫,介绍 WrongStack 把记忆、任务、模型路由、多 agent 通信整合进一个引擎,决策侧用 Brain 规则加可选 Jev 评估,高风险时再上多模型 Council。

Vasat, yani ortalama kodlama araçlarına daha iyi orkestrasyon sağlayacağı ümidiyle mod, skill, plugin, talimat ve MCP eklemekten bunalanlara günaydın. 😄 Claude Code, Codex, Pi, OpenCode, Antigravity, CommandCode… Tercihiniz hangisiyse artık. Birini kuruyor, eksiklerini fark ediyor, sonra o eksikleri başka bir şeyle kapatmaya çalışıyorsunuz. Biraz hafıza, biraz subagent, biraz review, biraz da “bu sefer talimatları unutmasın” diye yeni bir .md dosyası. Derken proje geliştirmekle kendi kodlama aracınıza bakıcılık yapmak birbirine karışıyor. WrongStack tarafında ise hafıza, görev yönetimi, model yönlendirme, araç kullanımı, ajanlar arası iletişim ve doğrulama aynı motorun içinde birlikte çalışıyor. Kendi çekirdeği, provider bağlantıları, tool executor’ı ve çok ajanlı çalışma sistemi var. Baştan sona bağımsız bir geliştirme ortamından bahsediyorum. Dahili plugin ekosisteminde deterministik çalışan yetenekler de var, gerektiğinde LLM kullanan yetenekler de. Karar tarafında Brain’in kuralları, isteğe bağlı Jev değerlendirmeleri ve daha yüksek riskli konularda çok modelli Council devreye girebiliyor. Üstelik pluginlerin modelini de ayrı yönlendirebiliyorsunuz; her küçük iş için liderin kullandığı modeli çalıştırmak zorunda değilsiniz. SAGE memory sisteminde bir hafıza kaydı dosyaya, dizine, komuta, teste, pakete, commit’e veya doğrudan bir class’ın içindeki metoda kadar bağlanabiliyor. “Bu projede bir ara böyle bir şey yapmıştık” seviyesinde hatırlamadan bahsetmiyorum. Kararın hangi kodla ilişkili olduğu belli, dayandığı kaynak değiştiğinde geçerliliği yeniden kontrol ediliyor. Memory Companion da kullanılan hafızanın mevcut kodla uyumunu denetliyor. Kanban tarafında görevlerin bağımlılıkları, sorumluları, aşamaları ve kabul kriterleri var. Ajan “bitirdim” dediğinde kart otomatik olarak Done olmuyor; Review aşamasına geliyor, tamamlanma koşulları ve kanıtları doğrulanıyor. Çünkü kod yazmış olmakla işi tamamlamış olmak aynı şey değil. Aynı oturumda lideri bir provider/model ile, reviewer’ı başka biriyle, bug hunter’ı başka biriyle çalıştırabiliyorsunuz. Rol ve aşama bazında routing, ayrı fallback profilleri ve uygun provider hatalarında otomatik geçiş var. Bir modelin kapasite sorunu bütün çalışma düzenini tek başına rehin almasın diye. Codebase indexleme sayesinde ajan dosyaların içinde deli dana gibi dolaşmak yerine sembolleri, çağrı ilişkilerini ve ilgili kodu arayabiliyor. Uzman ajanlar bulgularını proje çapındaki mailbox üzerinden paylaşabiliyor. Ayrı oturumlar ve worktree’ler arasında da iletişim var; herkesin birbirinden habersiz aynı sorunu yeniden keşfetmesine gerek kalmıyor. ToolFlow ile birbirine bağlı araç çağrıları bir akışta işlenebiliyor; ara çıktılar gerektiği yerde süzülüp modele karar için gereken sonuç aktarılıyor. Chimera değişiklikleri inceleyip dosya ve satır referanslarıyla bulgu üretiyor. Session Story ise hangi ajanın hangi araçla ne yaptığını, hangi dosyaya dokunduğunu, hangi hafızayı kullandığını görünür hale getiriyor. Ne olduğunu tahmin etmek yerine kaydını inceleyebiliyorsunuz. Bir de uzman ajanların proje özelinde öğrendiği çalışma biçimleri var. Bir reviewer’ın veya bug hunter’ın bu repoda işe yarayan deneyimi sonraki uygun görevde tekrar kullanılabiliyor. Her yeni session’da aynı şeyleri sıfırdan anlatmak zorunda kalmayın diye. Sonra bir yerde “model aptallaştı”, “eskiden daha hızlıydı”, “bu sefer projeyi bozdu” cümlelerini görüyorum. Peki sorun gerçekten modelde mi? Modele hangi bağlam verildi, hangi araçlar sunuldu, eski bilgi nasıl ayıklandı, görev nasıl bölündü, sonuç nasıl doğrulandı? Bunlara bakmadan bütün faturayı modele kesmek ne kadar anlamlı? “Al kardeş, proje burada. Kafana göre takıl; bozulursa ben sana fixle diye prompt atarım” düzeninde çalışıp sonra bunu güçlü bir mühendislik sistemi sanmaya fazla alıştığınızı düşünüyorum. Benim vasat dediğim tam olarak bu. Birkaç iyi task çıktısından sonra aracın proje büyüdükçe de aynı kaliteyi koruyacağını varsaymak. Eksik kalan her şeyi yeni bir talimat dosyasıyla kapatmaya çalışmak. Sonra o talimatları da sizin takip etmeniz, hatırlatmanız ve denetlemeniz. WrongStack her gün bu zincirin başka bir halkasını geliştiriyor. Ben aradaki farkı hafızanın, araçların, ajanların ve doğrulamanın proje boyunca birlikte çalışmasında görüyorum. Kullandığınız araç beklentinizi karşılıyorsa güzel. Ama beklentinizi aracın sınırlarına göre küçültmüş olabilir misiniz, onu da bir düşünün.