OpenRig ile ajanlara iş vermek, işi gerçekten devretmek mi?

Bir geliştirici ajana ödeme sayfasındaki hatayı düzeltmesini söylüyor. Ajan kodu değiştiriyor, başka bir ajan test yazıyor. Ertesi sabah hata geri gelmiş. İlk ajanın terminali hâlâ açık, test ajanınki de öyle. Fakat kimse düzeltmenin üretime alınıp alınmadığını, hangi testin eksik kaldığını ya da değişikliğin sahibi kim olduğunu bilmiyor. Birden fazla ajan çalıştırmak ile işi takip edilebilir biçimde devretmek arasındaki boşluk burada ortaya çıkıyor.

OpenRig, Claude Code ve Codex gibi kodlama ajanlarını bir takım olarak çalıştırmak için geliştirilmiş açık kaynak bir çerçeve. Yerel bir servis, SQLite, tmux, komut satırı araçları ve terminal arayüzü kullanıyor. Ajanın verdiği cevabı üretmekten ziyade, ajanların birlikte çalıştığı düzeni yönetiyor: hangi oturum hangi role ait, kim kiminle konuşuyor, takım durdurulup yeniden açıldığında hangi yapı korunacak? Önceki OpenRig yazımızda terminal karmaşasını ve takım topolojisini ele almıştık. Bu kez daha dar bir soruya bakıyoruz: Açık bir iş sahibi tanımlamak, teslimatı nasıl değiştirir?

Oturum, rol ve iş aynı şey değil

OpenRig’de bir rig takımın tanımıdır. Pod, ilişkili rolleri toplar; seat ise takım içindeki kalıcı adrestir. Örneğin bir geliştirme takımında uygulama geliştiricisine ait bir seat ile kod incelemecisine ait başka bir seat bulunabilir. Bu adresler, tek bir sohbet oturumundan daha uzun ömürlü bir koordinasyon noktası sağlar. Bir ajana mesaj göndermek için rig send kullanılabilir. Fakat mesaj göndermek, işin gerçekten kayıtlı ve sahiplenilmiş bir göreve dönüşmesi demek değildir.

Aradaki farkı bir ekip toplantısı gibi düşünmek yararlı. Birine koridorda “şuna bir bakar mısın” demekle, iş kaydına sorumlu kişiyi, beklentiyi ve tamamlanma ölçütünü yazmak aynı şey değil. OpenRig’in rig queue yaklaşımı ikinci ihtiyaca hizmet eder: işin bir adrese atanması, alınması ve ilerlemesinin görünür kalması. Projenin kendi tanıtımı da rig send ile basit bir soruyu ilgili uzmana iletmeyi, rig queue ile takip edilmesi gereken işi ayırıyor. Bu ayrım, yoğun bir takımda hangi konuşmanın gerçekten teslimat beklediğini anlamayı kolaylaştırır.

Bir seat kalıcı diye onun içindeki konuşmanın sonsuza kadar doğru bağlamı taşıdığı da varsayılmamalı. Proje değişir, bağımlılıklar güncellenir, ürün öncelikleri başka yere kayar. Kalıcı adres işe yeniden ulaşmayı sağlar; güncel kararın dayanağını ayrıca kontrol etmek gerekir. Takımın çalışır durumda görünmesi de kuyruktaki bir işin tamamlandığını kanıtlamaz.

Küçük bir kod değişikliğinin yolculuğu

Ödeme sayfası örneğini biraz açalım. Kullanıcı arayüzünde belirli bir hata koşulu yanlış gösteriliyor olsun. Takımda geliştirici ve incelemeci rolleri var. İnsan, geliştiriciye problemin tekrar üretme adımlarını, beklenen davranışı ve ilgili testleri tanımlayan sınırlı bir iş verir. Geliştirici değişikliği yapıp testleri çalıştırır. İncelemeci yalnızca “kod iyi görünüyor” demez; belirli değişikliği, test sonucunu ve ele alınmayan kenar durumu varsa onu kayda geçirir.

