- Yapay zekanın ürettiği kodun miktarı ve ölçeği katlanarak artarken, mevcut manuel kod inceleme yaklaşımı artık geçerliliğini yitiriyor
- Yapay zeka benimseme oranı yüksek ekiplerde tamamlanan iş miktarı %21, PR birleştirmeleri ise %98 arttı; ancak PR inceleme süresi %91 arttı gibi paradoksal bir durum ortaya çıktı
- Kodun kendisini doğrudan incelemek yerine insanın rolü, spesifikasyon ve kabul kriterlerini (Acceptance Criteria) inceleyen üst akış doğrulamaya kaymalı
- Tek bir doğrulama kapısı yerine çoklu ajan rekabeti, deterministik guardrail'ler, BDD, yetki sistemleri ve adversarial doğrulama gibi İsviçre peyniri modeli temelli çok katmanlı bir güven yapısı gerekiyor
- "Hızlı dağıt, her şeyi gözlemle ve daha da hızlı geri al" yaklaşımı, yavaş inceleme sonrası production debug etme düzeninin yerini alan yeni paradigma
İnsanlar zaten kod incelemeyi kaldıramıyor
- PR'ların günlerce bekletilmesi, biçimsel onayların verilmesi ve inceleyenlerin 500 satırlık diff'lere göz gezdirmesi bugün yaşanan gerçeklik
- Kod inceleme bir kalite kapısı olarak görülse de, satır satır inceleme olmadan onlarca yıldır yazılım yayımlayan ekipler var ve kod incelemenin yaygınlaşması 2012–2014 civarına denk geliyor
- İnceleme olsa bile kesintiler yaşanıyor; buna karşılık ekipler feature flag, kademeli rollout ve anında rollback gibi sistemler kurdu
Tüm kodu okumaktan vazgeçmek gerekiyor
- Yapay zeka benimseme oranı yüksek ekiplerde aynı anda hem değişiklik sayısı hem de değişiklik boyutu katlanarak artıyor
- 10.000'den fazla geliştirici ve 1.255 ekibin verisine dayanıyor (Faros analizi)
- Geliştiriciler, yapay zeka tarafından üretilen kodu incelemenin ekip arkadaşlarının kodunu incelemekten daha fazla emek istediğini hissediyor
- Manuel kod incelemeyle bu mücadele kazanılamaz; kod inceleme, bugünkü çalışma biçimiyle uyuşmayan geçmişten kalma bir onay kapısı
Yapay zeka kod incelemesi de hâlâ sadece 'inceleme'
- Yapay zeka kodu yazıyor ve yapay zeka inceliyorsa, gösterişli bir inceleme arayüzü açmanın anlamı yok
- Yapay zeka kod inceleme araçları yalnızca zaman kazandırır; bu tür incelemeler de geliştirme döngüsünün soluna (shift left) kayacaktır
- CI kaynaklarını harcayıp inceleme döngüleri arasında sürüm yönetimi yapmanın anlamı yok
- Ajanların kod yazdığı bir ortamda "yeni bir çift göz", aynı kör noktalara sahip başka bir ajandan ibarettir; değer onay kapısında değil, iterasyon döngüsündedir
- "Yapay zekanın bir kez saçmaladığını gördüm, o yüzden her zaman kontrol etmeliyim" içgüdüsü, manuel doğrulamanın mümkün olduğu dönemde mantıklıydı; ancak bugünkü ölçekte artık uygulanabilir değil
Kod incelemeden niyet (intent) incelemesine geçiş
- İnsani kontrol noktalarını üst akışa (upstream) taşımak gerekiyor
- Yazılım geliştirmede kontrol noktalarının yer değiştirmesine dair emsal var: waterfall sign-off → sürekli entegrasyon (CI)
- Spesifikasyon odaklı geliştirme (Spec-driven development), yapay zeka ile işbirliğinin başlıca yöntemi olarak öne çıkıyor
- İnsanlar spesifikasyonları, planları, kısıtları ve kabul kriterlerini incelemeli; 500 satırlık bir diff'i incelemeleri gerekmiyor
- Yeni paradigmada spesifikasyon gerçeğin kaynağı (source of truth) oluyor, kod ise spesifikasyonun çıktısı
- İncelenen şey kod değil; adımlar, doğrulama kuralları (verification rules) ve kodun yerine getirmesi gereken sözleşme (contract)
- Human-in-the-loop onayı "Bunu doğru yazdı mı?" sorusundan, "Doğru problemi doğru kısıtlarla mı çözüyor?" sorusuna kayıyor
- En değerli insan yargısı, kod üretildikten sonra değil ilk satır üretilmeden önce devreye giriyor
Çok katmanlı güven inşası — İsviçre peyniri modeli
- LLM'ler komutları iyi takip etmez, sık sık sapar ve öz doğrulamada da güvenilir değildir (kod yanarken bile kendinden emin şekilde "çalışıyor" diyebilir)
- Çözüm, LLM'den doğrulama yapmasını istemek değil; doğrulayan script'i yazmasını sağlamak — yargıdan çıktıya geçiş
- Güven katman katman inşa edilir; İsviçre peyniri modeli uyarınca kusurlu filtreler üst üste konur ki delikler hizalanmasın
Layer 1: Çoklu seçenek karşılaştırması
- Tek bir ajandan doğru cevabı istemek yerine, üç ajanın farklı yollarla denemesi ve en iyi sonucun seçilmesi
- Seçimin manuel olması gerekmez; en fazla doğrulama adımını geçen, en küçük diff'e sahip olan veya yeni bağımlılık eklemeyen seçenek gibi ölçütlerle sıralama yapılabilir
- Seçenek üretmenin maliyeti, yazılım mühendisliği tarihinde görülmemiş derecede düşük
Layer 2: Deterministik guardrail'ler
- Yapılan işi doğrulamak için deterministik yöntemlere ihtiyaç var — testler, type check, contract doğrulama gibi; yani görüş değil olgu temelli şeyler
- LLM'ye "Bu oldu mu?" diye sormak yerine, bir dizi pass/fail çıktısı üreten doğrulama adımları tanımlanmalı
- Guardrail hiyerarşisi:
- Kodlama yönergeleri — özel linter'larla uygulanabilir
- Kuruluş genelinde değişmez kurallar — hardcode edilmiş credential, API key, token yasağı gibi pazarlık konusu olmayan kurallar
- Alan sözleşmeleri — framework, servis veya codebase bölgesine özgü kurallar (ör. ödeme alanında tüm tutarlar Money tipi kullanmalı)
- Kabul kriterleri (Acceptance Criteria) — işe özel benzersiz ölçütler
- Doğrulama adımları kod yazılmadan önce tanımlanmalı; var olan şeyi kontrol etmek için sonradan oluşturulmamalı
- Ajan hem kodu hem testi yazıyorsa, bu sadece sorunu başka yere taşımaktır; doğrulama ölçütü implementasyondan değil spesifikasyondan gelmeli
Layer 3: Kabul kriterlerini insanlar tanımlar
- İnsanın değer kattığı nokta, üst akışta başarının tanımını yapmak
- BDD (Behavior-Driven Development) yeniden anlam kazanıyor
- Beklenen davranışın doğal dille tarif edilip testlere otomatik dönüştürülmesi
- Geçmişte kod da yazmak gerektiği için spesifikasyon yazmak ek iş gibi geliyordu; ama ajan ortamında spesifikasyon birincil çıktıdır
- İnsan spesifikasyonu yazar, ajan uygular ve BDD framework'ü doğrular — başarısız olmadığı sürece implementasyonu okumaya gerek yok
- İnsanın iyi olduğu şeyler: "doğruluğun" tanımı, iş mantığının ve edge case'lerin kodlanması, neyin ters gidebileceğini düşünmek
- İnsan tarafından yazılıp makine tarafından doğrulanan kabul kriterleri asıl önemli kapıdır
Layer 4: Yetki sistemlerini mimarinin parçası yapmak
- Ajanın neye dokunabileceği ve neyin eskalasyon gerektirdiği bir mimari karar olmalı
- Çoğu ajan framework'ü yetkileri all-or-nothing şekilde ele alıyor; oysa ayrıntılı yetkilendirme önemli
- Bir utility function hatasını düzelten ajanın altyapı yapılandırmasına erişmesi gerekmez
- Test yazan ajanın CI pipeline'ını değiştirme yetkisine ihtiyacı yoktur
- Kapsam, ajanın faydalı iş yapabilmesine izin verdiği sürece olabildiğince dar tutulmalı
- Örn: "utils/dates.py içindeki tarih ayrıştırma hatasını düzelt" görevinde yalnızca ilgili dosya ve test dosyalarına erişim verilmeli
- Eskalasyon tetikleyicileri de önemli: kimlik doğrulama mantığını değiştirmek, veritabanı şemasını değiştirmek, yeni bağımlılık eklemek gibi belirli kalıplar, ajanın güven düzeyinden bağımsız olarak otomatik insan incelemesini tetiklemeli
Layer 5: Adversarial doğrulama
- Sorumlulukların ayrılması: bir ajan işi yapar, başka bir ajan doğrular — esas nokta birbirlerine güvenmemeleridir
- Bu, QA ekibinin mühendislik yöneticisine raporlamaması ya da kodu yalnızca yazanın incelememesi gibi eski bir prensibin uzantısı
- Bu mimari olarak zorlanabilir: kodlama ajanı, doğrulama ajanının neyi kontrol edeceğini bilmez; doğrulama ajanı da kodu değiştiremez — sistem tasarım gereği adversarial olur
- Daha da ileri gidilerek üçüncü bir ajan, ilk ajanın ürettiğini edge case'ler ve failure mode'ları hedef alarak bozmayı deneyebilir — her değişiklikte red team/blue team otomasyonu
"İyi kod"un anlamı değişiyor
- Ajan sistemlerinin teşviki basit: verilen görevi tamamlamak ve talimatı vereni memnun etmek — uzun vadeli doğruluk ya da iş gereksinimleri onların içsel motivasyonu değil
- Bunu kısıtlara kodlamak insanın görevi
- Ajanların ürettiği ve ajanların okuduğu kodda "iyi kod"un biçimi daha standartlaşmış olacak; yeni bir codebase'e verilmesi gereken yön azalacak
- Geleceğin yönü: "hızlı dağıt, her şeyi gözlemle, daha hızlı geri al"
- Tersi: "yavaş incele, yine de bug kaçır ve production'da debug et"
- Makineleri daha fazla okuyarak kazanılamaz; kararların gerçekten önemli olduğu üst akışta makineden daha iyi düşünmeye ihtiyaç var
- Ajanlar kodu iyi işleyebiliyorsa, insanların o kodu okuyup okuyamaması artık önemli değil
25 yorum
Kod incelemesi darboğaz diye inceleme yapmayalım demek hem yaratıcı hem de güldürüyor hahaha
Yapay zeka öncesinde herkesin kod incelemesinin gerçekten iyi çalışıp çalışmadığını merak ediyorum.
Kod incelemesini hızlı ve özenli yapan organizasyonlar zaten oldukça nadirdi.
Birçok geliştiricide kod incelemesi, yapay zeka öncesinde de savsaklanıyor, birikiyor ve özensiz yapılıyordu.
Benim deneyimime göre Amerikan teknoloji şirketleri kitabına uygun davranıyordu; Kore dahil diğer ülkelerdeki şirketler ise karmakarışıktı.
Tersinden söylersek, inceleme ne kadar titizse iş stresi o kadar yüksekti; kötü yürütülen incelemeler ise görece daha rahattı
Bence review’un ortadan kalkması, davranış ödüllerinin bir sonucu.
Şirketin talep ettiği şey
düşük hata oranıysa review’u daha güçlü şekilde zorunlu kılar
hızlı özellik yayınıysa review zamanla atlanır
Review’un ortadan kalktığından söz ediliyorsa, şirketlerin tercih ettiği şeyin hızlı özellik yayını olduğu hissine kapılıyorum
Ama yatırımcı olsam ben de muhtemelen bunu talep ederdim, hehe
Pek emin değilim. İncelemenin darboğaz haline geldiğini söyleyip bu yüzden inceleme yapmayalım demek, sanki işin özünü unutmak gibi geliyor bana. Bence bunun yerine, implementasyon süresi kısaldığı ölçüde inceleme süresini zorunlu olarak ayırmak daha iyi bir yöntem olabilir.
Denemeye değer bir fikir gibi, ancak şimdilik bunun için henüz erken olduğu görüşü baskın gibi görünüyor.
Kara kutuları biriktirmeye devam mı edelim?
Kod sanki bir kara kutuymuş gibi yazılıp sadece sonuca bakalım... yani mesele bu gibi... Acaba bu gerçekten arzu edilen bir yön mü.. Bana göre bir gün mutlaka mevcut yapay zeka tarafından yazılmış kodların hepsinin sil baştan elden geçirileceği bir zaman gelecek.
Bu, "FSD daha akıllı hale geldiğine göre sürücü uyusa da olur." sözüne benzer şekilde düşünülebilecek bir mesele gibi görünüyor.
Teknik olarak giderek böyle bir çağın geleceği hissi var, ancak sorumluluk eşiğinin nasıl aşılacağı asıl önemli nokta gibi duruyor.
Bence kod incelemesi en azından asgari bir güvenlik mekanizmasıdır.
Daha üst düzey bir kavram olan niyet doğrulamasını neden insan yapıyor..?
Aslında programlama diliyle kod yazdırmaya bile gerek yok.
Aynı promptun AI'ye verildiğini varsayarsak, ortaya çıkan sonucu incelemenin modelin performansını test etmeye benzer bir şey olduğu düşüncesine kapılıyorum.
Sonuç en baştan belirlenip LLM'e yazdırılmış gibi. Saçma sapan laf cambazlığı.
Prodüksiyon deneyimi hiç yok gibi.
Tam bir hayal gibi geliyor bana.
Zaman geçtikçe dokümantasyonun da pek anlamı kalmıyor ve incelemeler de daha katı hale gelmiyor mu?
Evet~ böyle bir tartışma yaratıp düşündüren bir yazı olmasıyla bile niyet zaten fazlasıyla anlaşılmış.
Çeviri yazısıdır: https://rosetta.page/post/…
Bu aslında en başta plan aşamasında elenebilecek bir sorun.
Kodu elle yazma sürecinde geliştirici doğal olarak planlama da yapar, tasarım da yapar, keşif de yapar, anlama da yapar, test de yapar, öz inceleme de yapar; ayrıca sorun çıktığında sonradan nasıl müdahale edeceği sürecini örtük ve paralel biçimde yürütür, bu yüzden her bir yön doğal olarak birbirine uyumlanır. Yani test ya da inceleme eksik olsa bile bir ölçüde işler halde kalabilmesinin sebebinin bu olduğunu düşünüyorum.
Ama elle yazma sürecini ortadan kaldırdığınızda, örtük olan süreçlerin sınırlarını açıkça çizmeniz gerekir. Kodu yazan özne ile inceleyen özne daha da fazla ayrıştığı için iletişimdeki verimsizlik artar. Kodu yazan tarafa duyulan güven daha da düştüğü için inceleme maliyeti de artar.
Bunun
doorman's fallacykavramına benzer bir şey olduğunu düşünüyorum.Benim de şirkette sık sık düşündüğüm bir konuydu; güzelmiş, kişisel olarak geliştirdiğim Harnis'e de uygulamayı denemeliyim.
Bence zamanla incelemeler giderek daha da sadeleşir ve yönelim testleri çok daha sıkı hale getirmeye doğru kayar.
Sanırım burada mesele basitçe kod incelemesini ortadan kaldıralım demek değil; onun da üstünde yer alan, niyeti ve o niyetin doğru çalışıp çalışmadığını açıkça doğrulayabilen çıktılar üzerinden inceleme yapalım demek gibi görünüyor.
Mevcut durumda, tasarım veya mimari seviyesi değil de kod uygulamasının detaylarını bir kara kutu olarak tutmanın arzu edilir olduğunu düşünüyorum.
O kara kutunun birikerek, yapay zekanın bile düzgün şekilde müdahale edemeyeceği bir noktaya kadar gidebileceğini düşünüyorum. Herkes kolaylığın sarhoşluğuna fazla kapılmış gibi görünüyor. Bir gün büyük bir kazanın yaşanacağını düşünüyorum.
Ben de üstteki kişinin görüşüne katılıyorum. Diyelim ki bir gün modelin insan kodundaki bazı bölümleri yanlış öğrendiği ortaya çıktı ve bunun bugüne kadarki koda yansıdığını fark ettik; o gün her şeyi altüst eden gün olabilir..
En güncel model ne kadar iyi olursa olsun, SWE benchmark'ında tam puanı "her zaman" (6 nine, 0.999999) alamıyorsa, bence olasılık hâlâ açık.
Niyet incelemesi. Güzel bir ifade.
Yapay zeka ile hızlanan çağda buna nasıl ayak uyduracağımı düşünüyordum,
Kod incelemesine dair yeni bir bakış açısı sunan güzel bir yazı!