- Yapay zekanın kod yazdığı çağda pull request (PR) inceleme yöntemi kökten değişmeli; mevcut inceleme süreci yapay zeka kodlama iş akışlarına uymuyor
- İncelemeci "Neden bunu böyle yaptın?" diye sorduğunda geliştiricinin bunu yeniden yapay zekaya sorup cevabı kopyaladığı bir yapı oluşuyor; bu da insanın aracı (middleman) rolüne sıkıştığı bir verimsizlik yaratıyor
- Yapay zekanın karar günlüğü (decision log) kodla birlikte kaynak kontrolde yer almalı; böylece incelemeci bağlamı doğrudan görebilmeli
- İncelemeci yorumlarını yapay zekanın doğrudan alıp patch ve yanıtları otomatik üretmesi; GitHub/GitLab webhook'ları ile MCP sunucusu birleşimiyle bugün zaten mümkün
- Tasarım belgeleri ve mimari diyagramlar da Markdown veya Mermaid gibi LLM tarafından ayrıştırılabilir formatlarla kaynak kontrolde bulunmalı; çünkü bağlam kraldır
Yapay zeka çağında code review'un sorunları
- PR incelemesinde soru sorulduğunda, geri gelen yanıt yapay zeka tarafından üretilmiş gibi duruyor; çünkü kodu gerçekte yazan da yapay zeka
- "Neden bu kütüphaneyi seçtin?" sorusuna insan geliştirici cevap veremiyor; bunun yerine yapay zekaya yeniden sorup cevabı kopyalayarak iletiyor
- Yapay zeka öncesinde soru doğrudan geliştiriciye (kodu yazana) sorulurdu, onun yöneticisine değil; dolayısıyla aracı kaldırılmalı
- Kodun tüm yazarları incelemeye katılmalı; inceleme sorularına sonradan ayrı bir yapay zeka ajanının gerekçeleri tersine çıkarsayarak cevap vermesi tamamen yanlış bir yaklaşım
Karar günlüğüne neden ihtiyaç var
- İnsana "Neden?" diye sormak, PR'ye dahil edilmemiş iç düşünce sürecini sormaktır
- Yapay zekanın chain-of-thought'u dışarıdan denetlenebilir (externally auditable) ve yapay zekayla etkileşim kayıtları da denetlenebilir olduğundan, bu bağlam incelemeye ve kaynak kontrole dahil edilmeli
- PR hazırlanırken üretilen tüm token'ları commit etmek gerekmez; bunun yerine Random Labs'in episode kavramından ilhamla yalnızca başarılı araç çağrıları ile sonuçların transkriptleri eklenmeli
- Bu yaklaşım bir agent swarm ortamında da ölçeklenebilir; PR öncesi aşamada karar günlükleri bağlanır ve son biçimlendirme yapılır
Satır içi yorumların sınırları
- Kaynak dosyadaki bir değişiklikte, yalnızca yorum değişse bile build pipeline'ın yeniden çalıştırılması gerekir (linting, derleme, test)
- Karar transkriptleri, sıradan satır içi yorumların izin verdiği boyuttan çok daha büyüktür
- Mevcut yorumlar kodun şu anda nasıl çalıştığını açıklar; o karara nasıl varıldığını değil
Yapay zeka entegre inceleme iş akışı
- İncelemeci yorum bıraktığında, geliştiricinin yapay zekası bunu doğrudan alıp patch ve yanıtları otomatik oluşturabilmeli
- Bu, GitHub/GitLab webhook'ları ve MCP sunucusu birleşimiyle bugün zaten uygulanabilir
- Devin AI veya GitLab Duo üzerinden Claude Code benzeri bir yaklaşım
- Sistem, geliştiricinin önce yapay zekaya izin vermesini isteyecek şekilde ya da yapay zekanın kendi karar verip doğrudan harekete geçeceği şekilde ayarlanabilir
- İnsan geliştirici de hâlâ yorumları ve değişiklikleri kendisi yapabilir
- İnceleme yorumlarının ancak saatler ya da günler sonra ele alınması veya hiç ele alınmaması sorununu büyük ölçüde azaltabilir
İncelemeciler için araç gereksinimleri
- İncelemeci de tıpkı codebase'i gezer gibi PR'yi yapay zekaya doğrudan sorular sorarak inceleyebilmeli
- Bunun için karar günlüğünün kodla birlikte check-in edilmiş olması kritik
- Mevcut PR arayüzü korunurken, yanında Codex veya Claude ile konuşulabilen bir pencere IDE benzeri bir deneyimle entegre edilmeli
- Henüz temiz, iyi bir araç yok; biri yaparsa harika olur
- Diff'te bilinmeyen kütüphaneler, yabancı diller veya best practice'ler hakkında yapay zekayla özel olarak soru-cevap yapıp ardından code review yorumu gerekip gerekmediğine karar verilebilmeli
- Yorum gerekiyorsa bu, karar günlüğünde bir boşluk (gap) olduğunun işaretidir; PR onaylanmadan önce günlük güncellenmeli
Tasarım belgeleri ve bağlamın önemi
- Yapay zeka entegre incelemede, incelemecinin doğrudan patch önermesi de çok daha kolay hale gelir
- Tasarım belgeleri, karar kayıtları (decision records) ve mimari diyagramlar Markdown veya Mermaid gibi LLM tarafından ayrıştırılabilir formatlarda kaynak kontrole eklenmeli
- "Bağlam kraldır (Context is king)"
10 yorum
PR’nin ölmesinin nedeni PR’nin kendisinden çok, Vibe coder’ların özensiz iletişimi gibi görünüyor.
Hangi flow ile implement edildiği, başka hangi yöntemlerin olduğu ve neden tercih edilmediği,
package.lockdosyasının neden değişmesi gerektiği. Bunların hepsi önce anlatılması gereken şeyler değil mi?PR Description’a yazılabilecek şeyi insanlara özellikle sorduran coder’ların yok olması daha iyi görünüyor.
Katılıyorum. Eskiden PR, ortaya çıkardığım şeyin sorumluluğunu benim taşıdığım hissini verirdi,
ama vibe coder’ın PR’ı daha çok "Ne yaptığımı ben de bilmiyorum ama her neyse ortada bir çıktı var; sen değerlendirip sorunları bul" gibi.
Katılıyorum.
Önce konuşulması gereken şeyler, sonradan sorumluluk alınmayan bir biçimde ilerliyor.
Katılıyorum. Sinir bozacak kadar kötü.
Katılıyorum.
Tek bir PR'da 500 dosya birden değişiyor ama gönderen kişi 30 dakika içinde inceleme yapılmadı diye çok şikayet ediyor. Açıklama kısmına da beş altı satır yazıp bırakıyor; buna güvenip onay vermem mi gerekiyor...?
Testlerin hepsi yapıldı değil mi?
Evet
Tamam, iyi iş çıkaralım
Neyi durmadan öldü ilan ediyorlar ki
Böyle giderse hepimiz ölürüz!
Bir şey olur olmaz “öldü” başlıklı yazılar fazla çoğalınca
insanı fazlasıyla yoran bir durum ortaya çıkıyor gibi görünüyor.
Ben de artık bir şeyleri öldürmeyi bıraksak iyi olur diye düşünüyorum.
"Öldü; yaşasın"
Tür olarak bu tarz yazılar gerçekten fazla arttı. Ama yapay zekanın her şeyi değiştirdiğini kabul ediyorum.