Bir geliştirici sabah bir özelliği AI asistanına tarif ediyor, öğleden önce 900 satırlık bir pull request hazır oluyor. Testler geçiyor, kod düzgün görünüyor. Sıra incelemeye geldiğinde ekipte bu 900 satırı okuyup "evet,…
Bir geliştirici sabah bir özelliği AI asistanına tarif ediyor, öğleden önce 900 satırlık bir pull request hazır oluyor. Testler geçiyor, kod düzgün görünüyor. Sıra incelemeye geldiğinde ekipte bu 900 satırı okuyup "evet, doğru" diyebilecek biri var mı?
Kodu üretmek artık dakikalar sürüyor ama okumak eskisi kadar zaman alıyor, bu yüzden işin yavaşladığı yer inceleme oluyor. Pull request'i AI araçları da inceleyebilir ama merge onayını kodu anlayan bir insanın vermesi gerekiyor. Bunu yapılabilir kılan da pull request'leri küçük tutmak ve testleri işin tanımına göre yazmak.
AI asistanının yazdığı kod çoğu zaman derlenir, okunaklıdır ve ilk bakışta doğru görünür. Hatalı kodla doğru kod arasındaki fark ise yüzeyde görünmüyor. Asistan isteği yanlış anladığında bile tutarlı ve özenli görünen bir kod yazabiliyor.
Google'ın DORA ekibinin 2024 raporunda bununla ilgili bir sonuç var. Rapora göre AI kullanımındaki %25'lik artış dokümantasyon kalitesinde %7,5, kod kalitesinde %3,4 ve kod inceleme hızında %3,1'lik artışla ilişkili. Aynı veride AI kullanımı arttıkça teslim hızında tahmini %1,5, teslim kararlılığında (delivery stability) tahmini %7,2 düşüş görülüyor. Rapor bu sonucu, küçük değişiklik boyutu ve sağlam test mekanizmaları gibi temel pratiklere uyulmadıkça süreci hızlandırmanın teslimatı kendiliğinden iyileştirmediği şeklinde yorumluyor.
Aynı raporda katılımcıların %39'u AI ile üretilen koda çok az güvendiğini ya da hiç güvenmediğini söylüyor. Ekipler bu koda zaten temkinli bakıyor; bu temkini herkesin aynı şekilde uyguladığı bir inceleme düzenine çevirmek gerekiyor.
Kod üretmek hızlı olduğu için tek bir pull request'e çok şey sığdırmak kolaylaşıyor. Bir özelliğin tamamı, yanında birkaç refactor ve "fırsat bulmuşken" düzeltilen başka yerler aynı değişikliğe giriyor. Böyle bir pull request'i incelemek ya saatler alıyor ya da göz gezdirip onaylamakla bitiyor.
Google'ın mühendislik pratikleri dokümanı doğru boyutu tek bir işi yapan, kendi içinde tamamlanmış değişiklik olarak tarif ediyor. Dokümana göre 100 satır çoğu zaman makul, 1000 satır çoğu zaman fazla; son karar yine inceleyen kişinin. Değişikliğin kaç dosyaya yayıldığı da boyutu etkiliyor: tek dosyada 200 satır kabul edilebilirken aynı değişiklik 50 dosyaya dağılmışsa genelde fazla sayılıyor. Doküman küçük değişikliklerin daha hızlı ve daha dikkatli incelendiğini, hata getirme ihtimalinin daha düşük olduğunu ve gerektiğinde daha kolay geri alındığını yazıyor. İnceleyen kişinin bir değişikliği yalnızca çok büyük olduğu için reddedebileceğini de ekliyor.
Ekipte bunun karşılığı, asistandan özelliğin tamamını bir seferde istemek yerine işi parçalara bölmek: önce veri modeli, sonra servis katmanı, sonra arayüz. Refactor ile davranış değişikliği ayrı pull request'lerde durursa inceleyen kişi neyin neden değiştiğini takip edebiliyor. Açıklamayı değişikliği yapan kişi yazmalı; asistanın özetini kullanacaksa önce kendisi okuyup düzeltmeli. Lock dosyası ya da migration çıktısı gibi otomatik üretilen dosyalar da açıklamada ayrıca belirtilirse inceleyen kişi dikkatini nereye vereceğini biliyor.
Google'ın dokümanı küçük bir değişikliğin ilgili test kodunu da içermesi gerektiğini söylüyor. AI asistanı test yazmayı da hızlandırıyor ama bunun bir tuzağı var.
Kodu ve testi aynı araç aynı istekle yazdığında ikisi de aynı varsayıma dayanabiliyor. Asistan isteği yanlış anladıysa kodu o yanlış anlayışla yazıyor, testi de o davranışı doğrulayacak şekilde kuruyor. Testler geçiyor ama kod istenen işi yapmıyor, çünkü geçen test yalnızca kodun kendi içinde tutarlı olduğunu söylüyor.
Bu riski azaltmak için:
Girinti, isimlendirme ve yazım biçimi genelde sorun çıkarmıyor; bunları linter ve formatter zaten yakalıyor. İnsanın asıl bakması gereken yerler başka.
İlki niyet: kod, issue'da ya da iş kaydında tarif edilen problemi çözüyor mu? Asistan isteğin bir kısmını atlamış ya da kendi yorumuyla genişletmiş olabilir ve bunu ancak işi bilen biri fark eder.
İkincisi hata durumları. Kod beklenen akışta sorunsuz çalışırken ağ hatası, zaman aşımı, eksik alan ya da aynı isteğin iki kez gelmesi gibi durumlarda bozulabilir. Hataların sessizce yutulup yutulmadığına ve logların bir sorunu çözerken işe yarayıp yaramayacağına da bakmak gerekiyor.
Üçüncüsü güvenlik: kullanıcıdan gelen veri doğrulanıyor mu, veritabanı sorguları parametreli mi, yetki kontrolü doğru katmanda mı, koda bir anahtar ya da şifre yazılmış mı. Kod düzgün göründü diye bu kontrolleri atlamak olmaz.
En kolay gözden kaçan konulardan biri bağımlılıklar. Asistan, gerçekte var olmayan bir paketi import edebiliyor. USENIX Security 2025'te yayımlanan bir çalışmada araştırmacılar 16 farklı modelle Python ve JavaScript'te 576.000 kod örneği üretti. Ticari modellerde önerilen paketlerin ortalama en az %5,2'si, açık kaynak modellerde %21,7'si gerçekte olmayan paketlerdi. Toplamda 205.474 farklı uydurma paket adı tespit edildi.
Biri bu uydurma isimlerden birini paket deposuna kaydedip içine zararlı kod koyarsa, kontrol etmeden kuran ekip o paketi projesine almış olur. Bu yüzden pull request'te yeni bir bağımlılık görüldüğünde paketin gerçekten var olup olmadığına, kimin yayımladığına, bakımının sürüp sürmediğine ve projeye gerekip gerekmediğine bakılmalı.
AI yalnızca kod yazmıyor, kod da inceliyor. GitHub Copilot gibi araçlar pull request'e otomatik inceleme yorumu bırakabiliyor ve bu yorumlar inceleyen kişiye bakması gereken yerleri gösterebilir.
GitHub'ın kendi dokümanı Copilot'un her sorunu yakalamasının garanti olmadığını, zaman zaman hata yapabileceğini ve geri bildirimlerinin yanında bir insanın da kodu incelemesi gerektiğini yazıyor. Varsayılan ayarda Copilot'un incelemeleri, merge için zorunlu tutulan onay sayısına dahil edilmiyor. Bu ancak Copilot onayları depo, organizasyon ve enterprise ayarlarında etkinleştirildiğinde değişiyor.
Onayın kimden geleceği ayar düzeyinde de belirlenebilir. GitHub'da korumalı branch'ler için merge öncesinde istenen sayıda onay şartı konabiliyor. CODEOWNERS dosyasıyla da kodun bölümleri için sorumlu kişi ya da ekip tanımlanabiliyor ve o bölüme dokunan pull request'lerde onların onayı zorunlu tutulabiliyor. Ödeme, yetkilendirme ya da veri silme gibi hassas kod yollarında bu kural, branch koruması açıkken AI'ın yazdığı bir değişikliğin kod sahibinin onayı olmadan ana branch'e girmesini engelliyor.
Kurallar yazılı olursa herkes aynı şeylere bakar. Pull request şablonuna şöyle bir liste eklenebilir:
Son madde belki en önemlisi. Kodu kendisi yazmamış olsa da sahibi pull request'i açan kişi; inceleyen bir şey sorduğunda "asistan böyle yazdı" demek cevap sayılmaz. Kodu kim yazarsa yazsın, ana branch'e girmeden önce onu anlayan biri onaylamalı.