- Yapay zekanın yazdığı kodu yine yapay zekanın incelemesinin ne kadar makul olduğuna dair ilgi çekici bir soru
- Devin AI gibi botlar en fazla PR yazan taraflar haline geliyor ve incelemenin de yapay zeka tarafından yapıldığı örnekler artıyor
- LLM'lerin durumsuz (stateless) olduğu ve inceleme ile yazma sırasında iç yapının farklılaştığı için rollerin ayrılabileceği yönünde görüşler de var
- Yapay zekanın ürettiği kod, insanlardan farklı türde hatalar üretir ve yapay zeka bu hataları bulmada daha etkilidir
- Sonuç olarak yapay zeka incelemeleri, insan incelemelerine kıyasla gerçek hataları yakalamada daha avantajlıdır; ancak insanın mimari değerlendirmesi ve stil rehberleri hâlâ önemini korur
Yapay zeka kendi kodunu inceleyebilir mi?
- Çoğu şirket yazar ≠ inceleyen ilkesine bağlı kalıyor
- Ancak yapay zeka, LLM tabanlı olduğu için durumsuzdur ve her istekte yeniden karar verir
- Yani aynı motor kullanılsa bile yazma ve inceleme farklı “araçlar” olarak görülebilir
Scaffolding: yapay zeka incelemesinin yapısı
- İnceleme yapan yapay zeka şu tür belirli iş akışlarını yürütür:
- kod diff analizi
- hata tespiti
- yorum yazma ve önem derecesi belirleme
- kod tabanı dokümantasyonu ve ilişkili dosyalara başvurma
- Buna karşılık kod üreten yapay zeka tamamen farklı bir bağlamda çalıştığı için inceleme ile üretim işlevsel olarak farklıdır
İnsan da aslında “aynı motor”
- PR yazarı ile inceleyen farklı olsa da, ikisi de aynı insan zekâsından çıkar
- Aynı şirket içinde, benzer eğitim almış kişilerin benzer bilgi ve deneyimi paylaşması yaygındır
- Sonuçta hem yapay zeka hem insan “aynı motor, farklı durum” açısından birbirine benzer
Yapay zeka kodu daha hassas inceleme gerektirir
-
Yapay zeka kodunun kalitesi biraz daha düşüktür
- Yapay zeka hızlıdır ama prompt sınırları nedeniyle gereksinimler hatalı aktarılabilir
- İyi geliştiriciler bile yapay zeka kodunu kendi kodları kadar titizlikle incelemez
- Sonuç olarak genel kalite aşağı doğru eşitlenir ve orta seviyede toplanır
-
Yapay zeka hatalarını insanların bulması zordur
- Yapay zekanın ürettiği hatalar, insanların normalde yapmadığı türdendir
- Örnek: beklenmedik satır değişiklikleri, ince koşul ifadesi hataları vb.
- Greptile iç testlerine göre:
- AI (Sonnet), 209 “Hard” hatanın 32'sini buldu
- İnsan geliştiriciler ise ortalama yalnızca 5~7 tane buldu
Sonuç
- Yapay zekanın kendi kodunu incelemesi teknik olarak mümkün ve anlamlıdır
- Yapay zeka hata tespitinde insanlardan daha başarılıdır ve incelemede gerçekten faydalıdır
- Ancak insanın niyet yorumlama, tasarım değerlendirmesi ve kod stili yargısı hâlâ önemlidir
- Yazar ≠ inceleyen şeklindeki geleneksel ölçütün yapay zeka için yeniden yorumlanması gerekir
3 yorum
LLM modellerini değiştirerek inceleme yapmak nasıl olur diye düşünüyorum. Örneğin A modeliyle yazılan kodu B, C, D modelleriyle incelemek gibi
Ah, bizim şirkette bunu böyle yapıyoruz: Cursor (Claude) ile yazılan kodu PR olarak açınca ChatGPT ile inceletiyoruz. Sonra da “hadi, artık birbirinizle kapışın” diyoruz. Özellikle o4-mini’den itibaren insanların bayağı etkilendiğini gördük. İsterseniz Cursor içinde modeli değiştirip aynı şekilde doğrudan da deneyebilirsiniz.
Hacker News görüşleri
Şu noktayı vurgulamak istiyorum: mühendisler, yapay zekanın ürettiği kodu kendi yazdıkları kod kadar dikkatle incelemiyor. Bunun nedeni, LLM'in kod üretme hızının yazma hızından çok daha yüksek olması. Bu yüzden kodu kendin yazdığında doğal olarak gözden geçiriyorsun, ama yapay zeka ürettiğinde bu süreç atlanıyor. İlginç olan şu ki, ortalama bir mühendis için yapay zeka kod kalitesini hatta artırabiliyor. Yapay zeka ne kadar çok kullanılırsa, iyi mühendislerle kötü mühendisler giderek daha benzer seviyede kod üretmeye başlayacak. Kod inceleme, tasarım ve yazımın her aşamasında düşünme biçiminin farklı olması her zaman ilginçtir
İnsanların etkileşim biçimleri farklı olduğu için herkesin kendine daha uygun bir yöntemi var. Benim için kod yazmaktan çok kod incelemek daha kolay. Doğrudan yazarken kod tabanının dışında pek çok bağlamı da düşünmek gerekiyor; inceleme yaparken ise bu bağlamı yalnızca kod tabanına odaklayabildiğim için örüntü eşleştirmeyi daha hızlı yapabiliyorum. Ne yazık ki LLM'lerin seviyesi junior mühendis düzeyinde olduğu için PR incelemesine daha fazla emek ve enerji gidiyor
İyi bir mühendis her zaman iyi bir kod yazarı olmak zorunda değildir
Kod incelemesi ve kod yazımı için yapay zekada farklı botlar ve prompt'lar kullanırsan çok daha fazla hata yakalayabilirsin. Aynı araçla birkaç kez yinelemek bile yeni sorunlar bulabiliyor. Ne insanlar ne de yapay zeka tek seferde kusursuz kod üretemiyor. Yapay zeka araçları giderek gelişip kendi kodunu test eden ve ön incelemeden geçiren aşamaya geldi, ama ister insan ister yapay zeka olsun, PR kodunu her iki tarafın da incelemesinin asla zararı olmayacağına inanıyorum. Bizzat yaptığım Kamara adlı araçla bile kendi yazdığı kodda sorunlar bulduğu çok oldu. greptile örneğinde olduğu gibi, kod konumu tamamen yanlış öneriler verme sorunu da vardı ama giderek kontrol altına alınıyor. Hâlâ %100 kusursuz bir araç yok ve yapay zekanın her şeyi takeover etmesine kadar biraz daha zaman gerektiğini düşünüyorum
OpenHands'i (eski adıyla OpenDevin) başlattığımızda, yapay zekanın oluşturduğu PR'ler yapay zeka hesap adıyla açılıyordu. Bu iki ciddi soruna yol açtı: 1) yapay zekayı çağıran kişi kod incelemesi olmadan doğrudan merge edebiliyor, böylece incelenmemiş kod production'a çıkabiliyordu, 2) PR'nin net bir sorumlusu olmadığı için merge edilmese de sorun çıksa da kimin hesap vereceği belirsiz kalıyordu. Bu yüzden stratejiyi değiştirip tüm PR'lerin sahibi bir insan olacak şekilde düzenledik ve yalnızca commit'ler yapay zeka adıyla kalsın dedik. PR'nin kendisi tamamen insan sorumluluğunda
LLM'lerin bug bulmada iyi olduğuna dair kısım ilginçti. Yüksek gerçek hata tespit oranına ulaşmak için ne kadar false positive oluştuğunu merak ediyorum. Benim deneyimimde LLM'ler ortada bug yokken bile "var" diyebiliyor
Buna gerçekten katılıyorum. ChatGPT'ye bir şey sorduğumda önerisini beğenmezsem "o kısımdan çok emin değilim" dediğim anda cevabını değiştiriyor. Aslında ilk cevabı doğru da olabilir, ama kullanıcı emin görünmezse kolayca sarsılıyor. Bu yüzden aracı düzgün biçimde doğrulamak pek kolay değil
Bu örnekte her dosyada yalnızca tek bir bug vardı ve bottan tam olarak bir tane bulması istenmişti. Hepsi false positive örnekleriydi; hiçbir sorun olmayan yerde bug uyduruyordu
Piyasadaki çeşitli yapay zeka kod inceleme araçları arasındaki fark tam da signal/noise oranının nasıl ayarlandığında yatıyor. Bazı araçlar çok daha isabetli ve daha az false positive üretiyor
Bir programcı olarak en önemli sorumluluk, güvendiğin ve düzgün çalışan kod üretmektir. LLM kullanmış olmanın kendisi önemli değil. Asıl önemli olan, PR açtığında "bu değişikliğin sorunu çözdüğüne inanıyorum ve itibarımı bunun üzerine koyabilirim" diyebilme tutumudur. Bu nedenle ister insan ister yapay zeka olsun, PR'lerde her zaman ikinci bir göz gerekir
Bence kilit nokta itibar. Bu yalnızca kodlama için değil, doğal dilde yazılar için de geçerli. Bundan sonra çağ, yazarın değil yayımlayanın, yani yayımlayıcının içerikten sorumlu olduğu bir çağ olacak. İster %5 chatbot katkısı olsun ister %95, bir sorun çıkarsa suçlanması gereken o yazıyı yayımlayan benim. "Bunu chatbot yaptı" bahanesi işlemez
Burada sadece Devin gibi tamamen otomatik çalışan bir mühendisten söz ediliyordu; sıradan bir mühendisten biraz farklı bir durum
Bugünlerde birçok mühendis, yapay zekanın ürettiği kaba saba kodu sorumsuzca ortaya atıp diğer ekip arkadaşlarının sorunları yakalamasını bekliyor. Eskiden kod üretiminin kendisi zor olduğu için bu daha az görülüyordu
Güvenilir kod üretmenin senin sorumluluğun olduğu fikrine yürekten katılıyorum. Ama yapay zekadan önce de iyi kod her zaman korunmuyordu. Kodlamayı bir araç ya da para kazanma yöntemi olarak görmeye başladık. Oysa başlangıçta işin içinde "sorun çözmenin ve dünyayı değiştirmenin keyfi" vardı. Şimdi ise odak "hızlı para kazanmak ya da hendekler kazmak" oldu. Önemli olan kodun güzel olup olmaması değil, sorunu zarif biçimde çözüp çözmediği. Yapay zeka yüzünden bu kültür daha da kötüleşebilir, ama sonuçta her şey onu nasıl kullandığına bağlı
Bir şeyi merak ediyorum. Eğer bir PR tüm sorunları çözüyor ama içinde sadece ufak bir bug varsa, bunun zaman kaybı sayılacağı bir örnek verebilir misin?
Kod incelemesi, mühendisliğin en yavaş aşaması. Ben de yapay zeka olmadan kodu hızlı yazabiliyorum ama kod incelemesi hızlanmıyor. Bu yüzden ekip arkadaşlarımın zamanını korumak için inceleme öncesinde yapay zekaya ön inceleme yaptırıyor, bug'ları önceden yakalayıp production'a çıkış süresini günlerce kısaltıyorum. Yapay zeka hem bariz bug'ları hem de gizli hataları yakalıyor; hatta gerçekten derin bug'ları da bulduğu oldu.
gitCLI vexclipgibi araçlarla diff'i kopyalayıpo3gibi mantık modellerine yapıştırarak inceleme aldığım bir iş akışı kullanıyorumYapay zekanın avantajlarından biri, insandan çok daha hızlı biçimde çok sayıda unit test yazabilmesi. Ayrıca bulduğu sorunları kendi başına düzeltebiliyor. İdeal iş akışı sadece kod incelemesi değil; yapay zekanın testleri de otomatik çalıştırması ve her şeyin belirli bir spec'i karşılayıp karşılamadığını doğrulaması olurdu. Çok fazla test daha sonra refactor etmeyi zorlaştırabilir (örneğin implementation details'a bağımlı testler) ve canın istemediğinde yapay zekanın yazdığı testleri ayrıca çöpe de atabilirsin
Gerektikçe unit testleri yeniden üretebilmek bana çok iyi geliyor. İnceleme gönderirken diff'in boyutundan büyük tatmin duyuyorum ve sıkıcı test yazma süresinden tasarruf edip daha çok iş yapabiliyorum
Bugün bile programlamada can sıkıcı işler kaldı, ama idealde yapay zeka bu verimsizlikleri azaltmalı ve insanların yaratıcı alanlara odaklanmasını sağlamalı. Ne var ki pratikte yapay zeka giderek daha yüksek seviyeli yaratıcı işlere de göz dikiyor
Aslında yapay zeka olmasa da property-based testing framework'leri kullanarak çok sayıda girdiyle otomatik test üretmek mümkün
Kod incelemesinde bir kuralım var: sonradan bakımını bizzat üstlenebileceğime güvenmiyorsam onaylamam. Eğer LLM'i hem kod yazımında hem incelemede kullanıyorsan, aynı sorumluluk ilkesini araçlara da uyguladığın söylenebilir. Ama dürüst olmak gerekirse böyle bir durumda uzun süre kalabileceğimden emin değilim
Tek bir LLM ile gereksinimlerden Gherkin script'leri üretip, başka bir LLM ile bu script'lerden kod oluşturup, sonra da sonucu Cucumber ile doğrulayan bir pipeline deneyen oldu mu merak ediyorum. Her hâlükârda hem Gherkin script'lerinin hem kodun gözden geçirilmesi gerekecek, ama bu yöntemle üretilemeyecek kod türlerinin neler olduğunu öğrenmek isterim. Yapay zekayı tek bir geliştirici gibi görüyorum; insan geliştiricilerde olduğu gibi onun da belirgin biçimde zayıf olduğu alanlar mutlaka vardır
Sonuçta PR'yi açan yazar, kendi kodunun etkisi ve sonuçları konusunda sorumluluk taşımalı. Yapay zeka ile kod yazmanın yaygınlaşması ve junior mühendis sayısının artmasıyla bu sorumluluk daha da önemli hale geldi. Yapay zekanın incelemenin ilk geçişini yapması mantıklı, ama insan inceleyicinin de dışarıdan bir bakışla kod tabanını daha iyi anlaması ve daha yüksek seviyeli sorunları yakalaması gerekiyor. Sonuç olarak ideal yapı, ilk incelemeyi yapay zekanın yapması, ardından başka bir mühendisin bağlam ve iş birliği açısından kodu incelemesi ve nihayetinde tüm sonuçların sorumluluğunu yazarın üstlenmesi şeklinde olmalı