Paralel Claude Ekibiyle C Derleyicisi Geliştirmek

• 16 Claude ajanı, paralel iş birliğiyle Rust tabanlı bir C derleyicisini tamamladı ve Linux 6.9 çekirdeğini derleyebilecek seviyeye ulaştı
• Yaklaşık 2.000 oturum ve 20 bin dolar maliyetle 100 bin satırlık kod üretildi; x86, ARM ve RISC-V mimarileri destekleniyor
• Ajanlar, otomatik döngü harness'i üzerinden insan müdahalesi olmadan sürekli çalıştı; test, paralelleştirme ve rol paylaşımı yapısıyla verim artırıldı
• Ortaya çıkan sonuç, GCC uyumluluğu ve yüksek test geçiş oranı gösterdi; ancak 16 bit x86 kod üretimi, bağlayıcı ve optimizasyon kalitesi gibi alanlar henüz tamamlanmış değil
• Bu deney, otonom LLM ekiplerinin sınırlarını ve potansiyelini doğrulayan bir örnek oldu; bundan sonra tam otonom geliştirme ortamlarında güvenlik ve kalite yönetimi temel mesele olarak öne çıkıyor

---

Ajan ekibi tabanlı C derleyicisi projesine genel bakış

• Birden fazla Claude örneği paralel biçimde birlikte çalışarak tek bir kod tabanı geliştirdi
  • İnsanların gerçek zamanlı müdahalesi olmadan otonom olarak kod yazma, test etme ve düzeltme döngüsü tekrarlandı
• Hedef, Rust ile yazılmış bir C derleyicisini tamamlayıp Linux çekirdeğini doğrudan derlemekti
• Toplam 16 ajan, yaklaşık 2.000 oturum, 200 milyon giriş tokenı ve 140 milyon çıkış tokenı kullanıldı
• Sonuçta 100.000 satırlık bir derleyici ortaya çıktı; Linux 6.9 çekirdeği ve önemli açık kaynak projelerini (QEMU, FFmpeg, SQLite, Redis vb.) derleyebiliyor

Uzun süreli çalıştırma için Claude harness tasarımı

• Mevcut Claude Code insan girdisi gerektiriyordu; ancak sonsuz döngü yapısına sahip otomatik bir çalıştırma harness'i ile otonom ilerleme mümkün oldu
  • Her iş tamamlandıktan hemen sonra bir sonraki görevi alan otomatik tekrar yapısı
  • Çalışma sırasında Claude'un yanlışlıkla pkill -9 bash çalıştırıp kendi sürecini sonlandırdığı bir örnek de yaşandı
• Paralel çalışma yapısı, Docker konteynerleri ve Git senkronizasyonundan yararlandı
  • Her ajan /workspace içinde çalıştıktan sonra /upstream konumuna push yaptı
  • Metin dosyası tabanlı lock mekanizmasıyla iş çakışmaları önlendi
  • Merge çakışmaları Claude tarafından doğrudan çözüldü

Paralel Claude çalışma modeli

• Paralel çalışmanın avantajı, eşzamanlı hata ayıklama ve rol ayrışması oldu
  • Bazı ajanlar kod yazarken, bazıları dokümantasyon, kalite yönetimi ve performans optimizasyonu üstlendi
• Herhangi bir iletişim katmanı ya da merkezi koordinatör yoktu; her ajan bir sonraki görevi otonom olarak seçti
• Git geçmişinde, her ajanın iş lock kayıtları ve ilerleme dokümanları yer aldı

Claude ekip programlamasından çıkarılan dersler

Yüksek kaliteli testlerin önemi

• Claude kendisine verilen testlere göre otonom çalıştığından, doğrulayıcının doğruluğu kritik öneme sahipti
  • Yanlış pozitifler varsa geliştirme yanlış yöne kayabiliyor
• Sürekli entegrasyon (CI) hattı kurularak mevcut işlevlerin bozulmaması zorunlu olarak doğrulandı
• Kaliteyi güvenceye almak için açık kaynak build script'leri ve compiler test suite kullanıldı

