17 Ağustos'ta GitHub'da geniş çaplı hizmet sorunları yaşandı ve aynı gün Cursor, ücretli kullanıcılar için Origin early beta'yı açtı. Kod deposu, sürekli çalışan bir Agent'e entegre ediliyor; mevcut iş birliği altyapısı insan iş ritmine uygun şekilde tasarlanmıştır. Araştırmalar, depoların %40,2'sinde çakışan Agent PR'ler olduğunu ve merge çakışma oranının %41,7 olduğunu göstermektedir. Cursor Origin, Agent'ların yoğun yazma işlemlerine yönelik tasarlanmıştır ve tek bir depoda saniyede 22,6 commit desteği sunar; depo, PR, checks ve incelemeleri entegre eder. Origin, Git'in üzerindeki bir kontrol katmanı olarak konumlanmıştır ve yüksek frekanslı Agent iş birliği süreçlerini yeniden tasarlar. Musk'un altında yer alan xAI, X, SpaceX ve Cursor, tam bir AI üretim zinciri oluşturmuştur; Colossus hesaplama gücü sağlar, Grok modeli sağlar, Cursor kodu yürütür ve Origin mühendislik durumunu yönetir. GitHub, insan iş birliğinden Agent'lara doğru genişliyor; Cursor, Agent iş yüküne göre forge'yi yeniden tasarlıyor; bu iki yol arasındaki rekabet giderek artıyor.

Yazan ve kaynak: Leifengwang

Kod deposunun sahibi, insanlardan agente dönüşüyor.

17 Ağustos'ta GitHub'da geniş çaplı bir hizmet arızası yaşandı. Web, API, Actions, Çekme İstekleri, Git İşlemleri, Webhook'lar gibi temel bileşenler sırayla etkilendi ve bazı dönemlerde Web ve API istek hata oranları %20'ye yaklaştı.

Aynı gün içinde, Cursor, Origin erken beta sürümünü tüm ücretli planlara sırayla açmaya başladı. Depo, PR, kontroller, incelemeler, birleştirme ve otomasyonlar aynı sistemde birleştirildi ve Cursor'un belirlediği pozisyon da net: kod barındırma, “agent scale” için tasarlanmaya başlamıştır.

İlginç olan, bu iki şeyin aynı anda gerçekleşmesi ve bir değişimi büyütmek: kod deposu, giderek artan sayıda sürekli çalışan Agent'ı entegre ediyor, mevcut yazılım iş birliği altyapısı ise uzun süredir insan iş ritmine uygun şekilde tasarlanmıştı.

Bir insan birkaç saat kod yazabilir ve sadece birkaç commit üretir; bir Agent ise dakikalar içinde sürekli olarak değişiklik yapabilir, push edebilir, kontrolleri tetikleyebilir ve sonuçlara göre bir sonraki döngüye geçebilir. Commitlerin hızlanması sadece yüzeysel bir değişimdir; daha derin değişim, tüm yazılım üretim sisteminin zaman ölçeğinin sıkıştırılmasıdır.

GitHub ile karşılaşılan birçok yeni sorun, Origin'in çözmek istediği birçok sorun belki de buradan başlayacaktır.

01 GitHub ani olarak yaşlanmadı

GitHub doğduğunda, yazılım işbirliğinin kararlı bir temel birimi vardı: insan.

Bir mühendis birkaç saat kod yazıp bir kez commit yapıyor; bir özellik birkaç gün içinde geliştirilip bir PR oluşturuluyor; inceleme yarım saat içinde başlayabilir, yine de bir sonraki gün yapılabilir; CI'nın birkaç dakika içinde çalışması genellikle kabul edilebilir, merge çakışması biraz daha sonra ele alınsa bile sistemin tamamı anlamını kaybetmez.

Bu ritme dayalı olarak GitHub, Pull Request, Issue, Review, Actions, Webhook ve izin sistemlerini kurmuştur. Hatta uzun süredir yüksek commit oranına sahip Linux Kernel gibi projelerde dahi bu ritim, açıkça insan zaman ölçeğini taşımaktadır.

