Kod incelemesini iyi yapanlar, AI ajanlarını da iyi kullanabilir

 (seangoedecke.com)
15 puan yazan GN⁺ 2025-09-23 | 1 yorum | WhatsApp'ta paylaş
  • AI ajanlarını kullanmada ustalaşmak için kod inceleme becerisi önemlidir
  • Büyük dil modelleri kod üretmede başarılı olsa da derinlemesine muhakeme konusunda yetersiz kaldıkları için sık sık yanlış yöne gidip zaman harcarlar
  • Yalnızca ayrıntılı sözdizimine takılan aşırı titiz incelemeler ya da eleştirel olmayan onay damgası incelemeleri, AI kullanımına yardımcı olmaz
  • İyi bir kod incelemesi, yapısal bakış açısını da içerir; daha iyi bir yöntem olup olmadığını sorgular ve karmaşık tasarımlardan kaçınmayı sağlar
  • Sonuçta AI ile kodlama, "Centaur satrancı" gibi insan muhakemesi ile makine üretkenliğini birleştiren bir modeldir; kod inceleme yeteneği de doğrudan AI’dan yararlanma becerisine dönüşür

AI ajanları ile kod incelemesi arasındaki ilişki

  • AI ajanlarını doğru kullanmak, aslında kod inceleme sürecinin kendisidir
  • Kod incelemesini iyi yapan kişiler, Claude Code, Codex ve Copilot gibi AI kod araçlarını da etkili biçimde kullanır

Kod inceleme becerisi neden önemli?

  • Büyük dil modelleri büyük miktarda kod üretmede yeteneklidir, ancak deneyimli bir yazılım mühendisinin muhakeme gücünden hâlâ yoksundur
  • Bu nedenle denetimsiz bırakıldıklarında, gereksiz ya da kötü tasarımlara büyük kaynaklar harcama eğilimindedirler

AI ajanlarının sınırları ve tasarım hataları

  • Örnek olarak VicFlora Offline projesi geliştirilirken Codex, frontend kodunu tersine mühendislikle çözmeye çok fazla çaba harcadı
    • Oysa gerçekte daha basit bir veri erişim yaklaşımı vardı
    • AI ajanları kullanılırken yaklaşık saatte bir kez şüpheli bir iş yaptıkları görülebiliyor
    • Böyle bir sorun fark edildiğinde yönü doğrudan değiştirmek, birkaç saatlik işi tasarruf etmeyi sağlayabiliyor
  • Başka bir uygulama geliştirme deneyiminde AI, basit bir paralel işleme görevi için bile gereğinden fazla arka plan altyapısı kurulmasını önerdi
    • Oysa bunu yalnızca frontend tarafında non-blocking şekilde işlemek yeterliydi; buna rağmen karmaşık bir mimari getirmeye çalıştı
    • Sadelik korunmak isteniyorsa AI’ı sürekli kontrol altında tutmak önemlidir
  • Uzman olmayan biri yalnızca AI’a güvenerek geliştirme yaparsa, kod tabanındaki karmaşıklık ve verimsizlik birikir; bu da ironik biçimde problem çözme yeteneğinin hızla düşmesine yol açar

Kod incelemesinin özü ve etkisi

  • AI ile işbirliği yapmak, hevesli ama deneyimsiz bir junior geliştiriciyle çalışmaya benzer
    • AI’ın muhakeme gücü zamanla gelişmediği için sürekli gözlem gerekir
  • Kod incelemesindeki en büyük hata, yalnızca yazılmış koda bakıp daha iyi bir alternatif olup olmadığını düşünmemektir
    • En iyi kod incelemesi, yapısal bir bakışla tüm sistem bağlamını bütüncül olarak değerlendirir
    • Yeni ve gereksiz sistemler kurmak yerine mevcut sistemleri yeniden kullanmanın yolları önce gelmelidir
  • Yalnızca ayrıntılı kod stiline takılan bir 'nitpicky' incelemeci, AI araçlarının gerçek potansiyelini kaçırabilir
  • 'rubber-stamp' türü, eleştirmeden onay veren bir incelemeci ise AI/junior geliştiriciyle etkili işbirliği kurmakta zorlanır

