Yapay zeka kod incelemesinin neden geçerli bir karşı argüman olamayacağı

• LLM kodlama araçlarının sık yaptığı hataları insanların tamamen incelemesinin yeterli olacağı çözümü, kod incelemesinin işlem sınırları nedeniyle kaliteyi ve verimliliği birlikte garanti etmeyi zorlaştırır
• Ampirik araştırmalara göre etkili bir inceleme için tek seferde üst sınır yaklaşık 1 saat·400 LOC’tur; bunun aşılması yorgunluk ve dikkat düşüşü nedeniyle kusur tespit etkisini hızla azaltır
• Bu ölçüt uygulandığında, LLM’in yazdığı her 400 LOC için deneyimli bir geliştiricinin 1 saatlik odaklı incelemesi gerekir; gerçekçi günlük işleme kapasitesi 1.000 LOC’nin altında olabilir
• İnsanların LLM tarafından üretilen kodda daha az kusur bulurken daha güçlü bir özgüven gösterdiğine dair erken kanıtlar var; bu nedenle yalnızca incelemeyle hataların yeterince ayıklanabileceğini varsaymak zordur
• LLM kodunun kusur tespit oranını, inceleme hızını ve günlük sürdürülebilir hacmini doğrudan ölçen ve yeniden üreten ampirik araştırmalar olmadan, araçların etkinliği anekdotlarla değil kanıtlarla değerlendirilemez

---

LLM kodlama araçlarına neden şüpheyle bakıyorum

• Sorunun odağı fikri mülkiyet, ekolojik maliyet, kaynak tüketimi ya da LLM çıktılarının tamamının berbat olduğu değerlendirmesi değildir
• Mevcut bilimsel kanıtlarla, LLM kodlama araçlarının geliştiricilerin kodu daha iyi veya daha hızlı yazmasına nasıl yardımcı olduğunu doğrulamak zordur
• Savunular, ilgili sorunları ve kanıtları doğrudan ele almaz; şüpheciliğe verilen yanıtlar bazen sorunu daha da güçlendirir
• Yaklaşık bir yıl önce yazılmış bir metin olduğu için bugün büyük ölçüde yerini başka ifadelere bırakmış olan Coding Assistants terimini kullanır; ancak üretken yapay zekanın çeşitli kodlama kullanım alanlarını kapsayacak başka bir terim bulunamadığından aynen korunmuştur

“Stajyer” benzetmesi ve tam inceleme çözümü

• LLM kodlama araçları, çalışma yapıları ve etkileşim arayüzleri gibi nedenlerle nispeten yüksek hata riski taşır
  • Halüsinasyonlar veya yazım hataları üretebilirler
  • İstekle ilgisiz sonuçlar verebilir veya işi başka bir yoldan ilerletebilirler
• Kullanıcılar bu araçları sık sık stajyere benzetir
  • Sonucun bir ölçüde yanlış olacağını beklemek gerekir
  • Ne yaptığını tam anlamadan çalıştığını varsaymak gerekir
• Yaygın yaklaşım, tıpkı stajyer ya da junior geliştirici kodunda olduğu gibi, deneyimli bir kişinin sonucu tamamen gözden geçirmesidir
  • Bu, insanın daha iyi bildiği ve nihai sorumluluğu da taşıdığı varsayımına dayanır
  • Kod tabanına giren her kodun zaten inceleme konusu olduğu mantığı da bunu izler

LLM denetimi için gereken inceleme düzeyi

• Sektörde ve araştırma literatüründe inceleme, birbirinden farklı birçok pratiği kapsar
• Hafif ve birden fazla kişiye dağıtılmış incelemeler, değişikliklere dair bilgiyi paylaşmak ve yüzeysel kuralları uygulamak için yararlıdır; ancak LLM kodunu denetleme ölçütü olarak yetersizdir
• Geçmişteki komite tarzı kontroller gibi saatlerce her satırı acı verici biçimde kontrol etmeye gerek yoktur; yine de oldukça derin ve eksiksiz bir kod incelemesi gerekir
• LLM karmaşık kod yazabildiği ve yazılımın ayrıntılarında kusurlar saklanabildiği için hafif bir kontrol yeterli değildir