LWN'ye göre, Linux 7.0'un tüm geliştirme döngüsü boyunca 2362 geliştiriciden 14.251 adet non-merge commit yapıldı. Bu gönderimler, haftalarca süren bir geliştirme döngüsü içinde, e-posta tartışmaları, bakıcı incelemeleri, alt sistem entegrasyonları ve sürüm döngüsüyle birlikte gerçekleşti.

Cursor, 6. ay Origin yayın демонstrasyonunda gösterilen başka bir yük şekli: tek depo 22,6 commit/s.

Bu sayı, canlı demo verisine aittir ve bağımsız olarak tekrarlanmış bir üretim benchmark değildir; Origin'in gerçek iş yüklerinde aynı veri throughputunu uzun süre koruyabileceğini kanıtlayamaz. Ancak, Origin'in birçok Agent'in aynı kod durumuna sürekli olarak yazma yaptığı bir iş yüküne yönelik olduğunu göstermek için yeterlidir.

İnsan geliştiriciler doğal olarak akış sınırlamalarına sahiptir. Düşünme, kod yazma, toplantı yapma ve dinlenme, gönderimler arasında büyük boşluklar yaratır; bu nedenle insanlara göre tasarlanmış forge, sistemin büyük bir kısmını zamanın emmesine bırakabilir.

Agent bu sınırlamaya sahip değil.

Birçok Agent, aynı base SHA'dan aynı anda çatal oluşturabilir, ilgili dosyaları yakın bir zaman aralığında değiştirebilir, ardından birlikte push yapabilir, PR açabilir, kontrolleri çağırabilir, incelemeleri okuyabilir, kodu değiştirebilir ve tekrar push edebilir. Bir commit, indeks güncellemesini, izin kontrollerini, Webhook'u, CI'yi, kod taramasını, inceleme durumunu yenilemeyi ve mergeability hesaplamasını da tetikleyebilir.

Bu nedenle, Git nesne modeli değil, Git üzerindeki forge kontrol düzlemi: API, kimlik doğrulama, arka plan görevleri, CI tahsisi, Webhook, branch koruma, inceleme durumu, birleştirme kuyruğu ve bu bileşenler arasında oluşan kaskad yük, değişime maruz kalmalıdır.

GitHub'daki Agent PR'ler üzerine Temmuz'da yayınlanan bir araştırma, bu paralel biçimleri gözlemlemiştir. Araştırma, 2807 depoda yer alan 33.596 Agent PR'yi analiz etmiş ve depoların %40,2'sinde zaman olarak çakışan Agent PR'ler görülmüştür.

Örneklenen yeniden oynatılan eşzamanlı değişikliklerde, farklı Ajant PR'leri arasında metin birleştirme çakışması oranı %41,7, aynı Ajant tarafından oluşturulan eşzamanlı PR'lerde ise %19,8'dir.

Çoklu Ajan iş birliği, yeni eşzamanlılık kontrol sorunlarına yol açacaktır. GitHub'ın bu arızası, Ajan trafiğinin mevcut altyapıyı aşmış olduğunu kanıtlayamaz, ancak tam olarak bir gözlem penceresi sunar: yazılım üretimi düşük frekanslı insan olaylarından yüksek frekanslı makine olaylarına dönüştüğünde, kapasite planlaması, kuyruk tasarımı, durum yayılımı ve tutarlılık modelleri başka bir tür iş yüküyle karşı karşıya kalır.

Origin'in tasarımı buradan başlar.

02 Origin İşbirliği Maliyetini Yeniden Yazın

Eğer Origin, yalnızca bir Git deposu barındırma girişi eklerse, GitHub'ın zaten oluşturduğu geliştirici ilişkilerini, açık kaynak ekosistemini, kurumsal izin sistemini ve araç zincirini harekete geçirmesi zor olur.

Bu fırsat, Agent'in işbirliği maliyetini değiştirmesinden kaynaklanıyor. Stacked PR tipik bir örnektir.

İnsan geliştiriciler genellikle bir özelliği nispeten tamamlanmış bir PR olarak düzenlemeyi tercih eder. Her PR ayrılması, bir bağlam, bir inceleme ve bir dal bağımlılığı ekler. Bir değişiklik onlarca PR'ye bölünürse, insanlar bu ilişkileri yönetmek için büyük ölçüde çaba harcayabilir.

