Uzun Süre Çalışan Otonom Kodlamanın Ölçeklendirilmesi

 (cursor.com)
18 puan yazan GN⁺ 2026-01-16 | 1 yorum | WhatsApp'ta paylaş
  • Cursor, otonom kodlama ajanlarını haftalar boyunca paralel çalıştırarak büyük ölçekli projeleri tamamlayıp tamamlayamayacağını deneyimledi
  • Başlangıçta dinamik işbirliği yapısı kullanıldı, ancak lock çakışmaları ve iş tekrarları nedeniyle darboğazlar oluştu
  • Daha sonra roller Planlayıcı (Planner) ve Çalışan (Worker) olarak ayrıldı; bu da paralellik ve verimliliği büyük ölçüde artırdı
  • Bu yapı ile bir web tarayıcısı sıfırdan geliştirildi; yüzlerce ajan 1 milyondan fazla satır kod yazdı
  • Deney sonuçları, basit yapı ve uygun prompt tasarımının uzun vadeli otonom kodlamayı ölçeklendirmenin anahtarı olduğunu gösterdi

Tek ajanın sınırları

  • Günümüzün tek kodlama ajanı, basit görevlerde verimli olsa da karmaşık projelerde yavaş kalıyor
    • Birden fazla ajanı paralel çalıştırmak doğal bir ölçekleme yönü, ancak görev koordinasyonu zor
  • Başlangıçta önceden planlama olmadan dinamik işbirliği yöntemi denendi
    • Her ajanın diğer ajanların durumuna bakıp bir sonraki işi kendisinin belirlediği bir yapı

İşbirliğinden öğrenilenler

  • Tüm ajanların eşit yetkiye sahip olduğu ve paylaşılan dosyalar üzerinden çalışmayı koordine ettiği bir yapı kuruldu
    • Her ajan diğer ajanların durumunu kontrol ediyor, iş alıyor ve durumunu güncelliyordu
    • Tekrarı önlemek için lock mekanizması kullanıldı
  • Sorunlar
    1. Ajanlar lock'u uzun süre elinde tuttuğunda ya da serbest bırakmadığında, toplam hız 20 ajandan yalnızca 2–3'ü çalışıyormuş seviyesine düştü
    2. Lock tutulurken başarısız olma ya da lock olmadan dosya değiştirme gibi durumlar sistem kararsızlığına yol açtı
  • Ardından iyimser eşzamanlılık denetimi (optimistic concurrency control) modeline geçildi
    • Okuma serbest bırakıldı, yazma ise durum değişikliğinde başarısız olacak şekilde ayarlandı
    • Bu yaklaşım basit ve kararlıydı, ancak hiyerarşisiz yapıda ajanlar riskten kaçınan davranışlar sergiledi
    • Zor problemlerden kaçınıp yalnızca küçük düzeltmeleri tekrarladılar; ilerleme üretmeyen iş döngüleri oluştu

Planlayıcı ve çalışan yapısı

  • Roller ayrılarak hiyerarşik bir pipeline yapısına geçildi
    • Planlayıcılar (Planners): kod tabanını inceleyip görev üretiyor, gerekirse alt planlayıcılar oluşturuyor
    • Çalışanlar (Workers): yalnızca verilen görevi yerine getiriyor ve tamamladıktan sonra değişiklikleri push ediyor
  • Her döngüde bir değerlendirici ajan (judge) bir sonraki aşamaya geçilip geçilmeyeceğine karar veriyor
    • Bu yapı işbirliği sorunlarının çoğunu çözdü ve büyük ölçekli proje ölçeklenebilirliği sağladı

Uzun süreli çalışma deneyleri

  • Deneyin hedefi: bir web tarayıcısını sıfırdan geliştirmek
    • Yaklaşık 1 hafta çalıştırıldı ve 1.000 dosyada 1 milyondan fazla satır kod yazıldı
    • Yüzlerce çalışan aynı branch'e aynı anda push etti, ancak çakışmalar minimumda kaldı
    • Ortaya çıkan kod GitHub'da yayımlandı
  • Ek deneyler
    • Solid → React geçişi: 3 haftada +266K/-193K değişiklik, merge edilebilirlik doğrulandı
    • Video render iyileştirmesi: Rust sürümüyle 25 kat hız artışı, zoom·pan·motion blur özellikleri eklendi
    • İlgili kodun yakında production'a alınması planlanıyor