Kod incelemesinin karşılaştığı ampirik sınırlar

• Ampirik araştırmalarda etkili inceleme için belirlenen başlıca sınırlar şunlardır
  • Tek bir inceleme oturumu 1 saati aşarsa aşırı uzar
  • Bu sürede etkili biçimde incelenebilecek miktar en fazla yaklaşık 400 LOC’tur
• 1 saati aşan incelemelerin etkisi, kodun boyutundan bağımsız olarak hızla azalır
  • Bunun nedeni yalnızca çoğunun zaten incelenmiş olması değildir
  • Yüksek konsantrasyonu 1 saat sürdürmek yorgunluk ve sıkılma yaratır; ara vermek gerekir
• 1 saatlik oturumlar arasında gereken toparlanma süresini inceleyen bir araştırma bulunamamıştır
  • Uç bir üst sınır olarak günde birkaç kez varsayılabilir
  • Ortalama olası sayı olarak günde yaklaşık 2 kez önerilir, ancak kesinleşmiş bir rakam değildir
• Saatte incelenebilecek kod satırı sayısı; kodun bağlamına ve türüne, inceleyenin deneyimine ve bilgisine göre büyük ölçüde değişir
• Mutlak bir ölçüt olmasa da 400 LOC/saat’ten daha hızlı yapılan incelemelerin kusurları etkili biçimde bulup işaretlediği örnekler ampirik verilerde neredeyse yoktur; bu nedenle bu, pratikte etkili azami hız olarak görülebilir

LLM koduna uygulanan kapasite hesabı

• LLM kodundaki sorunları incelemeyle çözmek için en iyi durumda bile üretilen her 400 LOC başına deneyimli geliştiriciden 1 saat gerekir
• Bir geliştiriciye haftada yaklaşık 10–40 inceleme oturumu ayrılabilir; her oturum arasında uzunluğu bilinmeyen bir toparlanma süresi gerekir
  • Toparlanma süresi en az 1–2 saat olabilir, ancak bunu destekleyen doğrudan araştırma yoktur
• Bu odaklanma süresi toplantılar, tasarım, olay müdahalesi ve bizzat yazılacak kod üzerine düşünme için de kullanılmalıdır
• En iyi durumda, LLM kullanan bir geliştiricinin yazıp inceleyip commit edebileceği miktar günde birkaç bin LOC’dir
• Gerçekçi bir senaryoda günlük işleme kapasitesi 1.000 LOC’nin altında olabilir
  • Buna boilerplate, testler, migration’lar ve yapılandırma dosyaları dahildir
  • Tek bir test dosyası bile 400 LOC’yi aşabilir
• Kodun büyük bölümü basit ve incelemesi kolay olsa bile, en iyi koşullarda inceleme verimlilik artışının üst sınırı olarak işlev görür

İnsan kodu ile LLM kodunun incelenmesi arasındaki fark

• Mevcut kanıtlar, insan tarafından yazılmış koddaki kusurları insan inceleyicilerin bulduğu durumlardan gelir; aynı verimliliğin LLM koduna da uygulanacağına dair kanıt yoktur
• Erken kanıtlarda, LLM tarafından üretilen kodu inceleyen kişilerin daha az kusur bulduğu, buna karşın tüm kusurları bulduklarına dair özgüvenlerinin daha güçlü olduğu eğilimi görülür
• İnsan yazar ve insan inceleyici kombinasyonuna kıyasla, LLM kodlama aracı ve insan inceleyici kombinasyonu daha düşük kaliteli sonuçlar üretirken, ikinci gruptaki inceleyici kendi performansını daha yüksek değerlendirebilir
• Tam inceleme, LLM’in verimlilik avantajını sınırlamakla kalmaz; sık hataları gerçekten çözdüğüne dair sağlam kanıttan da yoksundur