Agent'ların maliyet yapıları farklıdır. Bir değişiklik onlarca dosyayı kapsadığında, herhangi bir adımda hata oluşursa Agent, geniş bir bağlamı yeniden anlamak zorunda kalabilir. Daha küçük değişiklik setlerine bölündüğünde, şema, hizmet ve UI gibi değişiklikler net bağımlılıklar oluşturur ve her bir düğüm ayrı ayrı doğrulanabilir; hata durumunda yalnızca ilgili kısımlar işlenir.

Küçük PR, bu nedenle bir Agent'in kontrol noktası olabilir ve görevlere yerel doğrulama, yerel yeniden deneme ve bağımlılık izleme yetenekleri kazandırır.

Cursor, Graphite'ı satın almak bu bağlamda da anlaşılabilir. Origin'ın mevcut erken beta sürümü, Graphite'in yığınlı iş akışını tam olarak devralmamıştır; ancak Graphite'in uzun süredir yatırımı yapılan yığınlı PR'leri ve yığına duyarlı birleştirme kuyrukları, Agent'in kod üretme hızını artırdıktan sonra ortaya çıkan sonraki darboğazlara tam olarak karşılık gelmektedir.

PR sayısı arttıkça, merge queue'nun sorumlulukları da artacaktır. Agent A ve Agent B, aynı base SHA'dan aynı anda çalışabilir ve her ikisi de ayrı ayrı testleri geçebilir.

A ana işlemine girildikten sonra, B'nin test sonuçları yalnızca kodun eski durumda geçerli olduğunu kanıtlar, yeni ana işlemeye girildikten sonra hâlâ güvenli olduğunu kanıtlamaz. Bu nedenle, queue, değişen ana işlemeye göre aday durumları yeniden oluşturmalı, kontrolleri yeniden çalıştırmalı ve PR'ler arasındaki bağımlılıkları işlemelidir.

Çatışmalar, insan müdahalesiyle yavaş yavaş hattın geri kazanılabilir bir hata durumuna dönüşebilir. Cursor, /babysit gibi yetenekler sunarak PR geri bildirimlerini, başarısız kontrolleri ve çatışmaları sürekli olarak yönetir. Aday bir birleştirme sorun yaşarsa, ilgili bağlam, izole bir ortamda düzeltilip yeniden doğrulanmak üzere Agent'e yeniden verilebilir.

İnceleme de yapılandırılacaktır. İnsan işbirliği, doğal dil ve ekip deneyimine büyük ölçüde dayanırken, Agent uzun süre çalıştırıldığında hangi kontrolün başarısız olduğunu, hangi konuların henüz çözülmediğini, hangi politikanın karşılanmadığını ve şu anki head SHA'nın ne olduğunu açıkça okumak zorundadır.

Origin, repository, commit, checks, PR gibi nesneleri API aracılığıyla ortaya çıkarmıştır ve resmi incelemeyi normal tartışmadan ayırmıştır.

Bu yapılandırılmış durumlar ardından doğrudan Otomasyonlar tarafından tüketilebilir. Push, PR opened veya PR pushed olayları cloud agent'ını tetikler, yürütme sonuçları checks ve PR'ye geri yazılır, başarısızlık durumunda işlem sürecine girilir. MCP, hooks ve Agent API, dış araçların aynı olay zincirine katılmasını sağlar.

“GitHub’den Bağımsız Hale Getir” geçiş yolunu çözer. Takım, GitHub deposunu önce mirror'layabilir, GitHub’u source of truth olarak koruyabilir ve Agent iş akışlarını Origin’e taşıyabilir; iş akışı kararlı hale geldikten sonra senkronizasyonu kesip deposu Origin’in bağımsız olarak yönetmesini sağlayabilir.

Bu, Cursor'un önce Agent, PR, inceleme, kontroller ve Otomasyon'u üstlenmesine ve daha sonra daha fazla mühendislik durumunu kendi sistemine aktarmasına olanak tanır.

