Yapay zeka çağında kod incelemesi nasıl yapılmalı?

• 15 yıllık CTO deneyiminden yola çıkarak yapay zeka çağındaki kod incelemesi tartışmasını tez-antitez-sentez olarak derleyen bir deneme
• Kod incelemesi her zaman bir sorundu — zaman, insan ve süreç her zaman yetersizdi
• Yapay zeka kod üretim miktarını patlattı, ancak inceleme kapasitesi aynı kaldı → darboğaz daha da büyüdü

Tez — insan incelemesi zorunludur

• Simon Willison: "İncelemediğiniz kodu ekip arkadaşlarınıza yüklemeyin"
• Kent Beck: üretim maliyeti sıfıra yaklaştıkça değer üretimden doğrulamaya kayar
• Addy Osmani: "Çözülmemiş mesele üretim değil, doğrulamadır"
• Yapay zeka ne kadar iyi olursa olsun sorumluluk insandadır → doğrulamak gerekir → incelemek gerekir

Antitez — insan incelemesi çağının sonu

• Bryan Finster: Nyquist-Shannon teoremi uygulanırsa — yalnızca üretim frekansı artıp geri bildirim frekansı sabit kalırsa sistematik olarak bir şeyler kaçırılır
• SmartBear verisi: 400 satırı aşınca kusur tespit oranı sert düşüyor, yapay zeka ise tek seferde 600 satır üretiyor
• StrongDM "yazılım fabrikası": insan kod yazmıyor, kod da okumuyor. Yalnızca niyet tanımı ve senaryo kürasyonu yapıyor
• Stanford CodeX: "Ajan üretip test ediyorsa, buna kim güvenebilir?"
• Salesforce Prizm: diff merkezli inceleme modeli yapay zeka çağında artık işlemiyor → niyetin yeniden kurulması gerekiyor

Sentez — neyi incelemeliyiz?

• latent.space: kod incelemesinden niyet incelemesine (Intent Review) geçiş
• Gerçeğin kaynağı spesifikasyondur, kod ise çıktıdır
• Güveni 5 katmanlı bir yapıyla inşa etmek (İsviçre peyniri modeli)
• Qodo deseni: önce bağlam, sonra ciddiyet temelli, ardından uzman ajan incelemesi
• Bryan Finster: insanın engelleyici olarak devreye girmesi gereken yalnızca iki durum var — bilgi eksikliği ve regülasyon yolu

Kapanış

• Yazar, yapay zeka tarafından yazılan kodu doğrudan incelemiyor → QA rolüne geçiyor
• Yapay zeka yerel mühendisi = önceki dönemin PM rolünü artık kendisi üstlenmeli
• "Kendi kodunuzun sorumluluğunu üstlenebiliyor musunuz?"

[kgcrom]

https://app.devin.ai/review

Henüz "orta nokta hatası" gibi bir başka gelip geçici yöntem mi, bilmiyorum ama
AI ile birlikte PR review yaparken kodu anlamayı ve bug düzeltmeyi mümkün kılan bir araç olduğu için paylaşıyorum.

Yan proje yaparken, AI’ın yaptığı kod değişikliklerini anlamadığımda kullanıyorum.

[pencil6962]

Orta nokta hatası (Argument to Moderation): İki uç iddia (A ve Z) olduğunda, bunların orta noktası (M) mutlaka doğru ya da en iyi çözüm olacakmış gibi varsayan bir mantıktır.

[overthinker]

Yarı yarıya bakıldığında, insan incelemesi sonuçta darboğaz oluyor

[vk8520]

Yarısı yarıya yaklaşımın bile şimdilik gerçekçi olmadığını düşünüyorum. Kod sürekli kullanılan bir şey ve LLM'ler olasılıksal olduğu için, insanın kendi yazdığı kodun tamamını (en azından şimdilik) okuması gerekiyor. İncelemeyi kolaylaştırmak, bağlamı ve niyeti anlamayı sağlamak için PR'ı otomatik bir şablonla yazdırmak ya da bunu ADR olarak yazmak yine de gerekli.