Yapay zekâ ile üretilen kodu merge etmeden önce incelemek için pratik bir kontrol listesi

Bir asistanın yazdığı kod genellikle derlenir, kolay okunur ve aşağı yukarı istediğiniz şeyi yapar. Onu kolayca onaylayıp geçmenizin nedeni de tam olarak budur. Hatalar nadiren sözdizimi hatasıdır. Bunlar modelin sessizce verdiği kararlardır: var olduğunu varsaydığı bir bağımlılık, yanlış yere koyduğu bir yetki kontrolü, görmezden gelmeye karar verdiği bir hata.

Bu, yapay zekâ destekli değişiklikleri incelerken kullandığımız kontrol listesi. Konu kodun zarif olup olmadığı değil. Konu, olaya dönüşen bir avuç sorun.

Yapay zekâ kodu neden farklı bir inceleme ister

Bir meslektaşınız kod yazdığında, değinmediği kısımlara genellikle güvenebilirsiniz. Kod tabanını biliyordu, değişikliği yerelde test etti ve yarım kalan bir şey olsaydı söylerdi. Bir model ise siz vermedikçe bu bağlamın hiçbirine sahip değildir ve boşlukları bir soruyla değil, akla yatkın bir şeyle doldurma eğilimindedir. Bu yüzden inceleme “bu iyi yazılmış mı” sorusundan “neyi varsaydı” sorusuna kayar.

1. Bağımlılıklar

Değişikliğin eklediği her paketi kontrol edin. Registry’de var mı? Resmî dokümantasyonun önerdiği paket mi, yoksa kulağa benzer gelen başka bir paket mi? Geçen hafta mı yayımlanmış? Modeller bazen paket adları uydurur ve bu adların bir kısmı saldırganlar tarafından kaydedilir. Slopsquatting rehberimiz bir paketi bir dakikada nasıl kontrol edeceğinizi anlatıyor.

Sürümlere de bakın. Hiç yayımlanmamış bir sürüme sabitlenmiş bir bağımlılık bir sonraki temiz kurulumu bozar; sürümü sabitlenmemiş bir bağımlılık ise incelediğiniz kodun çalışan kod olmadığı anlamına gelir.

2. Gizli bilgiler ve public değişkenler

Test dosyaları ve örnekler dahil, diff içinde anahtarları, token’ları ve parolaları arayın. Ardından VITE_, NEXT_PUBLIC_ ya da EXPO_PUBLIC_ gibi public önekli ortam değişkenlerine bakın. Bu önekleri taşıyan her şey build sırasında tarayıcı paketine kopyalanır. Bir asistan, bir özelliği tarayıcıda çalıştırmak için bir gizli bilginin adını bu öneklerden birine çevirebilir. Bu rehber aynı hatanın LLM API anahtarı versiyonunu adım adım anlatıyor.

3. Erişimin kontrol edildiği yer

Mevcut kullanıcının bu işlemi yapıp yapamayacağına karar veren satırı bulun. Bu satır bir React bileşenindeyse, bir route guard’daysa ya da gizlenmiş bir butondaysa, bu bir güvenlik önlemi değil, bir kullanıcı deneyimi özelliğidir. Herkes API’nizi doğrudan çağırabilir. Kontrol sunucuda, her istek için ve erişilen kaynağa göre yapılmalıdır: yalnızca “bu kullanıcı oturum açmış mı” değil, “bu fatura bu kullanıcıya mı ait”.

Hiç auth middleware’i olmayan yeni API route’larına ve veritabanının tarayıcıdan erişilebilir olduğu Supabase ya da Firebase gibi backend’lere dikkat edin. Bu tür backend’lerde koruma veritabanının kendi kurallarıdır. Row level security olmayan bir Supabase tablosu, herkese açık anon anahtarınıza sahip olan herkese açıktır.

4. Güvenilmeyen girdi

Kullanıcı girdisini girdiği yerden kullanıldığı yere kadar takip edin. String birleştirerek oluşturulan SQL, istek alanlarından derlenen shell komutları, query parametrelerinden gelen dosya yolları, kullanıcı içeriğinden render edilen HTML ve bir kullanıcı adına çekilen URL’ler; klasik injection, path traversal, XSS ve SSRF kalıplarıdır. Asistanlar bunları hâlâ üretiyor, çoğunlukla da çevredeki kod zaten benzer bir şey yapıyorsa.

// Looks harmless, is an injectiondb.query(`SELECT * FROM users WHERE email = '${req.query.email}'`); // Parameterizeddb.query('SELECT * FROM users WHERE email = $1', [req.query.email]);

5. Yarım kalmış kod