Temel çıkarımlar

  • Milyarlarca token kullanımı sonucunda sistem tamamen verimli olmasa da beklenenden daha yüksek performans gösterdi
  • Model seçimi, uzun süreli otonom çalışmanın kilidi
    • GPT-5.2, odağı koruma, talimat izleme ve doğru uygulamada üstün performans gösterdi
    • Opus 4.5 hızlı sonlandırma eğilimi gösterdi
    • GPT-5.2, planlayıcı rolünde GPT-5.1-codex'ten daha uygun bulundu
    • Her rol için en uygun model ayrı ayrı seçildi
  • Karmaşıklığı azaltmak performansı artırdı
    • Kalite bütünleştiricisi (integrator) rolü tersine darboğaz yarattı
    • Çalışanlar çakışmaları kendi başlarına çözebildi
  • Basit yapı en etkili seçenek oldu
    • Dağıtık sistem teorisi ya da organizasyon tasarımı modelleri yalnızca kısmen işe yaradı
    • Yapı çok az olduğunda çakışma ve tekrar oluşuyor, çok fazla olduğunda ise kırılganlık artıyor
  • Prompt tasarımı sistem davranışını belirleyici ölçüde etkiledi
    • Uzun süreli odağı koruma, patolojik davranışları engelleme ve işbirliğini teşvik etmede kilit rol oynadı

Gelecek görevler

  • Çok ajanlı koordinasyon hâlâ zor bir problem
    • Planlayıcıların görev tamamlandığında bir sonraki adımı otomatik planlaması için iyileştirme gerekiyor
    • Bazı ajanlar aşırı uzun süre çalıştığından periyodik yeniden başlatma gerekiyor
  • Ancak temel soru, yani “Ajan sayısını artırmak otonom kodlamayı ölçeklendirebilir mi?” konusunda
    • Yüzlerce ajanın haftalar boyunca işbirliği yaparak gerçek ilerleme sağlayabildiği doğrulandı
  • Bu teknolojinin gelecekte Cursor'un ajan özelliklerine yansıtılması planlanıyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-01-16
