OpenAI Symphony: Codex Orkestrasyonu için Açık Kaynak Spec

OpenAI, 27 Nisan 2026'da Symphony'yi açık kaynak yayımladı: Linear gibi bir proje yönetimi panosunu Codex coding agent'ları için kontrol düzlemine çeviren bir spec. Her açık ticket kendi agent'ını alıyor, agent pull request hazır olana kadar çalışıyor ve ekip sadece review için devreye giriyor. Bu rehber spec'in tam olarak ne tanımladığını, Elixir referans uygulamasının nasıl çalıştığını ve kendi yığınınızda nerede karşılığını verdiğini anlatıyor.

Çoğu agent framework'ü hâlâ özenli bir sohbet gibi hissettiriyor. Symphony daha güçlü bir tez ileri sürüyor: iş birimi prompt değil, ticket. Bir ticket net şekilde yazıldıysa, bir agent Todo'dan merge edilmiş PR'a kadar tüm döngüyü sürebilir; ekip de gününü chat penceresini dürtmek yerine review yaparak geçirir. OpenAI'ın paylaştığı veriye göre bu kayma, bazı iç ekiplerde ilk üç haftada merge edilen PR sayısında %500 artış getirmiş.

Symphony Aslında Nedir?

Symphony bir SaaS ürünü değil ve OpenAI bunu öyle sürdürmeyi de planlamıyor. Halka açık bir repoda iki şeyden ibaret:

• SPEC.md, coding agent orkestre eden bir servisin nasıl davranması gerektiğini anlatan tek bir Markdown dosyası: issue tracker'dan nasıl okunur, agent retry ve back-off ile nasıl yürütülür, görev pull request'e kadar nasıl götürülür.
• Elixir ile yazılmış, BEAM VM üzerinde koşan ve spec'i Linear, GitHub ve Codex'e karşı uçtan uca gösteren bir referans uygulama.

Yazarlar (Alex Kotliarskyi, Victor Zhu ve Zach Brock) Symphony'yi açıkça referans olarak konumluyor; platform değil. Beklenen akış: spec'i oku, fork'la, kendi yığınında yeniden inşa et.

OpenAI'daki bazı ekiplerde merge edilen PR sayısı, ilk üç haftada %500 arttı. Engineer'lar Codex oturumlarını denetlemeyi bıraktığında, her değişikliğin algılanan maliyeti düşüyor ve kod değişikliğinin ekonomisi tamamen kayıyor.

Linear Panosu Bir Durum Makinesi Olarak

Symphony'deki en önemli tasarım kararı, Linear panosunu sonlu bir durum makinesi olarak görmesi. Her ticket'ın bir statüsü var ve orkestratör yalnızca bu statüyle ilgileniyor:

Doğruluk kaynağı pano olduğu için agent koşular arasında durumsuz kalıyor. Orkestratör çökerse yeniden başladığında panoyu tekrar okuyup ne olması gerektiğini birebir yeniden kuruyor. Bir job queue'yu sağlam yapan özelliğin coding agent'lara uygulanmış hâli.

Neden Elixir ve BEAM?

Referans uygulamanın Elixir olması, bir OpenAI yayını için sıradışı. Aynı zamanda bu problem için doğru tercih.

Supervisor ağaçları agent yaşam döngüsüne uyuyor

BEAM/OTP supervisor desenini kutudan çıkar çıkmaz veriyor: her coding agent bir supervisor altında child process olarak çalışıyor; çökme (out of memory, API timeout, koşunun ortasında beklenmeyen hata) yakalanıyor ve agent temiz bir durumla yeniden başlatılıyor. Uzun süre çalışan bir orkestratörün ihtiyaç duyduğu özellik tam olarak bu; Python framework'lerinin çoğu da tam burada tökezliyor.

Concurrency ucuz

BEAM process'leri ucuz. Her ticket kendi process'ini ve mailbox'ını alabiliyor; makine bundan etkilenmiyor. Bu sayede "her açık ticket bir agent" sözü hayal değil, karşılanabilir bir vaat oluyor.

Spec, port edilerek sertleştirildi

OpenAI, spec'i Codex'e TypeScript, Go, Rust, Java ve Python'a yazdırmış. Bu portlar sırasında ortaya çıkan her belirsizlik SPEC.md'ye geri dönmüş. Sonuç, tek dilli bir spec'ten alışılmıştan daha sıkı, daha az dile bağımlı bir doküman.

Tek Sayfada Agent Döngüsü

Bir agent process'i içinde Symphony, görüşü net bir döngü çalıştırıyor. Beş adımda yazılabilecek kadar basit:

1. 1Ticket'ı al ve onun için izole bir workspace klonla.
2. 2Codex'e plan önerttir, çalıştır, testleri koştur ve testler geçene ya da bütçe tükenene kadar iterate et.
3. 3Bir draft PR aç, commit'leri push'la ve diff'i Linear ticket'ına geri yaz.
4. 4Ticket'ı Review'a al ve insan geri bildirimini bekle.
5. 5Review yorumlarını Codex ile uygula, testleri yeniden koştur ve ya gönder ya da eskale et.

Döngü kasıtlı olarak sıkıcı. Symphony'deki mühendislik emeği kenarlarda: retry, back-off, timeout, izolasyon ve sorun çıkınca agent'ı yeniden başlatan supervisor. Chat tarzı agent'ların üretimde tipik olarak düştüğü yer de tam burası.

Chat-Öncelikli Agent'tan Farkı

Karşıtlığı net koymak gerekiyor; çünkü Symphony'nin neden işe yaradığını açıklayan şey bu.

• Chat-öncelikli agent'lar bir insanın izlediğini varsayar. Kullanıcı bağlamı verir, takılınca yönlendirir ve işin bittiğine karar verir.
• Symphony agent'ları insanın başka bir yerle meşgul olduğunu varsayar. Bağlamı ticket taşır, bitti koşulunu test suite taşır; reviewer ancak review edilecek bir şey çıktığında çağrılır.

Bu, daha önce agentik kodlamanın orkestrasyon çağı yazımızda anlattığımız kayma. Symphony bu tezi uçtan uca savunan en temiz açık spec. Aynı zamanda Sakana Conductor çoklu agent orkestrasyon rehberindeki router-tarzı tasarımlarla doğal şekilde eşleşiyor: Symphony hangi ticket'a çalışılacağına karar veriyor, router ise o ticket'ın içindeki her alt görevi hangi işçinin üstleneceğini seçiyor.

Nerede Karşılığını Verir, Nerede Vermez?

Karşılığını verdiği durumlar

• Ekibiniz Linear ticket'larını zaten bir agent'ın aksiyon alabileceği detayda yazıyor olsun. Bulanık ticket bulanık kalır.
• Makul bir test suite'iniz olsun. Yoksa agent'ın işin bittiğine dair sinyali olmaz.
• Çok sayıda küçük ve birbirine benzer PR çıkarıyor olun (rename'ler, dependency güncellemeleri, copy düzeltmeleri, dar kapsamlı bug fix'ler).

Karşılığını vermediği durumlar

• Mühendislik değerinizin çoğu PR'larda değil, tasarım konuşmaları ve mimari kararlarda yatıyor.
• Test kapsamınız zayıf ve diff'i kim yazdı fark etmeksizin review'suz merge etmek riskli.
• Review yükünü karşılayamıyorsunuz: otonom bir agent, küçük bir ekibin okuyabileceğinden daha hızlı PR üretebilir.

Riski Düşük Bir Şekilde Denemek

1. 1SPEC.md'yi baştan sona okuyun. Bilinçli olarak kısa.
2. 2Elixir referans uygulamasını bir sandbox Linear projesi ve tek bir kritik olmayan repo karşısında ayağa kaldırın.
3. 3Yüksek hacimli ve iyi test edilmiş tek bir ticket tipi seçin (dependency güncellemesi iyi bir başlangıç). Symphony onu sürsün.
4. 4İki şeyi ölçün: time-to-PR ve reviewer saatleri. İkisi de lehinize hareket ediyorsa ticket tiplerini birer birer genişletin.
5. 5Ancak bundan sonra spec'i kendi yığınınızın diline taşımayı düşünün. Çoğu ekip için Elixir versiyonunu fork'lamak yeterli.

Coding agent'ların geniş haritasını hâlâ çıkarıyorsanız, OpenClaw 101 yeni başlayanlar rehberimiz Symphony'nin bir alt katmanında oturan yapı taşlarını (araçlar, skill'ler, izinler, bellek) anlatıyor.

Son Söz

Symphony, kod tarafında küçük; sonuç tarafında büyük. Linear'ı durum makinesi, Codex'i işçi ve bir BEAM supervisor'ını emniyet ağı olarak konumlayan OpenAI, prompt'ların değil, orkestrasyonun agent mühendisliğinde gerçekten ölçeklenen parça olduğunu gösteriyor. Bu spec'i birebir benimseyin ya da benimsemeyin, tasarım kopyalanmaya değer: zaten güvendiğiniz bir pano, yeniden başlatabildiğiniz bir agent ve insanın elinde kalan bir review adımı. Akıllı demo'dan ekibinizin gerçekten güvenebileceği bir coding agent'a giden yol bu.