Kusurları düzeltmeden önce ortaya çıkan maliyet

• Bu hesap, bulunan kusurları düzeltme maliyetini içermez
• Yalnızca profesyonel geliştiricinin iş ortamında kodu inceleme ve sorunları işaretleme yeteneğini ve maliyetini ele alır
• LLM’in yarattığı kusurların sayısı veya ciddiyeti ne olursa olsun, üretilen kodu inceleme maliyeti ortaya çıkar
• LLM kodlama aracı çok yüksek kaliteli kod üretse bile, tüm sonuçların inceleneceği koşulunda aynı maliyet ve verimlilik sınırı kalır

İncelemesi zor kodu araca bırakma çelişkisi

• LLM savunuları, insanların yazmayı zahmetli bulduğu kodu aracın onların yerine üretebilmesini bir avantaj olarak sunar
• Bir örnek, bundan sonra gereken Bash kodunun %100’ünün LLM tarafından yazılmasını önerir
• Shell script’leri gevşek biçimde ayrıştırılır ve anlamları aşırı iç içe geçmiştir; tek bir noktalama hatası zararsız olabilir ya da tüm bilgisayarı silmeyle sonuçlanabilir
• Bu tür kodlar hata üretmeye elverişlidir, anlaması ve incelemesi zordur; ölümcül hataları fark etmek de güçtür
• Rastgele hatalar yapan bir araca incelenmesi en zor kodu emanet edip sonra insanın kontrol etmesi yaklaşımı, LLM çıktısının gerçekten etkili biçimde incelenebilir olduğunu önce kanıtlamaz
• İncelemenin hataları çözüp çözmediğine ve yeterli verimlilik artışının geride kalıp kalmadığına yanıt vermeden, incelenmesi en zor kodu başlıca kullanım örneği yapmak sorundur

Doğrulanması gereken ampirik görevler

• İlk görev, insan inceleyicilerin LLM tarafından üretilen koddaki kusurları ne kadar iyi bulduğunu ölçmektir
  • Kusur tespit becerisi
  • İnceleme hızı
  • Gün boyunca sürdürülebilecek inceleme miktarı
• İnsan tarafından yazılmış kod üzerine yapılan araştırmalarda olduğu gibi, insanların LLM kodunu incelediği verilere ihtiyaç vardır
• Mevcut deneyler ve ampirik veriler ölçek ve bağlam bakımından sınırlıdır; bu nedenle daha fazla yeniden üretim çalışması gerekir
• Mevcut bilimsel veriler, insanların LLM sonuçlarını iyi inceleyemediği ya da bu sorunları tespit etmenin zor olduğu yönüne işaret eder
  • Bu, LLM’in tespitten kaçınacak şekilde eğitilmesi özelliğiyle uyumlu olabilir
  • Mevcut sonuçların tesadüf olma ihtimali de doğrulanmalıdır
• İkinci görev, LLM çıktılarının incelenmesinin insan yazımı çıktıların incelenmesinden niteliksel olarak farklı bir sorun olup olmadığını doğrulamaktır
  • Fark, mevcut kod inceleme araştırmalarının uygulanamayacağı kadar büyükse, mevcut eleştiri mantığı çökecek olabilir
  • Ancak erken kanıtlar, LLM tarafından üretilen kodun incelenmesinin daha kolay değil daha zor olabileceğine işaret eder; bu durumda eleştiri aksine güçlenir

Anekdot değil, profesyonel araçların ampirik değerlendirmesi

