Yazar: The Pragmatic Engineer
Derin Akış TechFlow
Derin Akış Öne Çıkarıyor: AI kod yazma hızını artırıyor, ancak kod incelemesi hâlâ insanlar tarafından yapılıyor. Bu çelişki, bir krize dönüşüyor: Mühendisler, AI tarafından oluşturulan PR'lerle boğuluyor; ya incelemeleri dikkatsizce yapıyorlar, ya da AI hata vermediği için doğrudan onaylıyorlar. Büyük şirketler bu soruna kendi araçlarını geliştirerek yanıt veriyor, ancak şu ana kadar kimse standart bir çözüm sunamadı.
Merhaba, ben Gergely, bu Pragmatic Engineer Newsletter'in ücretsiz bir ek sayısı. Her hafta, deneyimli mühendisler ve mühendislik liderlerinin bakış açısıyla büyük teknoloji şirketlerini ve startup'ları haberleştiriyorum. Bugün, The Pulse dergisindeki dört konudan birini ele alıyoruz. Tam aboneler bu makaleyi bir hafta önce aldılar. Eğer bu e-posta size iletilmişse, buradan abone olabilirsiniz.
En çok dikkat çeken konu, sürekli artan kod inceleme yüküyle nasıl başa çıkılacağıdır. Bu konu bir süredir mevcut ve şu anda bu tür konuşmalar giderek artıyor.
Benim için bu, Ocak'ta Opus 4.5 ve GPT 5.4'ün çoğu şirketde daha fazla ve daha iyi kod yazmaya başlamasıyla başladı. O zamandan beri, direktör düzeyindeki kişiler, yazılım geliştirme darboğazının kodlama aşamasından inceleme aşamasına kaydığını tartışmaya başladı.
AI kod inceleme aracının patlaması
Şubat'tan beri, yük artışıyla başa çıkmak için AI kod inceleme araçlarında patlama yaşandı. CodeRabbit, Greptile, Qodo, SonarQube (şimdi Gitar da dahil) gibi özel AI kod inceleme araçlarının deneysel kullanımı ve benimsenmesi patlama halinde. Ayrıca Claude Code review, Cursor review, GitHub Copilot review gibi kodlama araçlarının kendileri tarafından sunulan araçlar da var. Daha önce kod incelemesine dahil olmayan ancak kod tabanına sahip olan araçlar da bu alana dahil olmaya başladığında, Sentry'nin Seer AI incelemeleri ve Linear kod incelemeleri gibi örnekler ortaya çıktı.
Büyük şirketlerin kendi iç araçları: Uber'in Code Inbox'ı
Büyük şirketler, kod inceleme deneyimini iyileştirmek için iç araçlar geliştiriyor. Uber'in Code Inbox'u bunun bir örneği:
Akıllı atama, inceleme sürecini ilerletmek için Code Inbox'da bulunan bir özelliktir:
Şekil: İnceleme sürecini ilerletmek için Code Inbox’un Akıllı Atama (Smart assignment) ayarları. Kaynak: The Pragmatic Engineer
Değişikliklerin etkisini değerlendirmek ve geliştiricilerin yüksek riskli değişikliklere özel dikkat göstermesini teşvik etmek için risk profili özelliği de mevcuttur:
Şekil: Code Inbox’in Risk Profilleri özelliği, kod değişikliklerinin riskini tahmin eder ve dikkat edilmesi gereken noktaları gösterir. Kaynak: The Pragmatic Engineer
Uber'ın yazılım geliştirme sürecinde AI'yi nasıl kullandığını haberlemiştik ve sadece Uber değil: Cloudflare (AI Code Reviewer), Faire (Fairey), HubSpot (Sidekick) ve birçok diğer şirket, içsel çözümlerin tedarikçi entegrasyonlarından daha iyi sonuç verdiğini fark ettikleri için kod inceleme süreçlerini daha akıcı hale getirmek için araçlar geliştirdi.
İncelemeden Doğrulamaya Geçiş
Kodu incelemek yerine, kodu doğrulamanın nasıl yapılacağını düşünmek başka bir yaklaşımdır. Söylemek kolay, uygulamak zor; teorik olarak, kapsamlı testler kodun beklendiği gibi çalıştığını doğrulamalıdır. Ancak "kapsamlı" ne demektir? Hangi tür testlerden bahsediyoruz? Entegrasyon testleri ve uçtan uca testler de dahil mi? Bulanık testler? Formel yöntemler? Yeni testlerin fonksiyonları beklendiği gibi kapsayıp kapsamadığını nasıl doğrularız? Bunların tümünü gözlenebilirlikle nasıl birleştiririz?
Aşırı denetim mühendisleri yoruyor
Aşırı detaylı kod incelemeleri mühendisleri yoruyor ve inceleme kalitesini düşürüyor. Diğerlerinin kodları dikkatle inceleyemeyeceğini görünce, AI kod incelemeleri gerçek bir yorum içermiyorsa doğrudan onayladıkları hakkında birçok söylenti duyuyorum. Aynı zamanda, kod incelemelerine önceki kadar aynı çabayı ve zamanı harcayan geliştiriciler, kendilerine gönderilen AI tarafından oluşturulan çöp PR'lerle kaplanmış hissediyorlar.
Sorun mevcut, çözüm hâlâ deneysel.
Sorun var, ancak çözüm更像是 bir deney gibi geliyor.