Claude'un bakış açısından ortam tasarımı

• Her ajan bağlamı olmayan yeni bir konteynerde başladığı için, ilerlemenin dokümante edilmesi zorunluydu
  • README ve ilerleme dosyalarının sürekli güncellenmesi istendi
• Bağlam kirlenmesini önlemek için log'lar minimumda tutuldu, hatalar ise ERROR anahtar sözcüğüyle ayırt edilebilir biçimde kaydedildi
• Zaman farkındalığının olmamasını telafi etmek için --fast seçeneğiyle %1 ila %10 örnek testler çalıştırıldı

Paralelleştirmenin sınırları ve çözümler

• Birbirinden bağımsız çok sayıda test olduğunda paralelleştirme kolaydı; ancak Linux çekirdeği derlemesi tek ve dev bir iş olduğu için çakışmalar yaşandı
• Çözüm olarak GCC referans derleyici oracle'ı kullanıldı
  • Bazı dosyalar GCC ile, geri kalanı ise Claude derleyicisiyle derlendi
  • Hata olduğunda problemli dosya daraltılarak paralel hata ayıklama yapılabildi
  • Sonrasında delta debugging ile karşılıklı bağımlı hatalar tespit edildi

Ajan rollerinin ayrıştırılması

• Yinelenen kodun kaldırılması, performans iyileştirme, verimli kod üretimi, Rust yapısının iyileştirilmesi ve dokümantasyon gibi alanlarda uzmanlaşmış rol paylaşımı yapıldı
• Paralellik ile uzmanlaşmanın birleşmesi, büyük ölçekli kod tabanlarının yönetim verimliliğini artırdı

Opus 4.6 modelinin performans değerlendirmesi

• Opus 4.5 sürümüne kadar büyük projeleri derlemek mümkün değilken, Opus 4.6 ile ilk kez pratik düzeye ulaşıldı
• Clean-room implementasyon ile internet erişimi olmadan yalnızca Rust standart kütüphanesi kullanıldı
• GCC torture test suite testlerinin %99'u geçildi, Doom çalıştırılabildi
• Sınırlamalar:
  • 16 bit x86 kod üretilemiyor, bu yüzden önyükleme aşamasında GCC çağrısı gerekiyor
  • Assembler ve linker tamamlanmamış durumda, bazı hatalar bulunuyor
  • Üretilen kodun verimliliği düşük, GCC optimizasyonları kapalı seviyeden bile daha verimsiz
  • Rust kod kalitesi makul olsa da uzman seviyesinde değil

Otonom ajan ekiplerinin sınırları ve potansiyeli

• Proje, LLM'lerin otonom iş birliğinin sınırlarını ölçmek için bir benchmark niteliği taşıyor
• Tam otonom geliştirme, kalite güvencesi ve güvenlik riskleri barındırıyor
  • Yalnızca testleri geçmenin işi tamamlanmış sanılmasına yol açma riski var
• İnsan doğrulaması olmadan kod dağıtımı konusundaki kaygılar dile getirildi
• Buna rağmen, otonom ajan ekiplerinin karmaşık projeleri tamamlayabileceği gösterildi
• Gelecekte model ilerlemeleriyle birlikte güvenli otonom geliştirme stratejileri temel görev haline gelecek

Geleceğe bakış

• Dil modellerindeki gelişim, IDE otomatik tamamlama → fonksiyon tamamlama → eşli programlama → otonom proje yürütme çizgisinde ilerliyor
• Agent teams, tam otonom geliştirmenin mümkün olabileceğini gösteriyor
• Teknolojik gelişimin hızı şaşkınlık yaratırken, aynı zamanda yeni etik ve güvenlik çerçevelerine ihtiyaç vurgulanıyor
• Olumlu kullanımın olumsuz riskleri dengelemesi bekleniyor; ancak yeni geliştirme paradigmasına hazırlık gerekli

[mammal]

