Yazılım Fabrikaları Neden Başarısız Olur?

Tamam, metni analiz ettim. İşte Türkçeye çevrilmiş hali:

ya da: koşum yeterli değil

Güncelleme - bu yazının konuşma versiyonu YouTube'da yayında: https://www.youtube.com/watch?v=Ib5GBkD555M

sanırım döngüler yapıyoruz

Hepimiz AI kodlamayı üretime sokmak için yarışıyoruz. Döngü mühendisliği hakkında çok şey söylendi ve geçerli görüş, muhtemelen daha fazla döngü yazmamız gerektiği yönünde.

StrongDM, ışıksız yazılım fabrikaları hakkında yazdı - hiçbir insanın kod okumadığı ve hiçbir insanın kod yazmadığı bir yer.

Anlatı kabaca şöyle işliyor:

1. Darboğaz sensin.
2. Modeller yeterince iyi.
3. Kod bedava.
4. Sadece daha fazla şey gönder.

Ryan Lopopolo](https://x.com/_lopopolo OpenAI'den Şubat ayında bunun hakkında yazdı ve Nisan ayında bir konuşma yaptı OpenAI'in yazılım fabrikası Symphony hakkında.

Bu insanların hepsi gerçekten çok zeki ve onlara büyük saygı duyuyorum. Ama buradaki en alaycı yorum, bunun VC parasını slop topuna pompalamak için başka bir bahane olduğu olurdu.

şey... işte gidiyor

Arkadaşımız Mario AI Engineer Europe'da ayağa kalktı ve yavaşlamamız için yalvardı -- çünkü kodlama ajanı kazalarından dolayı kesinti yaşamaması gereken şirketler, işte... kodlama ajanı kazalarından dolayı kesinti yaşıyor.

Matt Pocock'un dediği gibi, kod tabanları hiç olmadığı kadar hızlı dağılıyor.

StrongDM'den o karanlık fabrikanın nasıl gittiğine dair kesin veri/bulgu bulamadım. Hava durumu raporu bu yılın Şubat ve Haziran ayları arasında birkaç seyrek güncelleme içeriyor. düzenleme - 23 Temmuz'da hacker news'te ekiple bir konuşma var - yakında daha resmi bir güncelleme alabiliriz gibi görünüyor!

Faros AI'dakiler bir rapor yayınladı: Ocak ve Şubat aylarında bu AI kodlama araçlarını hepimiz2 aldığımızdan beri, pull-request inceleme kalitesi çok düştü.

• Daha fazla yorum, daha uzun yorumlar ve hiç inceleme yapılmadan birleştirilen tonlarca PR.
• Olay sayısı çok arttı.
• Geliştirici başına hata sayısı çok arttı.

Bu rapor, doğrulanabilir bir kesin kanıttan çok bir korelasyon sinyali (evet bu kelimeyi bilerek seçtim, claude düzyazısı hakkında başlatmayın beni) ve bu yazının tüm amacı slop verilerine karşı dikkatli olmak, ama gördüklerime dayanarak yönsel olarak geçerli hissettiriyor.

"Yanlış tutuyorsun" (tutmuyorsun)

Birçok insan size bunun bir beceri sorunu olduğunu söyleyecek -- iyi sonuçlar alamıyorsanız, bu sizin hatanız.

Ama nasıl... şey... tutmayı seçerseniz seçin, size token-maxxing'in sizin için işe yaramadığında bunun bir beceri sorunu olduğu söylendiğine garanti verebilirim. Sadece daha fazla token harcamanız gerekiyor. Kodu okumayı bırakın. Ve yeni başlıyorsanız, söz veriyorum bu ilerlemenin bir parçası. Geçen yaz da böyle düşünüyordum.

Ne yazık ki egom için, "nasıl daha iyi tutulacağı" hakkında söylediğim bazı aptalca şeyler kaydedildi ve şimdi YouTube'da yaklaşık bir milyon toplam izlenmeye sahip. Burada övünmeye çalışmıyorum, bunu yalnızca kodlama ajanlarını kullanmanın en iyi yolları üzerinde uzun süredir derinlemesine çalıştığımı ve birçok kişinin gerçekten faydalı bulduğu bazı şeyler keşfettiğimi belirtmek için paylaşıyorum.

• Kodlama Ajanları için Gelişmiş Bağlam Mühendisliği
• Vibe Yok - Karmaşık Kod Tabanlarında Zor Problemleri Çözmek
• RPI Hakkında Yanlış Bildiğimiz Her Şey

Her neyse, Sözü, çevrimiçi katlanmak zorunda kaldığımız tüm bu "sadece daha sert tokenla" gevezeliğinin kısaca şu: yeterli koşum mühendisliği ile her iki dünyanın da en iyisini elde edebiliriz:

• 10 ila 100 kat daha hızlı,
• yüksek kaliteli, ve
• kimse hepimizin nefret ettiği o şeyi, yani kod incelemesini yapmak zorunda kalmaz

Tek yapmamız gereken daha fazla linter yapılandırmak ve yeterince PR inceleme botuna "çekişmeli inceleme" gibi sihirli kelimeler serpiştirmek, böylece yazılımımız mutlu bir şekilde kendini inşa edecek, kesinti olmadan.

Bu bir beceri sorunu değil

Sizi ikna etmeye çalışacağım şey, hiçbir miktarda koşum mühendisliği veya döngümaxxing'in temelde bir model eğitim sorunu olan şeyi çözemeyeceğidir.

Bununla başa çıkmak için, kodlama modellerinin gerçekte nasıl eğitildiğini ve değerlendirildiğini araştırmak zorunda kaldım - hem RLVR hem de benchmark tarafıyla ilgili olarak.

Bu yazıda şunları inceleyeceğim:

1. Yazılım fabrikaları 1968'e kadar uzanır, nasıl evrildiler ve AI onları nasıl değiştirdi?
2. Modeller benchmark'larda (hatta yeni "sınır" benchmark'larında) zirve yapmalarına rağmen neden dağlar kadar slop üretebilir?
3. Buna rağmen, kod tabanınızı ateşe vermeden oldukça hızlı ilerleyebilirsiniz.