Origin’un ürün mantığı bu nedenle çok açık: Git sürüm kontrolünü sürdürür, Origin ise Git’in üzerinde yüksek frekanslı Agent işbirliğiyle çalışan kontrol katmanını yeniden yapmak ister.

03 Yaşlı Ma, bir AI üretim zinciri üzerinde çalışıyor

Geçen yılın başından beri, xAI, X, SpaceX ve Cursor arasında sergilenen seriler hareketler, daha tamamlanmış bir tedarik zinciri ilişkisi oluşturmuştur.

xAI, X'i satın alarak SpaceX sistemine dahil olur; Cursor, Colossus hesaplama kaynaklarını alarak ardından SpaceX sistemine dahil olur. Bunun yanı sıra, Grok 4.6 yayımlandı ve Origin açık hale geldi.

Bu yol, Musk'ın Tesla'da kullandığı dikey entegrasyon yaklaşımıyla benzerlik gösterir: dış halkaların iterasyon süresini uzattığında, ana arayüzleri aynı sistem içinde yer alacak şekilde yukarı ve aşağı akışa doğru genişletilir.

Agent şu anda karşılaştığı tam olarak bu sorun. Model, akıl yürütme görevini tamamlayabilir, ancak bir yazılım görevi, depoya erişmek, dosyaları değiştirmek, testleri çalıştırmak, CI'yi işlemek, incelemeleri almak, çakışmaları çözmek ve başarısızlık durumunda yürütmenin yeniden başlatılması gerektirir.

Eğer bu adımlar birden fazla sistemde dağıtılmışsa, her görev döngüsünde izinler, bağlam ve durum tekrar senkronize edilmelidir; arayüz maliyetleri, sürekli çalışan Agent döngüsünde birikmeye devam edecektir.

Colossus, Grok, Cursor ve Origin, bu zincirdeki farklı katmanlara karşılık gelir: Colossus hesaplama gücü sağlar, Grok model yetenekleri sağlar, Cursor kod Agent ve yürütme ortamı sağlar, Origin repository, PR, kontrol ve inceleme durumlarını saklar.

Kod üretimi, modelin karar vermesi, Cursor'un bu kararları gerçek değişikliklere dönüştürmesi ve Origin'in proje durumunu kaydetmesi ve sonraki iş birliği kontrolünü üstlenmesiyle sürekli bir zincir oluşturur.

Bu, Grok 4.6'nın değerlendirilme ölçütünü de değiştirdi. Model yetenekleri hâlâ önemli, ancak Agent sistemlerinin çıktısı, yürütme ortamına ve mühendislik altyapısına da bağlıdır. Bir kod, kalitesi iyi olsa bile, ardından insan tarafından kopyalanıp, yürütülmeli, kontrol edilmeli ve yeniden gönderilmeliyse, model yetenekleri sürekli olarak büyütülemez.

Model kullanılabilir seviyeye ulaştıktan sonra, kodun hızlıca yürütme, doğrulama ve birleştirme süreçlerine girmesi, tüm sistemin çıktılarını giderek etkileyecektir.

X, bu zincirdeki konumu hâlâ belirsiz. Gerçek zamanlı içerik, kullanıcı ilişkileri, kimlik ve dağıtım ağına sahip; gelecekte görev kaynağı ve dağıtım girişi olabilir; şu anlık olarak Grok Bot, ürün formatı açısından sadece “pasif olarak soru bekleyen bir sohbet robotu” olarak düşünülenin ötesinde, sürekli görev yürütme katmanına daha yakındır.

Cursor, Origin neden gerekiyor? Bunun nedeni, kod üretildikten sonra bir sistemin mühendislik durumunu uzun süre saklaması, değişiklikleri koordine etmesi, sonuçları doğrulaması ve sonraki yürütme adımlarıyla bağlantı kurmasıdır. Bu konum dışarıda kalırsa, Agent yazılım zincirinde kritik bir bağımlılık oluşur.

Ancak Origin, tam olarak bu katmanı tamamlıyor.

04 GitHub ve Origin arasındaki ayrılık

