Yapay Zekâ Üretimi Yamaları İncelemek: Bir Şey Main'e Girmeden Önceki Kontrol Listem

Yapay zekâ üretimi yamalar, gerçekten güvenli olmadan önce çoğu zaman bitmiş görünecek kadar iyidir. İşte bu yüzden ilk taslağı bir ajan ürettiğinde inceleme sürecim daha gevşek değil, daha katı olur. Modelin bariz sözdizimi hatası yapmasını yakalamaya çalışmıyorum. Daha pahalı sorunları yakalamaya çalışıyorum: belirsiz kapsam, kazara oluşan yan etkiler ve gerçekten anlaşılmadan yerelde geçen değişiklikler.

İlk Soru: Görev Yeterince Küçük müydü?

İlk kontrol ettiğim şey kod değil. Görevin boyutu. Yama aynı anda çok fazla konuya dokunuyorsa, inceleme kalitesinin düşeceğini zaten bilirim. Büyük ajan yamaları, birden fazla kararı tek bir diff içinde sıkıştırdıkları için yanlış bir hız hissi yaratır.

Kapsam çok genişse, stil hakkında yorum yapmadan önce işi bölerim. Daha küçük bir yamayı test etmek daha kolaydır, üzerine düşünmek daha kolaydır ve daha sonra ince bir şey bozulursa geri almak çok daha kolaydır.

Küçük Bir Diff'e Güvenmek Daha Kolaydır

Hata bir sepette miktar (quantity) hatasıysa, şöyle bir değişikliği incelemeyi tercih ederim:

diff
- const total = items.reduce((sum, item) => sum + item.price, 0)
+ const total = items.reduce((sum, item) => sum + item.price * item.quantity, 0)

Bu tür bir yama üzerine düşünmek kolaydır. Bir inceleyici hemen doğru soruları sorabilir: miktarlar her zaman mevcut mu, testler sıfır değerlerini kapsıyor mu ve aynı mantık başka bir yerde tekrarlanıyor mu?

Diff'i Yalnızca Doğruluk İçin Değil, Niyet İçin Okuyun

Bir insan inceleyici, her düzenlemenin neden var olduğunu yeniden kurmak zorundadır. Değişen her bloğun açık bir nedene bağlanmasını isterim. Bir satırın neden taşındığını, bir yardımcının neden eklendiğini ya da bir bağımlılığın neden değiştiğini açıklayamıyorsam, yama hazır değildir.

Yapay zekânın kendini ele verdiği yer burasıdır. Zararsız görünen ama soruna ilgisiz temizlik düzenlemeleri eklemeye eğilimlidir. Bu düzenlemeler değer katmadan yüzey alanını artırır; bu yüzden onları acımasızca budarım.

Doğrulamanın Gerçek Olduğunu Teyit Edin

Kodun, görevin gerektirdiği biçimde çalıştırıldığına dair kanıt ararım. Değişiklik render mantığındaysa, başarılı bir build yeterli değildir. Değişiklik veri tutarlılığını etkiliyorsa, bir ekran görüntüsü yeterli değildir. Doğrulama yöntemi riske uymak zorundadır.

Kullanıcıya yönelik bir iş akışına dokunan bir yamayı onaylamadan önce genellikle çalıştırdığım komutlar şunlar:

bash
git diff --stat
git diff -- app/cart
pnpm test cart-summary -- --runInBand
pnpm lint app/cart

Kuralım basit: değişiklik ne kadar kullanıcıya yönelikse, kanıtın o kadar somut olması gerekir. Bu testler, günlükler, ekran görüntüleri ya da adım adım yeniden üretme notları anlamına gelebilir. Önemli olan, inceleyicinin davranışın gerçekten değişip değişmediğini tahmin etmek zorunda kalmamasıdır.

Kalıp Uyumsuzluğuna Dikkat Edin

En yaygın başarısızlık biçimlerinden biri, modelin deponun artık kullanmadığı makul görünen bir kalıbı izlemesidir. Eski bir hook kalıbı, kullanımdan kaldırılmış bir yardımcı ya da doğru görünen ama mevcut konvansiyonlarla çakışan bir stil getirebilir. Yalnızca değişen satırları yalıtık biçimde incelerseniz, bu tür bir uyumsuzluğu gözden kaçırmak kolaydır.

Yamayı, ekibin yakın zamanda yazdığı yakındaki kodla karşılaştırırım. Yeni kod, kod tabanının farklı bir neslinden geliyormuş gibi hissettiriyorsa, yavaşlayıp çok daha dikkatli incelerim.

Geri Almayı Kolaylaştırın

Güçlü yapay zekâ destekli değişiklikler bile kolayca geri alınabilir olmalıdır. Sorumlulukları ayrı tutan ve refactor'ları davranış değişiklikleriyle bir araya getirmekten kaçınan yamaları tercih ederim. Bir yamayı geri sarmak zorsa, genellikle çok fazla iş yapıyor demektir.

Geri alma kötümser bir zihniyet değildir. Bir kalite sinyalidir. Temiz geri alınabilirlik genellikle değişikliğin iyi kapsamlandığı ve iyi anlaşıldığı anlamına gelir.

Gerçekten Kullandığım Kontrol Listesi

Bir şey main'e ulaşmadan önce beş şeyi kontrol ederim: yama sıkıca kapsamlandırılmış, her düzenlemenin açık bir nedeni var, doğrulama riske uyuyor, depo kalıplarına saygı gösteriliyor ve geri alma basit olur. Bunlardan herhangi biri zayıfsa, yamanın hâlâ üzerinde çalışılması gerekir.

İncelerken bunu çoğu zaman kompakt bir kontrol listesine indiriyorum:

md
[ ] Only the necessary files changed
[ ] Every edit maps to the bug or requirement
[ ] Verification matches the user-facing risk
[ ] Current repository patterns are preserved
[ ] Rollback is straightforward

Yapay zekâ, uygulamayı hızlandırabildiği için kullanışlıdır. Mühendislik muhakemesinin yerine geçmek için kullanışlı değildir. En çok yararlananlar, inceleme için daha düşük değil, daha yüksek bir çıta koyan ekiplerdir.