• Kod incelemesi hakkında bilinenler dikkate alındığında, mevcut arayüzleri ve süreçleri kullanan LLM araçlarının profesyonel geliştiricilere ne fayda sağladığını doğrulamak zordur
• Tedarikçilerin kanıtlarla çelişen araç ve süreçleri tekrar tekrar sunmasından çok, sorunları ele almadan şüphecileri anormalmiş gibi gören tutum daha büyük bir memnuniyetsizlik konusudur
• TDD, tip sistemleri, test ve geliştirme organizasyonlarının ayrılması, CI/CD ve DevOps’ta da ampirik kanıtlardan çok anekdotların baskın olduğu örüntü tekrarlanmıştır
• “Bu kez bende işe yaradı” örneklerine dayanmak yerine, kod incelemesine dair ampirik kanıtların oluşturulduğu yolu izleyerek gerçek araştırmalar yapılmalıdır
• LLM kodlama araçlarını profesyonel geliştirme araçları olarak ele almak için, etkileri ve sınırları insan faktörleri ve ampirik kanıtlar merkezinde doğrulanmalıdır

[GN⁺]

Lobste.rs görüşleri

• Tek hedefin yalnızca hız olması gerekmiyor. Hata düzeltmeleri ayrı hazırlık commit’lerine bölünüp bağımsız incelenebilir, yanlış durumları ifade edebilen tip yapıları düzeltilebilir ve test güveni yetersizse özellik tabanlı test, fuzzing ve biçimsel yöntemler denenebilir.
  Eskiden bu işler tek bir commit’e doldurulur ya da teknik borç TODO’su olarak bırakılırdı; şimdi ise bunları düzgün uygulamanın marjinal maliyeti şaşırtıcı derecede düştü. LLM açık uçlu bir araç olduğu için, kullanıcı hangi değerlere önem veriyorsa o ölçüde fayda sağlıyor.
  Elbette tamamlanmayıp üretime hiç ulaşmayan prototiplerin artması gibi bir risk var, ama genel olarak titizliği önemseyen mühendislik için büyük fayda sağlıyor.

  • Bu değerlendirmeye güçlü biçimde katılmakla birlikte, çoğu şirkette gerçekte olanın farklı olduğunu düşünüyorum. LLM’ler titizliği artırabilirken, çoğu zaman en düşük kaliteli MVP yarışı için kullanılıyor.
    Bu bir şirket kültürü sorunu olabilir ama yine de hayal kırıklığı yaratıyor; sektörün kendine gelip daha yüksek kaliteli yazılımlar üretmesini umuyorum.

• Eski bir projeye ajanı tek bir prompt ile sokunca, büyük çaba harcamadan gerçek hataları sürekli buluyor. İnsanlar da özensiz olabiliyor, ben de hata yapıyorum; ama LLM hızlıyken birçok açıdan daha aptal olduğu için bu sorun daha erken görünür oluyor.
  Hatalar birikir; bu yüzden ajanların kodu rastgele değiştirmesine izin verilirse sistem hızla bozulur. Ama naif kullanımın istikrarsız olmasından hareketle aracın kendisini işe yaramaz saymak da tembelce bir yargı.
  Şu anda her değişiklikte mimari, bakım yapılabilirlik, güvenilirlik ve güvenlik gibi boyutları kapsayan 5 uzman incelemesini otomatik çalıştırıyorum; ayrıca bunları tasarım belgesi sistemi içinde düzenleyerek ajanın karar alma kalitesini ciddi biçimde iyileştiriyorum. Kusursuz değil ama naif yaklaşımdan daha iyi, üstelik daha da geliştirilebilecek olması yeni araçlarla uğraşmanın eğlenceli tarafı.

  • Burada yalnızca kod üretimi ve incelenmesi ele alındı; olasılıksal metin analiziyle hata kalıplarını bulma kullanımından söz edilmiyordu.

• Prompt ile daha hızlı üretmek mümkün olsa da, doğrulama ve anlama için daha fazla zaman harcanıyor; bu da baştan kendim yazsaydım daha hızlı olur muydu diye düşündürüyor. Hangi yolun daha iyi olduğuna karar vermek bile zaman ve enerji istiyor; o kaynağı başka yere harcamak istiyorum.
  Yine de PR’ı gönderen kişi sahiplenme ve sorumluluğu üstleniyorsa LLM kullanılıp kullanılmadığı önemli değil. Kalite, doğruluk ve tutarlılık ölçütleri karşılanıyorsa daha hızlı yöntem seçilebilir; sorumluluk yine insan yazarda kalır.
  Bana göre AI öğrenmek ve anlayışı genişletip derinleştirmek için iyi, ama yalnızca giriş süresini değil tüm süreci hesaba katınca, şimdilik kodu doğrudan yazmak hâlâ daha üretken.