GitHub, yığılmış PR'leri, birleştirme kuyruğunu ve REST API'yi zaten sunuyor ve Copilot kodlama aracını Sorunlar, Actions, PR'ler ve kod incelemelerine sürekli entegre ediyor. Fonksiyon listesine yalnızca bakıldığında, iki tarafın gelecekte giderek daha fazla çakışma yaşayacağı görülüyor.

Farklar temel alınan tasarımdan kaynaklanmaktadır.

GitHub, olgun bir insan geliştirici ağı üzerine kuruludur, bu nedenle Agent'in mevcut Issue, PR, Actions ve branch koruma sistemlerine girmesi daha doğal bir yoldur.

Cursor, yüksek yoğunluklu Agent işbirliğiyle bu bileşenleri yeniden tasarlayabilir. Bir depoda uzun süre onlarca Agent çalıştırılıyorsa, PR sayısı artar, değişiklikler daha ince hale gelir ve durum değişiklikleri hızlanır; bu durumda inceleme, kontroller, birleştirme ve yetki sistemleri, makine davranışlarına göre yeniden düzenlenmelidir.

PR'nin rolü de bununla birlikte genişleyebilir. Ana olarak okunmak üzere yazılmış bir kod değişikliğinden, diff, bağımlılıklar, test kanıtları, kaynaklar, risk seviyesi ve onay durumunu içeren bir mühendislik iş birimi haline gelebilir.

İnsanların sorumlulukları daha fazla kural katmanına girecektir: Hangi dizinler otomatik olarak değiştirilebilir, bağımlılık yükseltmeleri kaç versiyon atlayabilir, veritabanı geçişleri için hangi doğrulamalar gerekir, kimlik doğrulama ve ödeme ile ilgili kodlar hangi onayları geçmelidir, Agent'in durdurulması gereken durumlar nelerdir.

Buna göre, Agent-native forge göstergeleri de değişecektir. 22,6 commit/s dikkat çekici olsa da, commit sayısı kendisi yazılım üretkenliğini temsil edemez. Daha anlamlı göstergeler, görevin sisteme girdiğinden merge edilene kadar geçen süre, başarısızlıktan sonra yerel kurtarma yeteneği, politika içinde otomatik olarak tamamlanan değişikliklerin oranı, kabul edilen değişimlerin hesaplama maliyeti ve yüksek riskli değişiklikler için harcanan insan dikkatidir.

Origin, depo, kontrol, inceleme, izinler ve olayların birleşmesiyle oluşan yazılım üretim kontrol yüzeyini kontrol etmek istiyor.

Bu nedenle GitHub ve Origin arasındaki rekabet, GitHub'ın olgun insan işbirliği sisteminden Agentlere doğru genişlemesi ve Cursor'ın Agent iş yüküne göre forge'u yeniden tasarlaması yönünde ilerleyecektir.

05 Eski Ataltı bir sonraki katda

Bununla birlikte, Grok 4.6'nın yayınlanmasından sonra dışarıda benchmark etrafında kod yetenekleri, çıkarım puanları ve fiyatlar üzerine tartışmalar devam etmektedir. Ancak Colossus, Grok, Cursor ve Origin'i bir arada değerlendirirsek, bu strateji aslında modelin ardından gelen yazılım üretim zincirine kadar uzanmaktadır.

Colossus hesaplama gücü sağlıyor, Grok çıkarım yapıyor, Cursor model yeteneklerini kod değişikliklerine dönüştürüyor, Origin sonraki deposu durumunu, PR'leri, kontrolleri ve incelemeleri ele alıyor. Model yetenekleri arttıkça, kazanç doğrudan yürütme zinciri boyunca aktarılabilir; hatta tek nesil model arasında açık bir fark olmasa bile, sonraki altyapı hala birikim yapmaya devam edebilir.

Bu nedenle, Grok 4.6'nın bugün bir listede hangi sıradaki olduğu sadece geçici bir sonuç olabilir. Daha uzun vadeli soru, modeli, yürütme ortamını ve yazılım mühendisliği durumunu sürekli çalışan bir üretim sistemi haline getirebilecek kimse olacak.

Diğerleri hâlâ bu tur modelin kimin daha akıllı olduğunu tartışıırken, Lao Ma zaten bir kat aşağıya inmişti.