← Radar

Konu: Altyapı3 dk okuma

OpenAI git'i bırakmadı, arkasını yeniden yazdı: Pando

Bu neden önemli?

Ajanlar kodu ucuzlattıkça darboğaz depoya kayıyor. Aynı soruna iki büyük şirketin iki zıt cevap vermesi, hangi kararın neyi kazandırıp neyi kaybettirdiğini görmek için iyi bir fırsat. Pando'nun yaklaşımı ayrıca git'in kendisine de dönüyor: Bazı iyileştirmeler upstream'e gidiyor.

Aynı sorun, iki cevap

Kod yazan ajanlar çoğaldıkça büyük şirketlerin depoları zorlanıyor. Bir ajan aynı anda onlarca dal açabiliyor, sürekli push ediyor, CI her değişiklikte kodu yeniden çekiyor. Anthropic bu sorunu yaşayınca git’i tamamen bırakıp kendi sistemi Scion’a geçti. Bunu Scion yazımızda anlatmıştık.

OpenAI 2 Kasım’da kendi hikâyesini yayımladı ve ters yönden gitti. Geliştiriciler ve ajanlar hâlâ normal git komutlarını kullanıyor. Değişen, o komutların konuştuğu sunucu. OpenAI bu yeni arka uca Pando diyor.

OpenAI’de ne bozuldu?

OpenAI’nin yazısına göre Codex, mühendislerin aynı anda çok daha fazla iş yürütmesini sağladı. Bu da geliştirme ortamlarından, araştırma işlerinden ve CI’dan gelen push, merge ve fetch sayısını katladı. 2025’in sonuna doğru monorepo’nun arkasındaki sistemler tıkanmaya başladı: Fetch ve push yavaşladı, birleştirmeler başarısız oldu. Birleştirmelerin başarı oranı zaman zaman yüzde 90’ın altına indi.

Ekip şu sonuca vardı: Sorun git’in kendisinde değil, depoya erişimi yöneten katmandaydı. O yüzden istemciyi ve protokolü bırakıp sadece o katmanı yeniden yazdılar.

Pando nasıl çalışıyor?

Fikir basit: Her şeyi tek bir depo kilidinin arkasında tutmak yerine, işi küçük ve bağımsız parçalara bölmek.

  • Yazmalar dal başına. Her push, gelirken doğrulanıp değişmeyen bir paket dosyası (packfile) olarak bir blob deposuna yazılıyor. Ardından meta veri deposuna o dalın yeni sürümü kaydediliyor. Çekişme sadece aynı dalın işaretçisinde oluyor, o da atomik olarak güncelleniyor. İki ajan farklı dallara push ediyorsa birbirini beklemiyor.
  • Okumalar paylaşılıyor. Git’in packfile URI özelliğiyle sunucu, paketin kendisini göndermek yerine “şu adresten indir” diyebiliyor. Pando’da istemciler paketleri bölgesel önbellekleri olan bir servisten indiriyor. Aynı paket binlerce istemciye tekrar tekrar sunuluyor.
  • Küçük paketler arkada birleşiyor. Her push küçük bir paket üretiyor. Bunlar arka planda kademeli olarak daha büyük paketlerde toplanıyor. Bu, veritabanlarındaki LSM ağaçlarından ödünç alınmış bir yöntem.

OpenAI’nin verdiği sayılar şöyle (bağımsız olarak doğrulanmış değil): Medyan push süresi (push’ların yarısının bu süreden kısa sürdüğü değer) yaklaşık yüzde 80 düşmüş, yani eskisinin beşte birine inmiş. Sistem günde yaklaşık 1 petabayt git verisi sunuyor, önbellek isabet oranı yüzde 99’un üstünde. Yazıya göre Pando, başlangıçtan üretime 10 haftada çıkmış: Çekirdeği bir mühendis tasarlamış, büyük kısmını Codex ajanları yazmış. Önce eski sistemin önünde bir vekil (proxy) olarak çalışmış, işler tek tek ona taşınmış.

Bedeli ne?

Pando tüm depo için tek bir sıralama garanti etmiyor. Bir dalın kendi geçmişi tutarlı, ama aynı anda birkaç dala bakan bir istemci, onları farklı anlardaki halleriyle görebilir. OpenAI bunu açıkça yazıyor: Kullanıcılar ve ajanlar dallar arasındaki küresel sıralamayla zaten ilgilenmiyor.

Bir bedel daha var: Milyonlarca dal olduğu için push sırasında istemciye sadece ana dal bildiriliyor. Uzun ömürlü dallarda bu, zamanla daha fazla verinin yeniden gönderilmesi demek.

Scion mu, Pando mu?

İkisi de herkese açık değil. Ama farkı öğretici:

  • Scion git’in “herkes tüm geçmişi indirir” varsayımını tamamen bırakıyor. Kazancı büyük, ama geçmek için kod incelemeden CI’a kadar tüm hattı değiştirmek gerekiyor.
  • Pando ekiplerin alışkanlıklarına ve git kullanan yüzlerce araca dokunmuyor. Değişiklik sunucuda kalıyor.

Pando’nun bir yan etkisi de herkese yarayabilir. OpenAI, paketleri paralel indirme gibi istemci değişikliklerini herkese açık git kopyasında tutuyor. Bunların bir kısmı asıl git projesine de girmiş.

Senin deponda bu ölçek sorunları muhtemelen yok. Ama birden fazla ajanı aynı depoda çalıştırıyorsan videodaki pratik tavsiye işe yarar: Her ajana ayrı bir git worktree aç, böylece birbirlerinin dosyalarını ezmesinler. Bunu kolaylaştıran araçları Worktrunk yazımızda anlattık.

Düşün

  • Senin ekibinde git’in arkasında hangi araçlar var (CI, kod arama, inceleme)? Git’i değiştirseydin bunların kaçını yeniden yazman gerekirdi?
  • Dallar arasında küresel bir sıralama olmaması senin iş akışında bir şeyi bozar mıydı?

Videoyu izle

Tıklayınca video YouTube'dan yüklenir; o ana kadar bu sayfa YouTube'a hiçbir istek göndermez.
Kaynaklar (6, İngilizce)

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.

Konu: Altyapı3 dkVideo: Better Stack

Rex: Ghostty'nin yaratıcısından, laptopu kapatınca da çalışmaya devam eden terminal

Mitchell Hashimoto'nun yeni şirketi Superlogical, ilk ürünü Rex'i beta olarak test ettiriyor. Rex bir terminal çoğullayıcı (multiplexer): Oturumların arka planda bir sunucuda yaşıyor, uygulama sadece onlara açılan bir pencere. Böylece başka bir makinede başlattığın Claude Code, laptopun kapalıyken de çalışmaya devam ediyor.

Konu: Altyapı3 dkVideo: The Pragmatic Engineer

Slack ve GitHub'ı ölçeklemek: Thundering herd, yük testi ve görünmeyen SQL

Maude Lemaire yaklaşık sekiz yıl Slack'te performans altyapısında, sonra GitHub'da veritabanı ölçeklemede çalıştı. Bu sohbetten üç somut ders çıkıyor: Herkesin aynı anda geldiği anlara hazırlanmak, yük testini gerçek bir tarayıcı yerine hafif sahte istemcilerle yapmak ve kodda görünmeyen sorguların bedelini fark etmek.