• Yazının neredeyse 1 yıl önce yazılmış olması başlı başına sorun. Son 6 ayda, özellikle de son 3 ayda, güncel ücretli bulut modellerinin kullanışlılığı ciddi biçimde arttı.
  Denetim işinde geliştirdiğim MFIC ilkeleri gibi, tüm başarısızlık kategorilerini engelleyen kontrol mekanizmalarının olup olmadığına bakmak gerekiyor: https://gist.github.com/pmarreck/b30aa3ca69cb70a5526f8a63ab8c8d7e
  Mevcut kodu ve proje yapısını bağlam içinde tutan https://github.com/pmarreck/dirtree ve https://github.com/pmarreck/codescan gibi araçlar da gerekli; bunlar kod tabanını unutmuş ya da ona aşina olmayan insan geliştiriciler için de yararlı.
  Sonuçta ya bunları düzgün kullanıp avantaj elde edersiniz ya da doğrudan özel kod yazar, bu sırada hatalar ve güvenlik açıkları üretip daha hızlı rakiplere geçilirsiniz. Desk.com’un artık terk edilmiş milyon satırlık Ruby on Rails kod tabanında 2 insan-yılı harcamış biri olarak şunu söyleyebilirim: kurumsal kod geçicidir, bu yüzden LLM üretimi kodla iyi uyuşur.
  Erlang’ın iç implementasyonu söz konusu olsa güvenmek zor olurdu, ama işlev düzeyinde yazdırıp sonra incelemek mümkün; bazen beklediğinizden iyi de çıkabilir. Örgü şişiyle dokuma tezgâhından yalnızca birini seçmek yerine, duruma göre ikisini de kullanmak idealdir.

  • İç implementasyon değil, ben de kurumsal kodla uğraşıyorum ve LLM kullanıcılarının bıraktığı kodu toparlayan kişiyim. Az önce söylediklerin, asıl metindeki hiçbir cümleyi çürütmüyor; hatta tersine destekliyor.
  • Son 6 ayda ya da 3 ayda büyük gelişme olduğu söylemi en az 2 yıldır tekrar ediliyor.

• Kişisel deneyimime ve çevremdeki güvenilir, deneyimli geliştiricilere bakınca, LLM’lerin daha iyi ve daha hızlı kod yazmayı tekrar tekrar mümkün kıldığını görüyorum; bu yüzden bilimsel kanıtların bunun faydalı olamayacağını söylediği türden yazıları ciddiye almak zor.
  Hakemli makaleler olmasa da yeterince şey gördüm; METR araştırması geliştiricilerin üretkenlik artışı tahminlerine itiraz ediyor diye mevcut yargımı değiştirmem.

  • Kendine araştırmacı diyen birinin kişisel deneyim tek başına yeterlidir demesi, şaşırtıcı derecede düşük bir kanıt standardı.
  • Kişisel deneyim, doktorlar el yıkamayı reddederken ya da kan almayı savunurken de kullanılıyordu. İnsanların ölmesine yol açan bu deneyimlere güvenme tarihine karşı bilim inşa edildi.
    Titiz ve yöntemsel olarak sağlam biçimde, mevcut güçlü ampirik çalışmalardan nerede ayrıldığını gösterirsen fikrimi değiştirmeye hazırım. Ama kişisel deneyim ya da açıklamasız on iki anekdot yetmez.
    Bilim ve mühendislik milyarlarca insanın hayatını iyileştirdi; birinin kendisinin daha iyi bildiğine inanması yüzünden bunlardan vazgeçemeyiz.
  • Karşı tarafı ikna edecek kanıt istendiğinde, “Ben zaten ikna oldum, daha fazlasına gerek yok” diye yanıt vermek, soruya cevap vermemek demektir.
    Kimseye tarikat mensubu demek istemem ama, inanca yönelik itirazı kişisel algılayıp başkalarını nasıl ikna edeceğini bilmeyen tavır tarikatvari iletişim tarzına benziyor.
  • Kod üretimi için LLM’ler konusunda hâlâ temkinliyim, ama PR’ı yazanın insan mı makine mi olduğu önemli değil; aynı kalite standardı uygulanmalı.
    Çoğu LLM üretimi PR’da bile gönderen kişi sorumluluğu üstlenmeli ve değişiklikleri başkalarının anlamasını kolaylaştıracak bağlam ve boyuta bölmelidir. Kod hâlâ yazılımın nihai spesifikasyonudur; geliştiricinin ona sahip olması ve onu anlaması gerektiği gerçeği değişmedi.