Her gün ortaya çıkan beceri eklentilerinin ve ai-psikozu-tokenmaxxing tavsiye salgınının abartısını kesmeye çalışacağım ve belirli bir beceri veya çerçeveye atıfta bulunmadan genel olarak işe yarayan şey türleri hakkında konuşacağım.

Video Versiyonu: bu yazı, AI Engineer World's Fair 2026'daki açılış konuşmama dayanmaktadır (ve onu genişletmektedir).

Şu kişilere teşekkürler: @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, ve @jeffreyhuber bu yazıya geri bildirimleri için.

Bir ara not: bunun vibe kodlamayla hiçbir ilgisi yok

Addy Osmani vurgulamaya değer olan şu şeyi çözdü:

Bir düzine insanın çalıştıracağı bir yan projeyi vibe kodlayan bir geliştirici ile on yıllık bir kurumsal sistemi bir çeyrek daha canlı tutan bir ekip, neredeyse hiçbir ortak kısıtlamayı paylaşmaz ve dolaşımdaki tavsiyelerin çoğu aslında bu iki kişiden birinin diğerine nasıl yaşayacağını söylemesidir.

Vibe kodlamayı seviyorsanız, lütfen vibe yapmaya devam edin. Ben hala birçok şeyi vibe kodluyorum, sadece ayrıca birçok üretim yazılımını da sürdürüyorum (ve HumanLayer aracılığıyla 1000'lerce başka mühendisin aynısını yapmasına yardımcı oluyorum), bu yüzden geri kalanı karmaşık kod tabanlarında zor problemleri çözen kişilere yöneliktir.

Bu ayrımdan bahsetmek için brownfield kelimesini çok duyuyorum. Tarihsel olarak bu on yıllık bir Java şeyi anlamına geliyordu, ama şimdi gönderebildiğimiz hızda, bir ajan tarafından inşa edilmiş bir kod tabanının belki üç ila altı ay sonra zorlanmaya başladığı hissi var -- yavaşlamaya başlıyorsunuz ve yeni şeyler ekleme şekliniz değişmek zorunda.

Yazılım fabrikasının kısa bir tarihi

Tüm kariyerim boyunca yazılım fabrikaları inşa ettim ve inceledim, ama bunu ancak yakın zamanda öğrendim: terim, bize "yazılım mühendisliği" terimini de veren 1968'deki bir NATO konferansına kadar uzanıyor.

O zamandan beri gerçekten ilginç bulduğum tek diğer şey, ABD Savunma Bakanlığı'nın, Bakanlığın jenkins'i daha iyi kullanmaya başlaması gerektiği veya benzeri bir şey hakkında 31 sayfalık bir pdf yazması.

2022 yazılım fabrikası

"Yazılım fabrikası" tanımımızı AI'dan hemen önce, 2022 civarına sabitleyelim. Tipik bir yazılım fabrikasında:

• İnsanlar ne inşa edileceğine karar verir -- mühendisler, PM'ler, vizyonu yönlendiren liderlik
• Bu bir takipçiye gider -- Linear, Jira, fark etmez: ne yapılması gerektiğinin bir durum makinesi
• Birisi bir ticket alır ve onu inşa eder -- muhtemelen bunu yaparken biraz manuel/otomatik test de yapar
• Pull request -- otomatik kontroller, bir insan kodu inceler, belki birisi test etmek için indirir
• Yanlış bir şey var mı? "Birisi şeyi inşa eder" adımına geri dön
• Prod'a gönder -- ve kullanıcılarla temas eder
• İzleme ekle -- bir şey bozulduğunda sabah 3'te bir mühendisi aramak etrafında inşa edilmiş koca bir endüstri var
• Kullanıcılar şikayet eder -- bir şeyler ister, hata bulur, özellik talebi gönderir → takıma, takipçiye eklemek için geri

Ve böyle devam eder. Daha AI'ya bile gelmedik ve bu resimde zaten birkaç döngü var.

önceden yükleme uyumu

Takımların on yıllar önce çözdüğü bir şey var: inşa etmek saatler veya günler alır ve inceleme de öyle.

Bu yüzden işi önden yükleriz -- planlama, mimari önerileri, sprint planlama -- birlikte, bir takım olarak. Bu şu anlama gelir:

• daha az yeniden iş, çünkü kimse kod yazmadan önce uyum sağladık
• her satırı incelemek için daha az zaman, eğer uzun ama iyi yapılmış bir PR okuduysanız, neredeyse mükemmel olduğunda incelemenin ne kadar hızlı gittiğini bilirsiniz

Buna daha sonra geri döneceğiz - şimdi ajan kodlamayı resme kattığınızda ne olduğuna bakalım.

Ajan yazılım fabrikası

Artık her şirket ve onun annesi --

• Ramp
• Stripe
• WorkOS
• Brex

bu yılın büyük bölümünü, kodlarının %75'ini gönderen bir ajan fabrikasını nasıl inşa ettiklerini açıklayarak geçirdi.

Ajan fabrikası çoğunlukla "birisi şeyi inşa eder" → "bir ajan şeyi inşa eder" değişimini yapmak gibi görünüyor -- burada orkestrasyon, koşum, sanal alan, bir model, bilgisayar kullanımı vb. gibi bazı şeyler var. Bu ayrıntılara derinlemesine girmeyeceğim çünkü açıkçası bunun hakkında okumaktan bıktım ve eminim siz de öylesinizdir.

Ajan şeyi inşa ettiğinde:

• İnşa etmek saatler veya günlerden dakikalara veya saatlere düşer.
• İnceleme hala saatler veya günler alır. Bir insan hala kodu okumalı ve değişikliği test etmelidir. Bu yüzden inceleme şimdi darboğazdır.

Yani siz de incelemeyi hızlandırırsınız:

• Ajan kod incelemesi, stil, hata, güvenlik yakalamak için.
• Ajan regresyon testi, tarayıcılar ve bilgisayar kullanımı ile dışarıdan dürtmek ve bittiğinde size belki sevimli küçük bir video göndermek için

İnceleme şimdi daha hızlı, ama muhtemelen hala darboğaz. Ama daha fazla döngü yapabiliriz.

Sonraki adımda olayları fabrikaya yönlendirebilirsiniz. Birini sabah 3'te aramak yerine, muhtemelen zaten düzelten bir PR ile uyanırlar.

Ayrıca kullanıcı geri bildirimlerini fabrikaya yönlendirebiliriz. İnsanlar bir şey ister, inşa edilir.

Bu noktada iş iki soruya indirgenir: kuyruğa ne kadar sıkıştırabilirsiniz ve çıkanı ne kadar hızlı inceleyip test edebilirsiniz?

Bu da bizi ışıksız yazılım fabrikasına getiriyor.

Işıksız yazılım fabrikası

Dan Shapiro bu terimi icat etti ve Simon Willison, StrongDM'in uygulaması hakkında yazdı -- artık kodu okumadığımız yer.

Güzel yazılım fabrikanıza bakıyorsunuz. Şu sinir bozucu küçük kod inceleme adımı tarafından mahvediliyor ve diyorsunuz ki: biliyor musunuz, her değişikliği bir insanın okuduğu şey? Hayır teşekkürler.

Bu yüzden onu bırakıyorsunuz ve çabayı başka bir yere koyuyorsunuz:

• Test etmeye ve ajanın kendi işini test etmesine izin vermeye yatırım yapın
• Sanal alanlara ve orkestrasyona yatırım yapın
• Otomatik incelemeye yatırım yapın
• İzlemeye yatırım yapın
• Yayına yatırım yapın
• Kullanıcılardan geri bildirim sinyalleri toplamaya yatırım yapın

Ve şimdi iş gerçekten tek bir soru: ajandan ne kadar şey inşa etmesini isteyebiliriz? Okyanusun ne kadarını kaynatmak istiyoruz?

Bu harika gidecek (gitmeyecek)

Potansiyel olarak tartışmalı bir şey öne süreceğim: ışıksız fabrika işe yaramıyor.

Yazılım fabrikalarının neden başarısız olduğuna bir bakalım.

Bunu denedik

Temmuz 2025'te tamamen ışıksız moda geçtik. Sadece spesifikasyonları ve ticket'ları oku, tüm küçük/orta şeyler için arka plan ajanları, her şey.

Eğer bunu birkaç ay ciddiye aldıysanız, nasıl bittiğini zaten biliyorsunuzdur. Ajanın çözemediği en az bir tane yeterince zor sorun bulursunuz - en gelişmiş yönlendirmeleriniz ve iş akışlarınızla bile.

• Derin bağlam farkındalığıyla araştırma yaparsınız, tüm doğru parçaları modelin analiz etmesi için akıllı bölgeye toplarsınız
• Ajanın 10 farklı şekilde yeniden üretmeyi denemesini sağlarsınız

Sonunda dişinizi sıkıp üç ay önce okumayı bıraktığınız kod tabanına dalmanız ve neyin bozuk olduğunu anlamaya çalışmanız gerekir.

Ve bu arada:

• Siteniz kapalıydı.
• Kullanıcılarınız sinirliydi.
• Ve siz, eğer bana benziyorsanız, sefil durumdaydınız -- sisteminize girmesine izin verdiğiniz tüm slop kodunu okuyordunuz.

Bu ilk başımıza geldiğinde, salladım gitti. Claude spagettisini kazmak için neredeyse iki haftanın daha iyi bir kısmını harcamış olmama rağmen, "olumsuz risk hıza değerdi". Kasım ayında yaklaşık üçüncü kez olduğunda, sıfırdan yeniden yazmanın daha kolay olacağına karar verdik ve kurucu ortağım tam iki haftasını VS Code'da (cursor bile değil) tüm kalıpları elle döşeyerek geçirdi.

modeller zamanla kod tabanı kalitesini düşürür

Ulaşmak istediğim şu: modellerin bir eksikliği var. Zamanla kod tabanı kalitesini koruyamaz ve iyileştiremezler -- makul miktarda insan yönlendirmesi olmadan.4

Bakım yapılabilirlik derken, kod tabanının bir bölümünü diğerini kırmadan değiştirmenin gerçekten, gerçekten zor olduğu belirli durumu kastediyorum. Bu Martin Fowler'ın av tüfeği cerrahisi.

Bakım yapılabilirlik hakkında daha fazla bir şey söylemeyeceğim. Okuyabileceğiniz bir sürü kitap var:

• John Ousterhout'dan Bir Yazılım Tasarımı Felsefesi
• Robert C. Martin'den Temiz Kod
• Martin Fowler'dan Yeniden Düzenleme

Peki, modeller neden yazılım bakım yapılabilirliğini yapamaz?

"Ama modeller o zamandan beri kesinlikle daha iyi hale geldi"

Bu noktada şunu söylemek için can atıyor olabilirsiniz: ama Dex, modeller Temmuz'dan beri kesinlikle çok daha iyi hale geldi

Bazı yönlerden öyle oldular. Diğerlerinde ise aşağı yukarı aynılar.

• Tek seferlik sorunları çözmek veya yeni bir pazarlama sitesini vibe kodlamak mı? Evet. Çok daha iyi.
• Zamanla kod tabanı kalitesini iyileştirmek mi? Anladığım kadarıyla pek daha iyi değil.

Bunu kanıtlayamam. Siz de kanıtlayamazsınız. Bir modelin kod tabanı kalitesini koruma yeteneği için iyi bir benchmark yok. (Bunun nereye gittiği hakkında daha sonra.)

Bir modelin kod tabanı kalitesini koruma yeteneği için İYİ BİR BENCHMARK YOK

Ama bir süredir kodlama ajanlarıyla çalıştıysanız -- ve birçok insan tam olarak bunun hakkında yazıyor -- muhtemelen zaten şu hisse sahipsiniz: zamanla işleri daha da kötüleştirme eğilimindeler ve kod tabanında çalışmayı zorlaştırıyorlar.

Peki bunun neden olduğunu anlamak için, ilk büyük kodlama ajanına geri dönmek istiyorum.

Claude Code, koşum içindeki Pekiştirmeli Öğrenme sayesinde kazandı

Claude Code, bir yıldan kısa bir sürede sıfırdan ~$4B'ye -- şimdi ~$9B gibi bir şeye -- gelire ulaştı.

Bu biraz çılgınca, çünkü zaten harika CLI ajanları vardı. aider, cline, codebuff -- hepsi Claude Code'dan önceydi, hepsi gerçekten harika bağlam mühendisliğiyle birlikte geliyordu, hepsi claude code'a atfedebileceğiniz aynı araç setine sahipti: oku, yaz, düzenle, grep, bash. Onları kullandım. İyilerdi. Ama ayrıca, araç kullanımı bazen... başarısız olurdu -- aynı düzenlemeyi üç kez debelenirken izlerdiniz ve kendi editörünüzü açıp kendiniz yapardınız.

2024'ten SWE-Agent makalesi, araç şeklindeki küçük değişikliklerin fark edilir farklılıklar yarattığını ana hatlarıyla belirtir, örn. ReadFile sonuçlarına satır numaraları eklemek veya bir Edit aracını bul/değiştir'den satır aralığı düzenlemelerine değiştirmek.

Sonra Claude Code piyasaya sürüldü ve hızla dikey bir ivme kazandı. Bunu dağıtım olarak geçiştirebilirsiniz, ancak kabul edilen açıklama, claude code'un daha iyi olduğu için kazandığı ve daha iyi olduğu için de Anthropic'in modeli koşumun içinde RL'ye tabi tuttuğudur -- bir laboratuvarın modeli, onu gönderecekleri kesin araçlara karşı ilk kez eğitmesi. Ve bu araçları bir ajan döngüsünde çağırmada gerçekten, gerçekten iyi hale geldi.

Bir şey, modelin en çok sevdiği şekli bulana kadar araç tanımları ve değerlendirmelerle oynamaktır -- çeşitli kullanım durumları için bunu yaparak haftalar harcadım. Ağırlıklara sahip olduğunuzda ve modeli belirli bir araç setinde daha iyi olacak şekilde değiştirebildiğinizde bu farklı bir oyundur.

OpenAI ekibi Kasım ayında bir konuşma yaptı bunu oldukça iyi ifade eden: bir koşum inşa ederseniz ancak ağırlıklara sahip değilseniz ve modeli onun içinde RL'ye tabi tutamazsanız, her ikisine de sahip bir takıma karşı her zaman dezavantajlı olacaksınız.

Kodlama Ajanı RL 60 saniyede

Bu konu hakkında bir sürü araştırma yaptım ve önemli kısımları açıklamaya çalışan bir sürü görselleştirme hazırladım, ancak Calvin French-Owen'un (codex ekibinde MTS, Segment'in kurucusu) AI Council'de bir konuşma yaptığını ve bunu çok daha iyi ve temiz bir şekilde yaptığını buldum, bu yüzden onun slaytlarından ilham alan bu animasyonu buraya koyacağım:

Bir modeli kodlamada daha iyi hale getirmek için şunları yapacaksınız:

1. bir sorunu çözmek için bazı kodlama ajanı izleri oluşturun (ör. testlerimi düzelt)
2. izleri bazı kriterlere göre puanlayın (doğrulayıcı)
3. model ağırlıklarını güncelleyerek iyi izlerin daha olası, kötü izlerin daha az olası olmasını sağlayın

Ve bunu haftalar veya aylar boyunca milyonlarca kez yaparsınız.

Ancak bu şeylerin "puanlama" kısmı, kaprisli bir şekilde tek boyutlu olma eğiliminde olabilir.

Kötü tasarım için ceza yok

SWE-bench Multilingual'i ele alalım. Görevler küçük -- her biri yaklaşık on beş dakikalık iş -- Redis, jq ve Django gibi açık kaynaklı depolardan çıkarılmıştır. Ödül, şunlara dayalı olarak bir veya sıfırdır:

• FAIL_TO_PASS - düzeltmeniz istenen şeyi düzelttiniz mi?
• PASS_TO_PASS - başka bir şeyi kırmadan yaptınız mı?

İşte gerçek bir tane, fastlane__fastlane-19304, fastlane'den -- bir Ruby projesi. Zip eylemi iki isteğe bağlı parametre alır ve hemen onlara .empty? çağırır, bu nedenle include ve exclude'u boş bıraktığınız anda çöker:

Bu belirli sorunu kapatan insan düzeltmesi iki satırdır (nil'leri varsayılan olarak boş dizilere ayarla):

Değerlendirme sırasında model

1. bir temel commit'ten başlar -- depo, o düzeltmenin tam olarak uygulandığı andan hemen önceki haline alınır
2. hata raporu - bu durumda 'zip_command': nil:NilClass için tanımlanmamış 'empty?' metodu

Ajan, soruna dayanarak bir miktar kod yazıp gider. Altın yamayı veya derecelendirici görevi gören test yamasını görmez:

Sonra:

1. Ürettiği yamayı saklarız, ardından
2. Test dosyalarında yaptığı tüm düzenlemeleri atarız (modelin sessizce başarısız testi yorumladığını veya testi işe yaramaz hale getiren bir mock eklediğini gördük)
3. Benchmark'ın test yamasını üstüne uygularız ve
4. Tüm paketi çalıştırırız: mevcut zip testleri (PASS_TO_PASS) artı yenisi (FAIL_TO_PASS) ikisinin de geçip geçmediğini görmek için

Ara Not - Benchmark'lar doğrulayıcı değildir - aslında birbirlerinden ayrı tutulmaları gerekir (test üzerinde eğitim yapmayın, vb.) - bunu esas olarak "bir kodlama ajanı izinin kalitesini yargılamanın" şeklini ve sınırlamalarını iletmek için kastediyorum.

Modelin doğru cevaba nasıl ulaştığı önemli değil. Testler geçerse, kazanırız, ancak kod tabanı bakım yapılabilirliğini aşındırmak için hiçbir ceza yoktur.

kod tabanı bakım yapılabilirliğini aşındırmak için hiçbir ceza yoktur

Her şeyin etrafına try-catch koymanın yolu budur:

Kaliteyi doğrulamak, "testler geçti mi" sorusundan katbekat daha zordur

Testleri çalıştırmak, temiz bir geçme veya kalma sonucu almanızı ~saniyeler içinde sağlar. Bu nedenle RL, her model neslini optimize etmek için milyonlarca döngü çalıştırabilir.

Ancak kötü mimarinin maliyet fonksiyonu haftalar, aylar, hatta belki yıllarla ölçülür. Bu, birisinin tek satırlık bir değişiklik için o dosyayı ilk açtığında ve bunu tek satırda yapamayacağını fark ettiğinde olur -- birisi bunu biraz fazla sert vibe'ladı ve şimdi aynı düzenlemeyi on bir yerde yapmak ve üç dosya ötede bir şeyin sessizce kırılmamasını ummak zorundayız.

Testler size saniyeler içinde geri bildirim verir, ancak kötü mimarinin maliyet fonksiyonu haftalar, aylar, hatta belki yıllarla ölçülür

Kötü tasarım, bugünün benchmark'larının değerlendiremediği tek şeydir. Ve biliyorum, biliyorum, RL != Benchmark'lar, ancak bu RL'de çözülmüş olsaydı, benchmark'larımızın tasarımında da kendini göstermeye başlayacağına oldukça eminim.

Her durumda, bugünün benchmark'larındaki herhangi bir iyileşmenin, modellerin aniden kod tabanınızı sloplamakta iyi olduğunun bir göstergesi olduğuna kişisel olarak güvenmiyorum.

Sınır yavaş yavaş iyileşiyor

Tabii ki birçok zeki insan bunun üzerinde çalışıyor. Amacım bunun yapılamayacağını söylemek değil, abartının disiplinin önüne geçtiğini söylemek.

Doğru yönde olduğunu düşündüğüm birkaç çaba:

• SWE-Marathon (Abundant AI): "Excel'in tamamını, her özelliği klonla" gibi ~400 saatlik görevler -- tek bir geçme/kalma biti yerine bileşik bir ödül kanalı ile
• DeepSWE (Datacurve): gerçek dünyada hiç inşa edilmemiş OSS depolarındaki büyük görevler, bu nedenle yapıları gereği eğitim setinde zaten bulunamazlar (kirlenmeyi çözer, ancak kaliteyi değil)
• Frontier Code (Cognition): çoklu PR görevleri ve kaliteyi deterministik olarak değerlendiren akıllıca bir hamle -- modeli, yama öncesi kodda başarısız olmayan testler yazdığı için cezalandırır (mutasyon testi hakkında hiç duymadıysanız, eğlenceli bir sürüş sizi bekliyor5). Ayrıca kod kalitesi kurallarını kontrol eden diff üzerinde bir yargıç modeli çalıştırır.

Ancak kaliteyi yargılayan bir model ancak bir yere kadar gidebilir.

Aslında, bir modelin iyi kodu kötüden güvenilir bir şekilde ayırt edebilmesi halinde, baştan itibaren iyi versiyonu yazmış olabileceğini hayal etmek zor değil. RL hızlı ve güvenilir bir oracle gerektirir ve biz henüz sürdürülebilirlik için böyle bir sisteme sahip değiliz.

Bir model iyi kodu kötüden güvenilir bir şekilde ayırt edebilseydi, muhtemelen baştan iyi versiyonu yazardı, ancak sürdürülebilirliğin hızlı bir oracle'ı yok, bu nedenle RL sırasında bunu ödüllendiremiyoruz.

Elbette, daha fazla inceleme aracısı ve daha fazla token yardımcı oluyor – tabanı yükselterek aptalca şeyleri yakalıyorlar.

Ama tavanı yükseltmiyorlar, çünkü tavan, modele RL'de öğretmeyi başardığımız şeydir ve iyi tasarım, hâlâ nasıl öğreteceğimizi bilmediğimiz şeydir.

Bu yüzden yine de kod tabanımı bunlardan herhangi birine emanet etmezdim. Ancak bunlar, geçti/kaldı ile yetinmek yerine sürdürülebilirliği puanlamaya çalışan ilk değerlendirmeler.

Not Belki gelecekteki bir model bunu çözer ve biz de durabiliriz. GPT-7 çıkana kadar rastgele prompt'lar göndermek isterseniz, buyurun – ama acı ders ne derse desin, şu anda çözmemiz gereken sorunlar var ve bunu nasıl yapacağımızı anlatacağım.

Işıkları Yeniden Yakmak

Bugün Twitter Articles'ın bir "medya limiti" olduğunu öğrendim, bu da geri kalanının ikinci bölüme gideceği anlamına geliyor – takipte kalın.