Bu proje C ile yazılmış bir derleyici değil, yalnızca Rust standart kütüphanesiyle yapılmış bir proje; dolayısıyla gcc/clang C kodunun eğitim verisinde bulunduğu eleştirisi bana biraz kale direklerini taşımak gibi geliyor. Her hâlükârda gerçekten etkileyici.

[GN⁺]

Hacker News yorumları

• Ben Google'da yaklaşık 10 yıl boyunca Clang ile Linux çekirdeğini derleme işi yaptım. Bu proje(clangbuiltlinux.github.io) ise bir LLM'nin 2.000 oturum ve 20 bin dolarlık API maliyetiyle aynı işi başardığını söylüyor. Gerçekten açılışa kadar çalıştığı söylenince şaşırtıcı. Ancak üretilen kodun verimliliği düşük ve GCC'nin optimizasyonsuz sürümünden bile daha verimsiz deniyor. Yine de gerçekten harika bir proje

  • Harika ama belki de başkasının ödevini kopyalamış bir sonuç olabilir
  • Opus'un 16 bit x86 kod üretecini hayata geçiremediği için açılış aşamasında GCC'yi çağıran bir hile kullandığı söyleniyor. Gerçekten boot etmiş sayılır mı, emin değilim
  • Bu, sanki Ken Thompson'ın “Trusting Trust” döneminin geri gelişi gibi. AI yakında derleyicinin içine kendisini yerleştirebilir
  • 20 bin dolar harcandıysa, o parayla kısa süreliğine 8 kıdemli geliştirici tutulabilirdi. Pazarlama maliyeti fazla yüksek görünüyor ve gerçek gelir modeli belirsiz

• Cursor tarayıcı projesinden çok daha gerçekçi bir yaklaşım. Buna clean-room implementasyonu denmiş; internete erişim olmadan yalnızca Rust standart kütüphanesi kullanılmış. 100 bin satırlık derleyicinin Linux 6.9, QEMU, FFmpeg, SQLite, Postgres ve Redis'i derleyebildiği söyleniyor.
  Opus 4.5 ilk kez büyük testleri geçebildi ve bu sonuç da sanki o sınırların neredeyse tamamını kullanmış gibi.
  Pek çok kısıta rağmen bunun etkileyici bir deney olduğunu düşünüyorum

  • “Clean-room implementasyonu” ifadesi abartılı görünüyor. Model zaten internet genelindeki C derleyicileri üzerinde eğitildiği için bunu özellikle söylemeye gerek yok
  • Bu sonucu yalnızca bugünkü seviyeye bakarak değerlendirmek biraz yazık. Son birkaç aydaki gelişim hızı düşünülürse, 1 yıl sonra hayal edilemeyecek bir noktada olabiliriz
  • Aslında clean-room'dan çok, LLM'nin eğitim sırasında sıkıştırdığı bilgiyi test tabanlı olarak dışa vurmasının sonucu gibi duruyor
  • Sonuçta GCC ya da Clang koduyla eğitilmiş bir model olmalı; gerçek kod benzerliğinin ne kadar olduğunu merak ediyorum
  • Bana göre etkileyici ama gerçek kullanıcı açısından daha az ilgi çekici. LLVM'ye yeni bir ISA eklemek ya da yeni bir dil için derleyici yapmak daha anlamlı olabilir

• İlk başta “vay be, müthiş” dedim ama sonra fikrim değişti. C derleyicisi, spesifikasyonu çok katı bir yazılım olduğu için LLM'lerin ele alması görece kolay bir alan.
  Ama yaptığımız işlerin çoğu, gereksinimlerin belirsiz olduğu ve hedeflerin sürekli değiştiği ortamlarda geçiyor. Böyle alanlarda da iyi çalışıp çalışmayacağını merak ediyorum

  • “C derleyicisi nettir” sözü komik geliyor. Ortada ne kadar çok “unspecified behavior” var
  • Kod üretiminin testlere uydurulması, ML model fitting işine benziyor. İnsanların hâlâ testleri tasarlaması ve doğrulaması gerekiyor