• 1 yıl önce AI ajanlarının çok hata yaptığı iddiası doğru, ama bugün de öyle olup olmadığı belirsiz; geçen yılın kasım ayı civarında frontier modellerde bir kırılma noktası hissettim.
  LLM’lerin kod miktarını artırarak inceleme kapasitesi üzerinde yeni baskı oluşturduğu doğru, ama mühendisler buna fren koymalı ve inceleme hacminin gerçekten işleme kapasitelerine uygun kalmasını sağlamalı.

  • Hâlâ ciddi mimari hatalar yapıyorlar. Ortak davranışı çıkarıp yeniden kullanılabilecek durumları fark etmeyip yeni kod eklemek gibi.
    Daha kötüsü, yeni kod çoğu zaman çalıştığı için, temizlik yapılmadan birleştirilme olasılığı yüksek oluyor.

• Frontier modellerin muazzam miktarda kod yazmasına rağmen, kod silmeyi öneren negatif katkıyı ciddi biçimde araştırmamaları tuhaf geliyor. “The Best Code is No Code At All” - Jeff Atwood örneğinde olduğu gibi, soyutlama katmanlarıyla şişmiş kod tabanlarının karmaşıklığını çözüp satır silmeyi önerebilseler gerçekten yenilikçi olurdu.
  Belki bu zaten mümkündür ama ben henüz bizzat görmedim.

• Düzeltmek gerekirse, “The Limits Of Reviews” bölümü verimli azami hızı saatte 400 satır olarak veriyor; benim ilk düşündüğüm gibi inceleme başına 400 satır değil.
  Yine de 1 saat ve 400 satır sayılarının tam olarak hangi kod inceleme makalesinden geldiğini hâlâ merak ediyorum. Makale adını ayrıca kaydetmediysen tekrar bulmak için çok zaman harcamana gerek yok.

  • İlgili materyalleri bir yerde saklamıştım, bakabilirim. Çoğu saatte 100-200 satır sınırı veriyor ama bunların önemli kısmı, programlama dillerinin bugüne göre hatalara daha açık olduğu eski çalışmalar.
    Şu an seyahatteyim, birkaç gün sonra tekrar sorarsan söyleyeyim.
  • Saatte 400 satır bana şüpheli geldiği için kendi iş kayıtlarımla hesapladım. Son 6 ayda 139 bin satırlık değişime denk gelen 173 PR inceledim.
    Haftada 40 saatin %25’i incelemeye gidiyorsa saatte yaklaşık 540 satır, %15 ise 900 satır, %5 ise 2.700 satır ediyor. Gerçek işlem hacminin saatte 500-1.000 satır civarında olduğunu tahmin ediyorum; yani kaynağı verilmeyen o sayıya bir ölçüde yakın.

• AI üretimi kodun, insan yazımı koda göre daha fazla ya da daha az incelenmesi gerektiği mantığını anlamakta zorlanıyorum. Onay ölçütleri aynı olduğuna göre, aynı düzeyde inceleme yapılmalı.