Uzun üretimler bazen yarıda kesilir. Değişiklikte yer tutucuları arayın: TODO, “sonra implement edilecek”, “kodun geri kalanı burada”, sabit kodlanmış örnek veri döndüren fonksiyonlar, sahte kimlik bilgileri ve utils copy.ts gibi adlara sahip dosyalar. Toptan bastırmalara da bakın: // @ts-ignore, dosyanın başındaki eslint-disable ya da tip denetleyicisini susturmak için kullanılan any. Bunlar çoğu zaman modelin çözemediği sorunun ta kendisini gizler.

6. Hata yönetimi

Hatayı loglayıp devam eden ya da her şeyi yakalayıp boş bir sonuç döndüren bir catch bloğu, gürültülü bir hatayı sessiz bir veri kaybına dönüştürür. Bu çağrı başarısız olduğunda ne olması gerektiğini ve kodun bunu yapıp yapmadığını sorgulayın. Sınırsız yeniden denemelerden ve başarılı yanıtlara dönüştürülen hatalardan şüphelenin.

7. Testler

Üretilmiş testleri satır satır okumaya değer. Sık görülen sorunlar: hiçbir şey doğrulamayan testler, test ettikleri fonksiyonun kendisini mock’layan testler, yalnızca bir fonksiyonun çağrıldığını kontrol eden assertion’lar ve unutulmuş .only ya da .skip. Geçen bir test paketi, başarısız olabildiğini bilene kadar bir kanıt değildir. Kodu bir kez bilerek bozun ve bir testin bunu fark edip etmediğine bakın.

8. Zaman aşımları ve bloklayan çağrılar

Zaman aşımı olmayan dışa giden HTTP çağrıları, yavaş bir bağımlılığı bekleyen bir production olayıdır. Python’un requests kütüphanesi ve Go’nun http.DefaultClient’ı dahil, popüler istemcilerin çoğu varsayılan olarak süresiz bekler. Node.js’te bir request handler içindeki senkron dosya işlemleri ya da parola hash’leme, o süreçteki diğer tüm istekleri bloklar. Bunlar yerel testlerde nadiren ortaya çıkar; çünkü dizüstünüz ve bağımlılıklarınız hızlıdır ve boştadır.

9. Veri erişimi

Döngü içindeki sorgulara (N+1 sorunu), sayfalama olmadan tüm satırları döndüren liste endpoint’lerine ve paylaşılmak yerine her istekte yeniden oluşturulan veritabanı istemcilerine bakın. Migration’ları da dikkatle kontrol edin: uygulama açılışında çalışan bir şema senkronizasyonu ya da bir tabloyu drop edip yeniden oluşturan bir migration, bir sonraki deploy’da production verisini silebilir.

10. LLM özellikleri

Değişiklik bir model çağırıyorsa, modelin çıktısını güvenilmeyen girdi olarak ele alın. Bu çıktı asla çalıştırılmamalı, SQL’e eklenmemeli ya da ham HTML olarak render edilmemelidir. API anahtarının sunucuda kaldığını, modeli çağıran route’un oturum açmış bir kullanıcı gerektirdiğini ve bir rate limit’i olduğunu, çıktı uzunluğunun da sınırlandığını kontrol edin. Bir ajanın araçları varsa, bu araçların neler yapabildiğini ve belgelerden ya da web sayfalarından gelen metnin onları yönlendirip yönlendiremeyeceğini kontrol edin.

Bunu rutin hâline getirin

Pull request başına on kontrol, elle yapılacak iş için çok fazla; bir kontrol listesinin amacı da hafızanıza güvenmeyi bırakmanızdır. Bu maddelerin çoğu en azından kısmen otomatikleştirilebilir. Bu da dikkatinizi araçların kötü olduğu konulara, örneğin değişikliğin ürünün gerçekten ihtiyaç duyduğu şeyi yapıp yapmadığına ayırmanızı sağlar.

vetkit bu kontrolleri paketler hâlinde gruplar: güvenlik (gizli bilgiler, açığı olan bağımlılıklar, kod güvenlik açıkları, altyapı yapılandırması), kod kalitesi, sürdürülebilirlik, yapay zekâ kodu riskleri (uydurulan paketler, yarım kalmış kod, uygulama platformu tuzakları, LLM ve ajan güvenliği) ve production’a hazırlık (zaman aşımları, bloklayan çağrılar, veritabanı kullanımı, operasyonel temeller). Kodunuzu kurmadan, build etmeden ya da çalıştırmadan okur ve bulduklarını dosya, satır ve önerilen bir düzeltmeyle raporlar. Her statik analiz gibi bazı şeyleri kaçırabilir ve yanılabilir; bu yüzden incelemenin yerini almaz, ona destek olur.