AI araçlarını kullanma becerisi üzerine düşünceler

  • git gibi geleneksel araçların net bir yapısı ve kullanım biçimi vardır; ancak AI’ın temel yapısı opaktır
    • AI neredeyse her tür işlemi gerçekleştirebilir
  • Bazıları AI araçlarını çok yönlü şekilde kullanmanın AI becerisi olduğunu düşünüyor
    • Gerçekte ise deneyimli kullanıcılar çok daha fazla olasılığı ortaya çıkarabilir
  • Şimdilik AI kod ajanları pek çok farklı işte yardımcı olabilir, ancak yakın denetim gerektirir
  • "Centaur satrancı" modelinde olduğu gibi, deneyimli insanın yönlendirmesi ile AI’ın önerileri birleştiğinde en yüksek verimlilik elde edilebilir
  • AI’dan yararlanma becerisi sonuçta kod inceleme yeteneğine ve eleştirel tasarım muhakemesine dayanır
  • Kod inceleme becerisi ne kadar iyiyse, agentic AI araçlarından alınan verim de o kadar artar

Son düşünceler ve beklentiler

  • AI ajanları zaman geçtikçe giderek daha deneyimli mühendisler gibi gelişiyormuş hissi verebilir
  • Önümüzdeki birkaç yıl içinde AI ile çalışma deneyimi, orta kıdemli bir mühendisle çalışmaya yakın bir seviyeye evrilebilir
  • Bugün için Codex, Claude Code, Copilot gibi çeşitli AI araçlarıyla deney yapmak yerindedir; burada en önemli ayırt edici unsur eleştirel denetim becerisidir

Ek görüşler

  • Hacker News gibi yerlerde “AI ajanları ne ölçüde faydalı?” sorusu etrafında tartışmalar oldu
    • Yazar, yalnızca kod incelemesiyle AI’ın Linux kernel düzeyinde katkı sağlayabileceğini düşünmüyor
    • Bazıları stil ve adlandırma gibi kod inceleme yöntemlerinin de önemli olduğunu savunuyor
    • Tasarım tartışmalarının kod incelemesinde yapılmasına eleştirel bakanlar var, ancak yazar buna olumsuz yaklaşmıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-09-23