• Sonucun kusursuz olması gerektiği beklentisi tuhaf geliyor. Mümkün olması bile başlı başına şaşırtıcı. Böyle denemeler bir sonraki Opus veya Sonnet eğitimine yansır ve belki bir gün kendi kendine verimli derleyiciler üreten modeller çıkar

  • Ben de aynı düşünüyorum. “Bir köpeğin ne kadar iyi dans ettiğinden çok, dans ediyor olması şaşırtıcıdır”
  • Bugünlerde üretken yapay zekaya karşı tepki çok büyüdü; ufak bir kusur bile olsa hemen ‘AI çöpü’ diye damgalanması üzücü. Bu sadece bir demo ve kavram kanıtı sonuçta

• Bu projenin Linux çekirdeği, QEMU, FFmpeg, Redis ve Doom'u derleyebildiği söyleniyor. Gerçekten şaşırtıcı.
  Ama bu tür ajan sistemleri, test edilebilir alanlarda iyi çalışsa da iş kararları gibi bağlam gerektiren alanlarda sınırlı kalıyor

  • Zaten internetin tamamıyla eğitilmiş bir modele “clean-room implementasyonu” demenin anlamlı olup olmadığı şüpheli
  • Sonraki adım, AI'nin gerçekten iş bağlamını anlayıp işletmesi olacak. Örneğin Vending-Bench gibi benchmark'lara bakılırsa, AI ürün yöneticisinin kullanıcı görüşmeleri, deneyler ve roadmap önerilerini otomatik yaptığı gün çok uzak olmayabilir

• Harika bir proje ama “clean-room” vurgusu olmasa daha iyiymiş. Sonuçta telifli kodla eğitilmiş bir model, yani bunun tersine daha yakın

  • Ama insanlar da mevcut kod tabanlarını öğrenip, bu bilgiye dayanarak clean-room implementasyonu yapabiliyor
  • İnsanların şirkette öğrendiği bilgiyi başka yerde yeniden kullanması gibi, LLM de eğitim verisini dönüştürücü biçimde yeniden kuruyor. Doğrudan kopya değilse mesele farklı

• GitHub issue'ya göre sorun include yolunun eksik olmasından kaynaklanıyor. Derleyicinin kendisi normal

  • Muhtemelen sadece glibc-devel gibi bir paket eksikti
  • Yazı fazla uzundu ve yeterli dayanak sunmuyordu. Esas noktayı kaçırmış gibi
  • AI gelecektir
  • Gerçekten şaşırtıcı bir sonuç

• Keşke tüm prompt'lar ve ajan yapısı da paylaşılmış olsaydı. Öğrenmek için müthiş olurdu ama birebir denemek için 20 bin doları harcamak zor

  • Bugünlerde sadece sonuca bakıp sürecin nasıl işlediğini merak etmeyen bir hava olması üzücü

• Bu, Cursor blogundaki şeyin çalışan sürümü gibi. Gerçekten Linux çekirdeğini derlediğine dair kanıt çok daha ikna edici

  • Başta 1 Nisan şakası için hafif bir dil yapmayı düşünüyordum ama artık bu seviyede sonuçlar görünce şaşırıyorum. Yine de denemeye devam etmeyi düşünüyorum

• Bu, “piramit inşa edebilir ama katedral yapamazsın” türünden bir yaklaşım (ilgili yazı).
  Muazzam hesaplama kaynağı harcanarak işlev zorla ortaya çıkarılmış ve 20 bin doların yakıldığı bile söylenebilir.
  Üstel hesaplama ile doğrusal sonuç almak anlamlı olabilir ama uzun vadede verimsiz bir yön gibi görünüyor

  • 20 bin dolar API fiyatıysa, abonelik açısından bu herhalde 5-6 Max planına denk gelir
  • Yine de bu sadece bir FAANG mühendisinin 2 haftalık iş gücü maliyeti kadar. Bir insan 2 haftada derleyici yapamaz; o yüzden gösterim açısından fazlasıyla değerli