Tamamen yapay zekâ tarafından otomatikleştirilmiş yazılım geliştirme süreçlerinin var olup olmaması gerektiğine dair tartışma nihayet alevlendi. Fitili ateşleyen şey ise
@yetone tarafından sürdürülen magpie projesiydi; diğer geliştiriciler bu projeyi "fast-food hizmeti" ve "kullanmak için fazla riskli" olmakla eleştirdi.
Çoğu kişi, yapay zekâ destekli otomatik yazılım geliştirmenin kaçınılmaz bir trend olduğu konusunda hemfikir. Peki magpie bunu nasıl hayata geçiriyor? magpie'nin kodlarını çektim, son on gündeki 2.862 commit'i inceledim ve karşılaştırma yapmak için OpenClaw'ı kullandım.
https://x.com/wquguru/status/2109458639501271530
19 Günde 1204 Sürüm
magpie; Claude Code, Codex ve Gemini CLI gibi kodlama ajanlarını herhangi bir modele veya aboneliğe bağlayan yerel bir LLM geçididir (gateway). 22 Eylül'deki ilk commit'ten bugüne kadar geçen 19 günde 9.474 yıldız aldı. Toplam 2.862 commit'in %85'i yetone'un hesabından geldi ve 383 topluluk PR'ı merge edildi.
Etiket (yani sürüm) sayısı 19 günde 1.204'e ulaştı; bu da günde ortalama 60'tan fazla sürüm demek. Bir insanın manuel olarak asla sürdüremeyeceği bir tempo. Karşılaştırma yapmak gerekirse, OpenClaw ilk 19 gününde 1.423 commit gördü; bunların %99'u bizzat Peter Steinberger tarafından gönderildi ve yalnızca yaklaşık 10 etiket oluşturuldu.
magpie'nin iki kat daha fazla commit'i ama yüzden fazla sürümü var.
Çözmek istediğim tek bir soru vardı: Yapay zekâ bu projede döngüyü tam olarak nasıl kapatıyor?
Bir Yönlendirme Tablosu ve Bir Hata Defteri
magpie'nin CLAUDE.md dosyası yalnızca iki dosyaya referans veriyor: AGENTS.md ve LESSONS.md.
AGENTS.md bir yönlendirme tablosudur. Kendisi kural yazmaz; sadece ajanlara işe başlamadan önce hangi belgelere bakmaları gerektiğini söyler: alt sistemleri değiştirmeden önce docs/subsystems/ klasörünü kontrol et, kod yazarken veya incelerken docs/code-standards.md kurallarına uy ve topluluk PR'larını incelerken docs/contributors.md dosyasına göz at.
LESSONS.md dosyasının ilk cümlesi, baştaki sorumuzu yanıtlıyor:
magpie'nin kodları ajanlar tarafından yazılır, incelenir, birleştirilir ve yayınlanır. (magpie'nin kodları ajanlar tarafından yazılır, incelenir, birleştirilir ve yayınlanır)
Yazma, inceleme, birleştirme, yayınlama... Hepsi ajanlar tarafından yapılıyor. İnsan gözetimi olmadan neden çökmüyor? Cevap bu dosyada gizli. 479 satırlık bu dosya aslında her gece ajan tarafından tutulan bir hata defteri.
Ajan her gece o güne ait tüm commit'leri inceliyor ve şu üç senaryoya odaklanıyor:
- Hangi düzeltmeler tekrar elden geçirilmek zorunda kaldı?
- Hangileri hiç merge edilmemeliydi?
- Hangi doğrulamalar çok baştan savma yapıldı?
Bulduğu her sorun için bir kural ve bir gerekçe kaydediyor, kanıt olarak da commit ve issue numaralarını ekliyor. Örneğin:
Düzeltildi demeden önce, hatayı bildiren kişinin tam senaryosunu, onun kullandığı arayüzde yeniden üret.
834 numaralı issue 4 kez geri geldi (v0.1.920 → .925 → .931 → .938). Her seferinde yalnızca ekran görüntüsündeki ajan düzeltildi. Görüldü 1× (2026-10-05).
834 numaralı issue dört kez yeniden ele alındı ve her seferinde yalnızca ekran görüntüsünde görünen ajan düzeltildi. Dolayısıyla kural şu: Düzeltildi demeden önce, sorunu tam olarak hatayı bildiren kişinin kullandığı arayüzde yeniden üretmelisin.
Buradaki kilit nokta son satır: Görüldü 1×. Eğer aynı ders üç farklı gün yapılan incelemelerde karşımıza çıkarsa, LESSONS.md dosyasından code-standards.md dosyasına taşınır ve tecrübeden doğmuş katı bir kural haline gelir. Bundan sonra incelenen her PR, bu kurallarla madde madde karşılaştırılmak zorundadır.
Şimdiye kadar sekiz kural bu şekilde kalıcı hale getirildi. Örnekler arasında benzer hataların birlikte düzeltilmesi (5, 6 ve 7 Ekim'de birer kez yakalandı), main dalında başarısız olan testlerin anında düzeltilmesi gereken hatalar sayılması ve merge işleminden önce neyin, hangi commit üzerinde test edildiğinin açıkça belirtilmesi yer alıyor.
Elbette hata defteri doğru yapılan şeyleri de kaydediyor ve bunlar "Done right" (Doğru yapıldı) olarak işaretleniyor. Böylece ajanlar sadece "bunu yapma" değil, "bunun yerine şunu yap" mesajını da almış oluyor.
Hata Defteri 6 Ekim Sabahı Erken Saatlerde Devreye Alındı
Bu sistem en başından beri planlanmış mıydı? LESSONS.md dosyasının commit geçmişine baktığımızda, ilk sürümün 6 Ekim sabahı 03:10'da oluşturulan 303819c5 commit'i olduğunu görüyoruz.
Bir gün önce, yani 5 Ekim'de magpie 168 sürüm yayınlamıştı.
LESSONS.md'nin ilk versiyonu o günü kayıt altına aldı. 220 commit ve yaklaşık 170 sürümle, kabaca 40 tanesi aynı gün veya bir önceki gün yayınlanan sürümleri düzeltmek içindi. CI neredeyse her zaman bir sonraki push işlemiyle iptal ediliyordu. Yalnızca Linux'ta başarısız olan bir test, kimse fark etmeden v0.1.877'den v0.1.892'ye kadar kırmızı kaldı.
51 saatte 294 etiket, hiçbir çalışmanın tamamlanmasına izin vermedi. (51 saatteki 294 etiket, hiçbir CI çalışmasının tamamlanamayacağı anlamına geliyordu)
Bu yüzden ilk sürüme şu kural eklendi: Etiketlemeden önce, o commit'e ait CI süreci tamamlanmış ve yeşil yanmış olmalıdır. Yeni push işlemleri nedeniyle iptal edilen çalışmalar geçerli sayılmaz.
İlk gün 168 sürüm, ikinci gün 42, üçüncü gün 15 ve ardından 15 ile 26 arasında dengelenen bir tempo.
Hiçbir toplantı yapılmadı, hiçbir bildirim gönderilmedi. Gece incelemeleri sorunları tespit etti, hata defterine bir kural ekledi ve çalışan ajanlar bunu okuyarak sürüm sıklığını yavaşlattı.
Yani son zamanlarda sorunlu olduğu iddia edilen günde yirmi küsur sürüm, aslında frene basıldıktan sonraki hızdı.
PR Kabul Kriterleri
Şimdi gerçek PR'lara bakalım:
code-standards.md altı kabul kriteri listeliyor. Merge veya yayınlama işleminden önce hepsinin geçmesi gerekiyor. Üç platformda derleme ve sandbox testi gibi standart kontroller bir yana, üç tanesi tipik projelerde pek rastlanmayan türden:
- Regresyon Testi: Eski kodu geri koyun; yeni testler hangi davranışın yanlış olduğunu açıkça belirterek başarısız olmalıdır. Derleme hataları veya atlanan testler sayılmaz.
- Gerçek Kullanım: Bir sağlayıcı entegrasyonunu değiştiriyorsanız, gerçek hesaplar, konfigürasyonlar ve API yanıtlarıyla doğrulayın. Test edilmemiş özellikler üzerine inşa yapılamaz veya kullanıcılara kullanılabilir diye sunulamaz.
- Çalıştırılmayan Kontroller Listelenmelidir:
Çalıştırılmayan bir kontrol, "çalıştırılmadı" olarak listelenir, asla atlanmaz. (Yapılmayan kontroller "çalıştırılmadı" olarak listelenmeli, asla es geçilmemelidir)
Merge edilmeden önce bırakılan yorumu görmek için rastgele #1339 numaralı PR'ı seçtim:
Kırmızı tik regresyon testini, Break tiki testlerin yakalayıp yakalamadığını görmek için kodun kasıtlı olarak bozulmasını ifade ediyor ve son satırda Not run (Çalıştırılmadı) yazıyor; yani gerçek donanımda test edilmediği anlamına geliyor.
Merge komutu --match-head-commit <reviewed sha> parametresini içeriyor. İnceleme sırasında biri yeni bir push yaparsa merge işlemi başarısız olur ve incelenmemiş kodun içeri girmesi engellenir.
Süreçteki İnsan Faktörü
Elbette insanlar hâlâ bazı işlere dahil oluyor, en azından şu alanlarda:
- Ürün kararları: "Bilinçli alınmış kararlardan geri dönülmez." Kaydırma davranışı veya buton imleçleri gibi şeyler PR'larla değiştirilemez.
- Güvenlik Geçitleri: Risk kontrolleri tetiklenirse, proje yürütücüsünün onayı beklenir.
- Topluluk Önerileri: 474 commit başlığı X veya Discord'daki bildiricilerden bahsediyor; örneğin X'te JonahFu, Discord'da Jeremy.Zhou.
Kısacası insanlar yönü belirliyor ve kapıları bekliyor; yazma, inceleme, birleştirme ve yayınlama işlerini ise ajanlar üstleniyor.
yetone Bir Şeyler Saklıyor mu?
Bu noktada bazıları sorabilir: yetone bir şeyler saklıyor mu? Ben de merak ettim ve biraz daha derine indim.
Gerçekten de repoda olmayan birkaç şey var:
- Gece incelemelerinin nasıl tetiklendiği belgelenmemiş. 4 iş akışının (workflow) hiçbiri zamanlanmış değil.
- 7 LESSONS.md güncellemesinin saatlerini çıkardım: 03:10, 03:49, 00:23, 23:46, 03:48, 14:24, 05:26. Dağınıklar, cron job'larından ziyade manuel yerel çalıştırmalara veya özel betiklere benziyorlar.
- Gece incelemeleri için kullanılan prompt'lar da yok. Hangi ajan, kaç paralel oturum... Hiçbiri belgelenmemiş.
Bu arada iki ek detay daha buldum:
Birincisi, yöntem topluluk katkılarını içeriyor. Alt sistem dokümantasyonu ve anlamsal değişiklik incelemeleri, topluluk üyesi Junjie Zhou'nun #889 numaralı PR'ı aracılığıyla devreye alındı. code-standards.md dosyasının başındaki iki tablo, 926bcaa3 commit'inde açıkça Junjie Zhou'nun Discord'da önerdiği altı inceleme kuralına atfediliyor.
İkincisi, yetone'un ajanlarla etkileşimleri commit'lerde korunuyor. 52 commit başlığı, yetone'un orijinal alıntılarını parantez içinde barındırıyor:
1(sahibi: Bu çok çirkin)2(sahibi: Neden bizim soyut ComboBox'ımız yerine yerel bir seçici kullanılmış?)3(sahibi: Bu neden yine geri geldi? Sadece üzerine gelindiğinde görünmesi gerektiğini söylememiş miydik? Sürekli görünmesi çok çirkin)4(sahip: pr-preview sırasında bazen test edecek veri olmuyor. Birkaç sahte veri oluşturabilir misin?)
Bunlar çoğunlukla tek satırlık şikayetler; gerisini ajan dolduruyor ve bu durum genellikle commit gövdesinde yüzlerce kelimelik metinlerle sonuçlanıyor. Sahte veri talebi daha sonra CI kayıtları için kullanılan mock veri setine dönüştü.
İnsanlar neyin yanlış olduğunu gösteriyor; ajanlar bunu doğrulanabilir değişikliklere çeviriyor. Bu düzinelerce commit başlığı, metodolojiyi herhangi bir dokümandan çok daha iyi açıklıyor.
Kendi Sisteminizi Kurmak İsterseniz
Herkes bir yönlendirme tablosu yazabilir. Kopyalanması gereken asıl değer, hata defteri sistemidir. Bir LESSONS girdisi şöyle görünür:
1**<Tek cümlelik kural>**2- <Hangi commit/issue soruna yol açtı, sonucu ne oldu>3- <Düzeltme commit'i>4- Done right: <Doğru yapılış örneği>5- Seen N× (YYYY-MM-DD, YYYY-MM-DD).
Bir ajana her gece günlük commit'leri inceletmesini sağlayın; yalnızca tekrar eden işleri, kötü merge'leri ve zayıf doğrulamaları aratsın. Aynı sorun üç farklı gün ortaya çıkarsa, onu kod standartlarına taşıyın. Kabul aşamasında regresyon testlerini, gerçek kullanım senaryolarını ve çalıştırılmayan öğeleri commit gövdelerinde ve PR yorumlarında listeleyin.
Tüm repoyu inceledikten sonra beni en çok etkileyen şey "Seen 3×" eşiği oldu. Hatalar not ediliyor, ajanlar başlarken bunları okuyor ve aynı hatanın üç kez tekrarlanması onu katı bir kurala dönüştürüyor. Bu durum "Üçüncü kez şans" (veya daha doğrusu üçüncü ihtar) sözünün mükemmel bir yansıması.
Son Söz...
Bir yıl, hatta altı ay önce bile model yetenekleri nadiren üretim seviyesinde bir otomasyona ulaşabiliyordu. Ama şimdi, özellikle Opus 5.5'in sahneye çıkmasından bu yana görüyoruz ki gelecek artık burada.
Bu bana @yuanhao'nun Yoyo'sunu hatırlatıyor; 200 günden fazla süredir kendi kendini iyileştiren bir Ajan: https://yoyo-gasp.yolog.dev/, ona da mutlaka göz atmalısınız.