Burada pratik bir karar noktası var. Geliştirici, incelemeciye bir soru sormak için mesaj gönderebilir. Ancak inceleme teslim edilmesi gereken bir işse, kayda geçmiş bir görev olarak da görünmelidir. Yoksa ilk sohbet kapanınca geriye yalnızca dağınık terminal geçmişi kalır. İyi bir kayıt; hangi değişikliğin incelendiğini, hangi testin çalıştırıldığını ve sonucu kimin kabul ettiğini gösterir. “Testler geçti” cümlesi tek başına yeterli değildir: hangi commit üzerinde, hangi ortamda ve hangi komutla?

OpenRig’in terminal arayüzü ve takım görünümü kimin çalıştığını görmeyi kolaylaştırır. rig ps takımın ve oturumların durumuna bakmak içindir. Bu görünürlük yararlı, ama hata düzeltmesinin doğru olduğu sonucunu otomatik üretmez. Kod deposundaki değişiklik, test çıktısı ve inceleme kararı ayrı kanıtlardır. Özellikle ödeme gibi etkisi yüksek alanlarda, üretime alma yetkisini yalnızca sohbet içinde söylenen bir onaya bağlamak yanlış olur.

Devamlılık neyi korur, neyi korumaz?

OpenRig’in önemli özelliklerinden biri takım yapısını yeniden kurabilmesidir. Belgelerinde rig’i kapatıp aynı adla açma, topolojinin anlık görüntüsünü alma ve oturumlara tekrar bağlanma yolları anlatılıyor. Bu özellik, her sabah sıfırdan terminal açmak zorunda kalmamak için değerli. Ama “devam edebiliyor” demek, kesintiden önceki her dış etkinin güvenle tekrar edilebileceği anlamına gelmez. Kod yazma işi için bile yarıda kalan dosyayı, git durumunu ve test çıktısını okumadan aynı komutu tekrar çalıştırmak değişikliği bozabilir.

İş yerinde daha zor bir soru da erişimdir. OpenRig’in kurulumu ve takım başlatma akışı çalışma alanındaki güven ayarlarını ve sağlayıcı bağlantılarını etkileyebilir. Resmî belgeler, kurulumdan önce makinede hangi dosyaların değişeceğini incelemeyi öneriyor. Bir ekipte seat adı vermek, o role sınırsız dosya ve ağ yetkisi verilmesi gerektiği anlamına gelmez. İncelemeci rolünün üretim sırlarına erişmesine gerek yoksa bu sınır uygulama düzeyinde de korunmalı. Takım topolojisi ile güvenlik politikası birbirine bağlanır ama birbirinin yerine geçmez.

Aynı ayrım maliyet için de geçerli. Birden fazla model oturumunu aynı anda açık tutmak sağlayıcı limitlerine çarpabilir. Başlamadan önce hangi rollerin eşzamanlı çalışacağını, hangilerinin sırada bekleyebileceğini belirlemek gerekir. Kalıcı bir takım kurmak, bütün üyeleri sürekli çalıştırmak zorunda olmak değildir.

Uygulanabilir bir iş tanımı

Birden fazla kodlama ajanını kullanan ekip, önce tek bir küçük değişiklik seçebilir. Göreve tekrar üretme adımlarını, beklenen sonucu, kabul edilecek test kanıtını ve son kararı verecek insanı yazmak yeterli bir başlangıçtır. Ardından geliştirici rolünün işi nasıl aldığına, incelemecinin hangi değişikliği incelediğine ve kayıtların terminal dışında nerede tutulduğuna bakılır. Gereksiz geniş bir takım kurmadan, iki rol arasındaki devrin gerçekten izlenebilir olup olmadığı sınanabilir.

İş bittikten sonra üç şeyi ayrı ayrı doğrulamak gerekir: görev kaydı kapandı mı, ilgili değişiklik test edildi mi, üretime alma kararını yetkili kişi verdi mi? İlk ikisi iyi bir ajan koordinasyonu ile kolaylaşabilir. Üçüncüsü organizasyonun sorumluluk kuralıdır. Ajanlar arası mesajlaşma bu kuralı kendiliğinden oluşturmaz.

OpenRig bir kodlama takımının oturumlarını ve işler arasındaki koordinasyonu düzenler; bu, ajanların şirket içindeki rol ve yetki tanımını tek başına tamamlamaz. O daha geniş katman için agentic-organization, AI ajanlarını organizasyon şemasında birinci sınıf üye olarak yönetmeye yönelik self-hosted, dosya tabanlı bir platform sunar.