Hacker News yorumları

  • Steve Yegge’nin Welcome to Gas Town yazısıyla ilgili bir şey üzerinde çalıştığım için bunu ilgiyle okudum

  • Kısa süre önce paylaştığım LLM tahminleri yazısında, 2029 civarında yapay zeka destekli kodlamayla tarayıcı yapmanın şaşırtıcı olmayacağını söylemiştim; Cursor’ın bu projesi de ikinci deneme sayılır
    Başka bir örnek bu Reddit gönderisinde görülebilir

    • Akıllıca bir uygulama yapılacaksa, muhtemelen GitHub’daki Chromium kaynak kodu alınır, gereksiz özellikler çıkarılır ve sadece görünüşü değiştirilir diye düşünüyorum
    • 2029’a geldiğimizde, pelikanlar için tarayıcıyı yapay zekanın yaptığına dair şakalar yapılabilecek kadar çıtayı yükseltmemiz gereken bir noktadayız
    • Reddit’teki örnek koda yaklaşık 5 dakika baktım; metin yerleşimi hesaplaması ve bidi (çift yönlü metin) işleyişi berbattı. Standartları dikkate almayan bir “tarayıcıya” gerçek tarayıcı demek zor
    • Etkileyici ama açık kaynak tarayıcı kodunun modelin eğitim verisinde yer alıp almadığını merak ediyorum
    • Tahmininin tutmadığını söyleyip bir hafta sonra aynı podcast’e yeniden çıkıp yeni tahminler yapmasının nedeni neydi, merak ettim

  • Deponun testlerini bizzat çalıştırdım; hata ve uyarılarla doluydu, CI da uzun zamandır başarısızdı. Bu durumda buna “başarılı bir örnek” demek ne kadar doğru emin değilim. Tam otonom kodlamadan ziyade insan merkezli yardımcı yaklaşımın daha gerçekçi olduğunu düşünüyorum

    • Kod tabanı yüzlerce, binlerce küçük dosyaya bölünmüş, bu yüzden yapıyı kavramak neredeyse imkansızdı. README de özensizdi ve bağımlılıkların açıklaması yoktu. Kod yapay zeka tarafından üretilmiş olabilir ama bakım tarafı tam bir kabus
    • Yazarı da tam otonom kodlamayı ciddi bir ürünleştirme hedefinden çok LLM sınırlarını deneyi olarak görmüş gibi. Şu anda ancak küçük projelerde “tek başına fena olmayan kod” üretebilen bir aşamadayız
    • CI başarısız PR’ı doğrudan merge etmiş olmaları, insan seviyesinde kaliteye ulaşmış sayılabilecekleri yönünde bir şakayı hak ediyor
    • “Yavaş” ifadesinin tam olarak ne anlama geldiği de belirsiz. GPU hızı mı? İnsandan yavaş olması mı? Sonuçta bu bana yapay zeka balonunu şişiren bir yazı gibi geldi

  • O PR’ı neden hâlâ merge etmediklerini merak ediyorum. Yapay zeka ajan sürülerinin uzun vadede karmaşık yazılımları tamamladığı bir gelecek heyecan verici, ama şu anki örnek fazla zayıf. İnsanla işbirliği yapılan noktalar daha önemli

    • Benim deneyimimde ajanlar yakınsamıyor; giderek daha da dağınık bir kod canavarı üretiyorlar
    • Çalışan tek bir basit projeyi bile yayımlamamış olmaları, bunu yatırımcı çekmeye yönelik bir yem gibi gösteriyor. Yapay zeka patlaması dotcom balonuna benziyor ama bu kez para kazanmaya daha fazla odaklı gibi
    • Tarayıcı, Excel ya da Windows 7 gibi örneklerin bir kısmı eğitim verisine girmiş olabilir ama bununla tamamen kopyalamak mümkün değil
    • Kod o kadar büyük ve sorunlarla dolu ki inceleme yapmak fiilen imkansız. Sonunda geriye sadece YOLO usulü merge kalıyor
    • Benim ilgimi çeken şey yakınsama koşulları. Kod artsa da azalsa da, önemli olan en uygun duruma gelip kararlı hale gelmesi

  • Zorluk seviyesini kademeli artırarak deney yapmamış olmaları üzücü. React CRUD → Paint klonu → dosya yöneticisi → tarayıcı şeklinde ilerleselerdi gelişim aşamaları çok daha net görülebilirdi

  • Ben de benzer bir yaklaşımla tjs oluşturmuştum. Dünyanın en hızlı ve en doğru JSON Schema Validator’ı; git subtree kullanan planner/delegate deseni etkili olmuştu. Standartları ve testleri iyi tanımlanmış yazılımlarda yapay zeka ajanları çok hızlı şekilde yeniden yazım ve optimizasyon yapabiliyor
    İlgili komutlar spawn-perf-agents.md içinde görülebilir

  • Tarayıcıyı sıfırdan yapmak çok zor ama yazıda sunulanlar detaylı analiz açısından yetersizdi. Sadece “derleniyor” düzeyindeyse bunun anlamı sınırlı. Asıl doğrulama, bir sonraki değişikliği kararlı şekilde birleştirebilip birleştiremediğinizdir

    • Ajan kodlamasında asgari eşik şu sırayla gider: “derleme başarılı” → “normal çalışıyor” → “uç durumları işliyor”. İnsandan daha az hata üreten bir sistem en az 1 yıl boyunca kararlı biçimde çalışmadan güven vermesi zor
    • Gerçekte CI da başarısız olduğu için, “derleniyor” iddiasından bile şüpheliyim

  • Bloga göre trilyonlarca token kullanılmış; bunu OpenAI API fiyatlarıyla hesaplarsanız on milyonlarca dolarlık bir ölçeğe denk geliyor. Bu seviyede, belki de doğrudan tarayıcı ekibine bağış yapmak daha mantıklı olurdu

  • Bizzat derlemeyi denedim ve 100’den fazla derleme hatası aldım. Commit’lerin çoğu CI başarısız durumdaydı; gerçekte yapılan şey de çeşitli açık kaynak kütüphanelerini bir araya getirmekti.
    quickjs, wgpu, winit, egui, html parser gibi mevcut bileşenler aynen alınmıştı ama CEO bunu “özel bir JS VM” gibi anlatarak yanlış bir izlenim oluşturuyordu
    Yine de yapay zekanın bu entegrasyonu otonom biçimde gerçekleştirmiş olması etkileyici

    • Kullanılan bileşenler Rust tabanlı tarayıcı blitz ile çok benzer görünüyor; bu da eğitim verisinde yer almış olabileceğini düşündürüyor
    • “Çalışıp çalışmaması önemli değil, ekran görüntüsü alıp yatırımcıya göster” tarzında startup usulü bir şaka da yapılmıştı
    • 60 bin civarı workflow içinde sadece yaklaşık 1 bini başarılı olmuş. Bu da pratikte doğrulanmamış bir kod yığını gibi görünüyor
    • Sonu da “herkes kendi özel Cursor’unu yapsın” esprisiyle bitiyor

  • Kod çok kırılgan ve kararsız görünüyordu. Örneğin render_placeholder fonksiyonu, sadece frame buffer’ı dolduran geçici bir kod gibi duruyor.
    Böyle bir kodun gerçekte ne işe yaradığını ve test başına token/zaman maliyetinin ne kadar olduğunu merak ediyorum

    • Etiket özniteliklerini çıkarma yöntemi de şu kısımda görüldüğü gibi biraz tuhaftı
    • Ama Cursor bunu otomatik olarak düzeltebiliyorsa, bu tür kırılganlıklar uzun vadede bağımlılığı artırmaya yönelik bir strateji de olabilir