Hacker News yorumu

  • Süreç kötü olsa bile kalite kontrolü iyi yapılırsa iyi sonuç çıkacağı fikri bana oldukça şüpheli geliyor; bu, "durmadan çer çöp üret, biri kontrol ettiği sürece sorun olmaz" demek gibi ve gerçek hayatta bunun iyi çalıştığını hiç görmedim. ABD otomotiv sektöründe buna benzer denemeler olmuştu ama başarılı bir örnek hatırlamıyorum. Düşünsenize, bana ekip lideri olarak üstüm gelip "yetenekli 5 kişi yerine tamamen acemi 25 kişi alacağım, belki şans eseri bir şeyler tutar; sen de hepsini incele" dese, bu tam bir saçmalık olurdu. Ama işin içine AI girince birçok insanın "hmm, belki olur?" diye düşünmesi ilginç.

    • Tecrübesiz ya da motivasyonu düşük insanların kodunu review etmek de aşırı yorucu. Zihinsel ve duygusal olarak çok enerji tüketiyor. Aynı özelliği 4 kez review edince insan bıkıyor ve kalite artık daha fazla artamayacak noktaya gelmeden pes edebiliyor.

    • Bu, Deming’in (Edward Deming) Japonya’da geliştirip Batı’ya taşıdığı kalite yönetimi anlayışının tam tersi. Kalite insandan değil, süreçten gelir. Hata oranı yüksek bir süreci seçip sonra insanların hataları yakalamasını beklemek, amaç kaliteyse hiç de iyi bir yöntem değil. LLM’ler birçok şekilde kullanılabilir ama bunların yalnızca bir kısmı gerçekten avantaj sağlar. Yönetim tarafı AI’nın her sorunu çözebileceği yanılgısına kapılmış gibi; ya AI’nın güçlü ve zayıf yanlarını doğru anlamıyorlar ya da Deming’in derslerini unuttular.

    • Evrim de rastgele mutasyon ve seçilimdir; hatta tüm karmaşık yaşamın varlığı bunun örneği. Benim tercih ettiğim yöntem değil ama moda kavramlara kapılıp alakasız yerlere bile gelişigüzel uygulama eğilimi var. Bazı mutfak eşyalarının plastik parçalarının üretiminde hâlâ düşük kaliteli baskı alınıp sonra günlük işçilerin bunları elle bıçakla düzeltip paketlediği süreçler kullanılıyor; ben de böyle geçici işlerde çalıştım. Yarı iletkenlerdeki chip binning / yield management da başarısızlık oranı çok yüksek örnekler sayılabilir. Etrafımıza bakınca şüpheli süreçlerin istisna değil, günlük hayatın parçası olduğunu görüyoruz.

    • İnsan kendini "AI kullanmayı iyi biliyorum" diye değerlendirmeye başlayınca, çözebildiği problem alanının inanılmaz genişlediği yanılsamasına kapılıyor. Bu her genel amaçlı teknolojide olur. Geçmişte genetik algoritma patlamasında da benzeri vardı. Herkes "genel amaçlı" bir araç bulup onunla her şeyi yapabileceğini sanıyor. Gerçekteyse hiçbir bağlam olmadan optimizasyon yapmaya çalışıyor. AI bunun daha da uç bir örneği.

    • Süreç ne kadar iyi olursa olsun, doğru çalışan bir sistemin nasıl kurulacağını bu şekilde öğrenemezsin. Tekrar tekrar gördüğüm örüntü şu: ekip uzun süre debeleniyor, sonra en sonunda problemi gerçekten nasıl çözeceğini bilen bir mühendis devreye girip doğru yönü veriyor.

  • AI’ya istenen parametreleri takip ettirmek gerçekten çok zor. Sürekli rastgele saçma yönlere sapıyor. nftables highlighting üzerinde çalışırken 230 token, 2.500 durum ve 50 binden fazla state transition vardı. AI’ya aşağıdaki beş açık kuralı verseniz bile hepsinden rastgele noktalarda sapıyor. Sadece kod çıktısında değil, çok basit Vimscript’i bile düzgün üretemiyor. Sonuçta AI’yı sadece dokümantasyon amaçlı kullanıyorum. Yine de rule, chain_block stmt, map_stmt_expr gibi parçaları açıklamada epey işe yarar hâle geldi. Ben de istediğim sözdizimi desenlerini kopyalayıp kullanıyorum.

  • AI ile kod üretimi projenin erken aşamalarında oldukça faydalı olabilir ama olgun projelerde kaygı verici yanları var. Kısa süre önce 280k+ LOC’lik Postgres parser’ını Multigres’e merge ettiler ve bu açık review olmadan yapıldı. Açık kaynak ekosisteminde bu dikkat edilmesi gereken bir durum. Birçok insan öğrenmek ve referans almak için böyle projelere güveniyor; yeterli review olmadan AI kodu girdiğinde, hem eğitsel değer hem de bağımlılık olarak güven zayıflıyor. Kod review yalnızca bug yakalamaz; katkı verenlerin öğrenmesi, tasarım gerekçelerini anlaması ve ortak bilgi birikimi oluşturması için de temeldir. Sorun hız değil, bilgi aktarım süreci. Bu arada PR’ın ne kadar süre sonra açığa çıktığıyla ilgili olarak şu bağlantıya bakılabilir.

    • Bu işi ben denetledim ve daha iyi bir yöne dair her türlü geri bildirime açığım. Bu durumun özel yanı, LLM kullanılarak Postgres C parser’ının çevrilmiş olmasıydı. Ölçek o kadar büyüktü ki satır satır review etmek mümkün değildi; bunun yerine tutarlılığı güvenceye almak için ayrı bir süreç kurduk. Her gün dikkatle kontrol ederek iki ay harcadık. Postgres testlerinin büyük bölümünü taşıyıp başarıyla port ettiğimiz için çalışma güvenilirliği konusunda da yeterince güvenimiz var. Multigres şu anda çok erken aşamada; ileride Vitess gibi daha fazla projede büyük çaplı kopyalama/çeviri denemeleri yapmayı planlıyoruz. İyileştirme önerileri gelirse kabul edeceğiz. Yazar da tüm süreci anlatan bir blog yazısı hazırlıyor, ilgilenenler bakabilir. Kişisel olarak LLM yardımıyla başarılabilen şeylere gerçekten çok şaşırdım. Elbette belirli bir ustalık gerekiyordu ve bu kişi burada belirtilen çıtanın da ötesine geçti.

  • Benim sürecim kabaca şöyle:

    1. AI’ya gereksinimleri veriyorum
    2. Belirsiz kalan noktaları bana sormasını sağlıyorum
    3. Artık soru kalmayınca gereksinimleri resmi bir PRD biçiminde yeniden ifade etmesini istiyorum
    4. Ben eleştiriyorum
    5. İki alternatif mimari önermesini istiyorum
    6. Birini seçip eleştiriyorum
    7. İki ayrıntılı TODO listesi önermesini istiyorum
    8. Birini seçip eleştiriyorum
    9. TODO’lardaki maddelerden biri için iki farklı uygulama yaklaşımı önermesini istiyorum
    10. Birini seçip eleştiriyorum
      1. adıma dönüp tekrarlıyorum
        Sürecin farklı noktalarında snapshot alıp geri dönüyorum.
        Böyle yapınca mükemmel olmasa da en azından kendi uygulamam için bir referans noktası olacak sonuçlar elde edebiliyorum.
        Dezavantajı ise inanılmaz zaman alması ve vakaların %80’inde "bunu baştan sona tek başıma yapsam daha hızlı olurdu" diye düşünmem.

    • Tek başına yapmaktan daha yavaş görünüyor. AI ile kod yazmak bazen sanki "bir iki kadeh içip bana bıraktığın notlara göre bir şeyler yaptım, nasıl olmuş?" diyen orta seviye bir geliştiricinin hafta sonu gece doğaçlama ürettiği bir şeyi görmek gibi. Sonra "HAYIR, beğenmedim" diyorsun; ama kaba yönü doğruysa onu refactor ederek pazartesi sabah sıfırdan başlamaktan biraz daha hızlı olabiliyor.

    • Bu tür adım adım rehberleri her gördüğümde, aslında sürece devasa bir uğraş eklendiğini ve en başta AI’dan beklenen verimliliğin ortadan kalktığını düşünüyorum. Kendi deneyimimde de bu neredeyse doğru. Elbette AI’nın yardımcı olduğu anlar var ama ne zaman ve nerede işe yaradığını ayırt edebilmek de başlı başına önemli bir beceri.

    • Ben biraz daha alt katmanlarda çalışıyorum ve genelde şöyle yapıyorum:

      • Temel arayüzü kendim kuruyorum ya da zaten varsa bir sonraki aşamaya geçiyorum
      • LLM’i otomatik tamamlama aracı gibi kullanıyorum
      • Gereksinimleri anlatıp hangi giriş noktası dosyalarının değişmesi gerektiğini söylüyorum
      • Hedefi tek seferde vermeyip her seferinde yalnızca bir adım iletiyorum
      • İşlerin ters gitmeye başladığını görür görmez araya girip durduruyor ya da AI yanlışsa yön veriyorum
        Genel olarak, çok geniş ve uzun hedefler tek seferde verildiğinde ajanın işin ne zaman tamamlandığını yanlış değerlendirmeye çok meyilli olduğunu gördüm.

    • Benzer ama daha sade bir süreç kullanıyorum. PRD’yi de veriyorum, kabaca mimariyi de söylüyorum ve her bileşeni istediğim şekilde uygulatıyorum. Hâlâ çok zaman alıyor ve doğrudan kendim yapmak daha hızlı olurdu ama artık satır satır kod yazmakla uğraşmak istemediğim için bazı işleri LLM’e fonksiyon bazında vermeyi düşünüyorum.

    • AI’yı yalnızca genel yaklaşım, kütüphaneler ve dil özellikleri hakkında fikir almak için kullansaydım, asıl işi doğrudan kendim yapmak çok daha hızlı olurdu.

  • Kod review konusunda iyiseniz, AI agent’ları hiç kullanmamak daha iyi olabilir.

    • Claude Code gibi agent’lara âşık olmuş ekip arkadaşlarımın yazdığı kodları review edip bug düzeltirken hissettiğim şey şu oldu: kodlar çoğu zaman sanki halüsinasyon hâlinde yazılmış gibiydi ve yazan kişi de onları neredeyse hiç açıklayamıyordu. Elbette gerçekten iyi kod üreten insanlar vardır diye düşünüyorum ama benim bizzat gördüklerim hep hayal kırıklığı yarattı. Neyse ki bazıları bunu kendiliğinden fark edip tekrar düzgün yönteme döndü. Son zamanlarda agent tabanlı workflow’lardan çıkan işleri eleştirel gözle inceleyince cevabın oldukça açık olduğunu düşünüyorum. Kodu iyi review eden biri bu sonuca çok daha hızlı varacaktır.

    • Eğer kod review işinde iyiysem, daha da iyi olmak isterim.

  • Kod review’ı titizlikle yapanlar AI araçlarını kullanmakta zorlanıyor, buna karşılık üstünkörü yapanlar AI’ya aşırı bağımlı hâle geliyor.
    Yani kod review’ı iyi yapan insanlar için doğrudan kodu kendilerinin yazması daha iyi ve özellikle bu tür projelerde uzun vadede bakımı da kendileri üstlenecekleri için bunu yapmaları çok daha doğal. Kod yazmak seni rahatsız etmiyorsa ve bunda iyiysen, AI kullanman için çok az sebep var. AI en çok, bilmediğin bir araç ya da yeni bir şeyi öğrenirken kısa kısa yoklamak için uygun. Yine de son zamanlarda LLM’ler sayesinde arama motoru özetlerinin iyileştiğini kabul ediyorum. Gereksiz dokümanları didikleyip durmak ya da konunun özüyle ilgisiz şeylere dalıp zaman kaybetmek neredeyse sıfıra indi.

  • Kod review de işin bir parçası ama en keyifli kısmı değil. Geliştiriciler tatmini çoğunlukla doğrudan kod yazarken alıyor. AI araçları faydalı olabiliyor ama hem öngörülemezler hem de ikna edici göründükleri için daha dikkatli review gerektiriyorlar; yani yükü azaltmak yerine artırıyorlar. Neden eğlenceli kısmı elimizden alıp sadece sıkıcı tarafı büyüten araçlar yaptık? Bir de merak ediyorum: "kod review" için özel ajanlar nerede?

    • Aslında ben kodun kendisini "yazma" kısmını çok eğlenceli bulmuyorum. Problem çözmek, yeni bir şey inşa etmek, sistemi parçalara ayırıp daha iyi bir yapıda yeniden birleştirmek daha eğlenceli. LLM’lerle kod yazınca, fikirleri gerçekten elle tutulur çıktılara dönüştürme hızım belirgin biçimde artmış gibi geliyor. Mevcut kodlarda type safety daha iyi oluyor, dokümantasyon güçleniyor ve karmaşık refactor’lar kolaylaşıyor. Ben LLM’den problem çözmesini beklemiyorum; bağlam toplama, kalıp yeniden uygulama ve tekrarlı kodu otomatikleştirme için kullanıyorum. Özellikle birçok dosyaya dağılmış kodları tek tek yazmak yerine AI ürettiğinde sadece değişiklikleri kontrol etmek yeterli olduğu için çok rahatlatıcı.

    • OpenAI Codex Cloud kod review özelliği ekledi ve yeni GPT-5-Codex modeli özellikle kod review için eğitildi [Codex yükseltmelerinin tanıtımı]. Gemini ve Claude tarafında da GitHub Actions ile entegre kod review özelliği ve Claude GitHub entegrasyonu geldi. GitHub da kendi Copilot Code Review özelliğini yayınladı. CodeRabbit, Greptile, Qodo Merge gibi bu işe odaklanan birçok startup da var.

    • Beni gerçekten heyecanlandıran an, bir şeyi uygularken altında yatan son derece zarif yapıyı keşfedip bunun önceki programlama biçimimi, hatta bazen yaşam biçimimi bile değiştirmesi oluyor (gerçi böyle şeyler çok nadir yaşanıyor).

    • Junior geliştiriciler daha çok doğrudan kod yazmayı sever, senior’lar ise çoğu zaman kodu azaltmayı sever. Benim içinse kod review, teslim tarihi baskısı altında olmadığım zamanlarda işimin en eğlenceli kısmı. Kod review’ın sıkıcı olduğu iddiasına katılmıyorum.

    • Girişte "çoğu geliştirici yeni bir şey inşa etmeyi sever" denmişti ama pratikte başkalarının kurduğu bir codebase üzerinde kalıpları ve yapıyı anlayıp iyileştirmeyi tercih eden çok insan var. Tamamen yeni bir şeyi baştan kurma süreci (ilk tasarım - sonsuz yineleme) bazı insanlar için daha yorucu olabilir; bunu da hesaba katmak gerekir. "Eğlenceyi alıp sıkıcılığı artırdık" sorusuna gelirsek, muhtemelen üretkenlik artışının en çok hissedildiği noktaya odaklandılar. Review AI tarafında da CodeRabbit, GitLab Duo gibi birçok seçenek zaten mevcut. RooCode gibi araçlarla Git diff verip kod review yaptırmak da gayet mümkün.

  • Bu yazının başlığı bana fazla indirgemeci geliyor. Kod review ile tasarım review aynı şey değil ve AI ile denenen şey bunlarla da sınırlı değil. AI’dan verim almak için o alan hakkında uzmanlık gerekiyor; kod yazma bağlamında bile sadece review becerisi yetmez, AI’ya yaptırdığın iş hangi alandaysa onu doğrulayabilecek yetkinliğin de olmalı. Hatta AI’nın daha faydalı olduğu durumlar, iyi bilmediğim bir dil ya da framework ile karşılaştığım zamanlar oluyor ama bu durumda da derin bir kod review yapamıyorum. "Coding" kelimesinin AI/LLM çağında yeniden moda hâline gelmesi de ilginç. Şirketler artık sadece kod yazan kişilerden çok, mimari, gereksinim analizi, full-stack geliştirme ve operasyonu bir arada yapabilen mühendislere yöneliyor gibi.

    • Resmî unvanım "Software Engineer" ama son 5 yılda

      1. Ekibimiz için Kubernetes cluster’ını bizzat kurup işlettim
      2. Çok yoğun biçimde Docker kullandım
      3. CI/CD pipeline geliştirdim
      4. Sayısız entegrasyon ve test işi yaptım
      5. Çeşitli sistem diyagramları dâhil olmak üzere bolca gereksinim dokümantasyonu hazırladım
      6. Altyapı ekibinin yapmadığı türlü çeşitli IT işlerini üstlendim
      7. Arada bir de kod yazdım

    • AI agent’larını doğru kullanmak, review süreciyle aynı şeydir.
      Çünkü LLM’ler çok büyük miktarda kod üretebilir ama yetkin bir yazılım mühendisinin sahip olduğu derin muhakemeye henüz sahip değiller.
      İşlerin yanlış yöne gittiğini fark etmeden uzun süre kod birikmesine izin vermektense, rotayı erkenden düzeltmek çok daha iyidir. Tıpkı junior bir geliştiriciyle çalışırken yaptığınız gibi önce büyük resmi ve tasarımı konuşup yön sapmaya başladıkça erkenden müdahale etmek daha akıllıca. Çünkü 100K token’lık kod biriktikten sonra ilk 100 satırın hatalı olduğunu fark ederseniz, sonunda her şeyi baştan elden geçirmeniz gerekir.

  • Ekip arkadaşlarımla kod review yaparken ortak bilgi ve kalite çıtasının yükselmesi fikrini çok seviyorum. Ama inatçı ve işbirliğine yanaşmayan bir AI’nın kodunu review etme düşüncesi bile bana tükenmişlik hissi veriyor.

  • İşimde en sıkıcı kısmı iyi yaptığım için hayatım boyunca sadece o işi yapacakmışım gibi düşünmek can sıkıcı geliyor. Dürüst olmak gerekirse hoşuma gitmiyor. Ayrıca yazıda da dendiği gibi, bug’ların en iyisi baştan hiç girmeyenidir. Sonradan yakalanmaları her zaman risk taşır.