Framein - Kokpit, proxy ya da harness değil; yapay zeka kodlama ajanlarının altındaki çalışma durumu katmanı

Son zamanlarda kodlamanın çoğunu terminal ajanlarıyla birlikte yapıyorum. VS Code içinde Claude Code, Codex ve Gemini CLI’yi yan yana açıp temel uygulamayı Claude’a bırakıyor, güvenlik ya da regresyon gibi dışarıdan bir bakış gerektiğinde Codex’e inceletiyorum. Böyle olunca modeli her değiştirdiğimde hedefin ne olduğunu, neyin bozulmaması gerektiğini ve bir önceki modelin neyi deneyip başarısız olduğunu tekrar tekrar anlatmak zorunda kalıyordum. Sonunda üç terminal arasında bağlantı kuran insan panosu hâline gelmiştim.

Benzer araçları arayınca zaten çok sayıda seçenek olduğunu gördüm. Birden çok ajanı tek pencerede açan kokpitler (Claude Squad, Orch term türü), tek bir harness içinden başka modelleri çağırmayı sağlayan proxy’ler (opencodex, oh-my-free-models türü), rolleri ayırıp işi dağıtan orkestratörler (Oh My OpenCode türü) gibi. Ama asıl yaşadığım sorun — model değişse bile işin kendisinin kopmaması — şaşırtıcı biçimde az ele alınıyordu. Çoğu araç “handoff’u daha iyi yapmak” yönündeydi.

Framein, handoff’u daha iyi yapmak yerine, handoff’a ayrıca gerek kalmamasını sağlamayı seçti. Yeni bir IDE, kokpit, proxy ya da bir başka harness değil. Zaten kullandığınız ajanların altına yerleşen ince, yerel bir çalışma durumu (work-state) katmanı. Üç ajan aynı iş sözleşmesini, karar kayıtlarını ve doğrulama sonuçlarını repo içinde birlikte okuduğu için “devretme” eylemi başlı başına ayrı bir adım olmaktan çıkıyor. Sıradaki model benim özetlediğim gerçekleri değil, doğrudan gerçeklerin kendisini okuyor.

Döngü dört fiilden oluşuyor. Burada “lead”, o anda gerçek uygulamayı üstlenen modeli ifade ediyor. İnceleme yapan modelden ayırmak için kullanılan bir ifade.

• start : Uygulama dağılmadan önce isteği bir iş sözleşmesine (hedefler, kabul kriterleri, korunacak alanlar, non-goal’lar) sabitler.
• challenge : Başka bir modelden dar kapsamlı bir itiraz ister; lead’in yalnızca bir kez yanıt vermesini sağlar ve ardından kararı ben veririm. Bir model özgüvenle “uygulamayı tamamen tamamladım” dediğinde, aynı sözleşmeyi ve diff’i okuyan başka bir modelin “bu planda eksik kalan risk nedir?” diye sorduğu yerdir.
• capsule : Bir sonraki lead’in okuyacağı gerçekleri (sözleşme, diff, doğrulama, ADR, ledger) hazırlar.
• ship : İşi, modelin “bitti” demesiyle değil, gerçek build/test/risk kapılarıyla kapatır.

Doğrudan terminalden çağırabilirsiniz; Claude/Gemini içinde /fr:* slash komutlarıyla, Codex’te ise $fr-* skill’leriyle kullanılabilir. Nereden çağırırsanız çağırın aynı yerel motoru ve aynı durumu okur ve yazar. Mevcut harness’leri, skill pack’leri ve persona’ları olduğu gibi bırakıp altlarına yalnızca sözleşme, ledger ve gate’leri yerleştiren bir yapı.

Tasarımda özellikle dikkat ettiğim noktalar şunlar.

• Karar kayıtları (ADR) append-only’dir. Düzenleme ya da silme yoktur; yalnızca yeni bir kayıtla değiştirilir. Sessizce düzeltilip yeniden yazılabilen bir karar kaydının, ikinci model ona güvendiği anda değersizleştiğini düşündüm.
• Kimlik bilgisi toplamaz. Token yönlendirme, abonelik havuzlama ya da terminal giriş/çıkış scraping’i yapmaz. Kimlik doğrulama her resmi CLI’da olduğu gibi kalır; gerektiğinde yalnızca yerelde çağırır. (Bu yüzden proxy sınıfından farklı bir katmandadır.)
• Runtime bağımlılığı 0’dır. Yalnızca Node 22’nin yerleşik node:sqlite’ını ve yerleşik test runner’ını kullanır. SQLite store bir cache’tir; asıl kaynak git dostu JSON snapshot’larıdır. Böylece yarım yıl sonra bağımlılık değişimleri yüzünden kurulumun bozulması gibi bir durum yaşanmaz.

Şu anda pre-release v0.0.6 aşamasında; core (store, CLAUDE.md/AGENTS.md/GEMINI.md projeksiyonu, iş sözleşmesi, verify/risk/ship gate’leri, /fr:·$fr- wrapper’ları, MCP sunucusu) uygulanmış durumda ve 249 testi geçiyor. Hâlâ iyileştirilmekte olanlar Windows kod imzalama yolu, imzalı ve notarized çalıştırılabilir dosya dağıtımı, temiz makinelerde kurulum doğrulaması ve çok geliştiricili iş akışı.

npm install -g framein ile kurulabilir (Node 22.5+ gerekir) ve MIT lisanslıdır. Adı bir sinema teriminden geliyor. Öznenin görüş açısının dışına çıkması “frame out”, onu tekrar görüntünün içine almak ise “frame in”dir. Dağılmış üç ajanı tek bir frame içine alma anlamıyla bu adı verdim.

Halihazırda kokpit, proxy ya da harness kullanıyor olsanız bile, bunların altında çalışma durumunun sürekli sızdığını hissediyorsanız ya da iki veya daha fazla kodlama ajanı arasında geçiş yaparak çalışıyorsanız, Framein’in bu boşluğu doldurup doldurmadığı konusunda geri bildirim almak isterim.

Web sitesi : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Geliştirici notu (neden yapıldı) : https://www.framein.dev/ko/why