Aviator her satırı okumadan 4 kat daha fazla AI kodunu nasıl gözden geçiriyor

Aviator, kod incelemesini ham farkları okumaktan niyet, kabul kriterleri, değişmezler, kararlar ve somut kanıtları doğrulamaya çevirdikten sonra aynı dokuz mühendisin 4 kat daha fazla pull request birleştirdiğini söylüyor. Birleştirme için medyan süre 2,1 günden 3,4 saate düştü, geri almalar %40 azaldı ve her pull request için hâlâ bir insan onay veriyor.

Sorun: kod incelemesi AI ile ölçeklenmiyor

Ekibin kodu insan tarafından yazılan ve AI yardımı alan yapıdan AI tarafından üretilen ve insan tarafından desteklenen yapıya döndü. Haftalık birleştirilen pull request sayısı yaklaşık 100'den 400'ün üzerine çıktı ve medyan AI tarafından üretilen pull request 640 satıra, hata tespitinin düştüğü kabul edilen 400 satır sınırının üzerine ulaştı.

Hataları yakalamak zaten kod incelemesinin asıl amacı değildi. Bacchelli ve Bird'in 2013 tarihli Microsoft çalışmasında inceleme yorumlarının yalnızca %14'ü kusurlarla ilgiliydi. İnceleme, mühendislerin bilgi paylaşması ve sisteme dair zihinsel modellerini güncel tutması içindir ve korumaya değer olan kısım da budur. Ajanlar kodun çoğunu yazdığında bu kısım en çok risk altındadır. İncelemeyi tamamen bırakıp bırakmadıkları sorulduğunda ekip hayır diyor: farkı incelemeyi bıraktılar. Sonuçları şu: kararlar bir insana ihtiyaç duyar ve fark, bu kararların alınması için en kötü yerdir.

Ne değişti: satırları değil, niyeti doğrulamak

Kod incelemesi eskiden aynı anda birkaç iş yapıyordu: hataları yakalamak, ekip kurallarını uygulamak, tasarım kararlarını çözmek ve herkesin sistem anlayışını güncel tutmak. Ekip bu işleri ayırdı ve her birine daha iyi bir yer verdi.

Niyet ve kabul kriterleri, ajanla yapılan kodlama oturumundan yakalanır; önceden yazılmış bir şartname olarak değil. Bir mühendis ajanı her düzelttiğinde veya onun sorusunu her yanıtladığında bir kriter oluşur. Ekip eskiden oturum bittiğinde bunları attığını söylüyor. Niyet, değişikliğin neden yapıldığını yanıtlar; kabul kriterleri, nasıl davranması gerektiğini yanıtlar. Kriterleri olmayan niyet kontrol edilemez ve niyeti olmayan kriterler yargılanamaz.

Bu ikinci yarının tam olarak bir inceleyicinin farkı okurken hiçbir zaman kontrol etmeyeceği şeydir. Her kriter için tarayıcı gerekmez: bir API sözleşmesi kaydedilmiş bir istek ve yanıtla kanıtlanır, bir kod kuralı ise ast-grep eşleşmesiyle veya dosya ve satır alıntısıyla kanıtlanır. Tavsiye, soruyu çözen en ucuz kanıtı seçmektir. Yeşil bir CI kontrolü yalnızca düşündüğünüz testlerin geçtiğini söyler.

Kararlar üç yerden gelir: kodlama oturumu, ajanların argümanı ve başarısız doğrulama çalıştırmaları. Pull request, her birini, nereden geldiğini ve kimin çözdüğünü listeler. Başarısız webhook teslimatları için yeniden deneme ekleyen bir pull request'te beş karardan dördü çözülmüştü; ajanlar yeniden denenmiş teslimatların kopyalarını kaldırıp kaldırmamaları konusunda anlaşamadı, bu yüzden bir kişi bunu çözdü.

Mühendisler her satırı okumayı bırakır. Her satırı kontrol eden kuralların sahibi olurlar ve sistemi anlayışlarını niyet, kanıt ve kararları okuyarak korurlar.

Sonuçlar

İnceleme işi ortadan kalkmadı. Değişmezleri iyileştirmeye, kararları tartışmaya ve doğrulamayı geliştirmeye taşındı. Geçiş acı verebilir: birinci ay çift iş, ikinci ay değişmezler yeterince yetişir ve incelemeler küçülür, üçüncü ay insanlar kod yerine niyet ve kanıtı okur.

Kaynaklar: The New Stack