Yapay zekayı kullanarak daha iyi kodu daha yavaş yazmak

• Yapay zeka ile kodlama, yalnızca düşük kaliteli kodu hızla ve büyük miktarda üretmek için değil, PR’ları derinlemesine inceleyerek yüksek kaliteli kodu daha yavaş üretmek için de kullanılabilir
• LLM ajanları, kod tabanında hata tespiti konusunda güçlüdür; ancak asıl zorluk, bulunan maddelerin önceliklendirilmesi ve doğrulanmasındadır
• Birden fazla modeli birlikte kullanan Claude skill, Claude sub-agent, Codex ve Cursor Bugbot ile PR’ları inceler ve yanlış pozitifleri azaltılmış nihai bir rapor oluşturur
• İş akışı, critical/high sorunları tekrar tekrar düzeltmek, maliyetine göre getirisi düşük maddeleri atlamak ve çok fazla kritik sorun varsa PR’dan vazgeçmek şeklinde işler
• Bu yaklaşım, hızdan çok kod tabanının sağlığını önemser ve hata modlarını ile mevcut bug’ları anlamaya dayalı dikkatli programlamayı güçlendirir

---

Yapay zeka ile kodlamayı yavaş yapmak

• Yapay zeka ile kodlamayı yalnızca düşük kaliteli kodu hızla ve büyük miktarda üretme aracı olarak görmek, LLM’lerin esnekliğini küçümsemektir
• LLM’ler, hızlı kod üretmenin yanı sıra daha yüksek kaliteli kodu daha yavaş yazmak için de etkili biçimde kullanılabilir
• slop cannons gibi doğrulanmamış büyük PR’lar yağdıran yaklaşımın tersine, PR’ları daha derin inceleyen ve başarısızlık olasılıklarını ısrarla kontrol eden bir yaklaşım da mümkündür

Hata tespitinden daha önemli olan doğrulama ve önceliklendirme

• Mythos, LLM ajanlarının kod tabanında hataları çok iyi bulabildiğini gösterir
• Başka örneklerde de Mythos dışındaki modellerin incelenmemiş kod tabanlarında çok sayıda hata bulabildiği görülür
• En yeni açık Anthropic ve OpenAI modelleri, ince hataları tespit etme ve yanlış pozitiflerden kaçınma konusunda farklılık gösterse de, yeterince çok hata bulabilir
• Gerçek zorluk, hatayı bulmanın kendisinden çok önceliklendirme ve doğrulamadadır

Birden fazla modelle PR inceleyen Claude skill

• Birden fazla modeli karşılaştırıp tartıştıran yapay zeka kod inceleme yaklaşımı, farklı modeller ne kadar çok devreye girerse halüsinasyonların veya yanlış hata raporlarının o kadar azaldığına odaklanır
• Kullanımdaki Claude skill, PR incelemesi için Claude sub-agent, Codex ve Cursor Bugbot çalıştırır
• Her araç, PR’deki hataları critical/high/medium/low olarak derecelendirir; ardından sonuçlar birleştirilerek yanlış pozitifleri ayıklanmış nihai rapor oluşturulur
• “Hata” kapsamı, proje ölçütlerine göre genişletilebilir
  • KISS ve DRY ilkelerinin ihlali
  • Erişilebilir HTML/JSX yazılıp yazılmadığı
  • SQL sorgularında uygun indekslerin kullanılıp kullanılmadığı
  • Bunun dışındaki projeye özgü kalite ölçütleri

Gerçek iş akışı ve karar ölçütleri

• Bu yaklaşım, PR’lerde çok sayıda hata bulabilir ve yanlış pozitif oranını neredeyse 0’a kadar düşürebilir
• Bulunan sorunlar, güvenlik ve doğrulukla ilgili kritik hatalardan performans sorunlarına, hatta “yorum kafa karıştırıyor” düzeyindeki düşük önem dereceli sorunlara kadar uzanır

• Genel işleme akışı

  • critical ve high dereceli sorunlar ajana düzelttirilir, ancak uygun çözüm insan tarafından yönlendirilir
  • critical/high sorunlar kalmayana kadar bu döngü tekrarlanır
  • Düzeltme maliyetine kıyasla getirisi düşük high/medium sorunlar atlanır
  • Dar bir edge case’i düzeltmek için 100 satır kod gerekmesi buna tipik bir örnektir
  • Çok fazla critical sorun varsa ve genel yaklaşımın yanlış olduğu düşünülürse PR’dan vazgeçilir

Üretkenlikten çok kod tabanının sağlığına odaklanmak

• Bu teknik, geliştirme hızını mutlaka artırmaz
• İnceleme sürecinde, PR’dan önce de var olan mevcut hatalar keşfedilebilir; bu da birim testleri yazmaya ve ince kusurları düzeltmeye yol açabilir
• Sıklıkla “vibe coding” ile ilişkilendirilen “10 kat üretkenlik” tarzı geliştirmeye neredeyse zıttır
• Karmaşık mimarilerde, normal akıştan çok hata modları daha ilgi çekici olabilir; bu hata noktalarını anlayıp düzeltme süreci, kod tabanını öğrenmenin bir yolu haline gelebilir
• Tüm kod tabanının sağlığını iyileştirirken iyi bilinmeyen köşeleri öğrenmek için faydalıdır

Yavaş vibe coding için pratik yöntemler

• Ajanla, kendisinin de tam anlamadığı yüzlerce satırlık PR’lar üreten bir geliştiriciyseniz daha yavaş bir yaklaşımı deneyebilirsiniz
• Ajana, PR’ın nasıl çalıştığını ve nerelerde başarısız olabileceğini sorabilirsiniz
• Gerekirse Mermaid charts içeren Markdown belgeleri yazdırabilirsiniz
• PR’ı baştan sona anlayana kadar Matt Pocock’un /grill-me skill’ini kullanabilirsiniz
• Kod satırı sayısına göre ölçülen “üretkenlik” artmayabilir ve çok fazla token harcadıktan sonra ilk planın yanlış olduğu sonucuna da varabilirsiniz
• Bu yaklaşım, LLM’lerden önce de hedeflenen dikkatli, sistematik ve kaliteye takıntılı programlamayı daha güçlü hale getiren bir biçime daha yakındır

[GN⁺]

Lobste.rs görüşleri

• İş yerimde AI ile daha hızlı ilerleme hayalinden vazgeçtik. Bizim durumda darboğaz kodlama değil
  Yine de kodlama ajanlarının güzel yanı, her zaman olmak istediğim mühendis gibi çalışmamı sağlamaları
  Örneğin biraz daha ileri gidebilen düzgün test harness'leri kurmak, üretilen kodun aslıyla eşleştiğini doğrulayan CI adımları eklemek ve değişiklik dağıtımlarını düzgün şekilde izlemek gibi işler
  Eskiden GitLab CI kılavuzunu okuyup koşulları nasıl uyduracağımı ve şirketimizin dolambaçlı yöntemini çözmem gerekeceği için takvim açısından altından kalkamayacağım şeylerdi; şimdi ise mümkün ve bence gelecek de bu

• LLM'i API'yi bilen bir spike partneri ya da mekanik bir refaktör aracı olarak kullanınca epey başarılı sonuçlar aldım; özellikle de güçlü tipli dillerde çok etkili. Test yazmak için de iyi, ama o testlerin gerçekten kısıtlayıcı güce sahip olup olmadığını doğrulayan çok katmanlı bir süreç olmalı
  Mutasyon testi oldukça yardımcı oldu ve orijinal yazının önerdiği gibi birden fazla gözden geçirme de gerekli
  Eskiden LLM'lere çok daha olumsuz bakıyordum; dönüp bakınca neredeyse irrasyonel denecek kadar, ama bunun büyük kısmı LLM'lerin ortaya saçtığı düşük kaliteli yazılımdandı
  İçine girdikçe, onlara kartondan prototipleme aracı ve çok daha hızlı bir daktilocu gibi yaklaşmanın doğru olduğunu gördüm. Mesela “bu Lean projesindeki tüm teoremlerde şu deseni bul, bununla değiştir; hemen çalışmayan yerleri de işaretleyip bana kalanların listesini ver” dediğimde, benim vim, sed, awk ve çeşitli geçici çözümleri karıştırarak ilk bir iki denemeyi yapacağım sürede, 100'den fazla teoremi parçalar halinde düzeltebiliyor
  Lean'de dil özellikleri ve yaptığım iş nedeniyle “derleniyor” ile “çalışıyor” arasındaki mesafe dar; bu yüzden özellikle iyi. Rust'ta da iyi bir test paketi ve mutasyon testi eklendiğinde benzer hissi alıyorum
  Bu araçların uzun vadeli etkisinin “düğmeye bas, ürün çıksın” değil; iyi mühendislerin bunları benimseyip enerjilerini önemli işlere odaklaması ve eskiden yaptıkları angaryaların önemli bir kısmını makinelere devretmesi olacağını düşünüyorum

  • Ben de başlangıçta LLM'lere çok olumsuz yaklaşıyordum, ama artık köstek olmaktan çok yardımcı olacak kadar iyileştiklerini düşünüyorum
    Verdiğin örnek ilginç; eskiden JavaScript framework ekibinde çalışırken yükseltme ya da migration gibi işler için bizzat codemod yazardım. AST'lerle uğraşan zahmetli bir işti
    Bugün olsa bunu LLM'e verip %90 civarına ulaşabileceğimi düşünüyorum

• Bu bakış açısını beğendim. Aracın esnek olması ve mutlaka düşük kaliteli çıktılar üretmek zorunda olmaması apaçık görünüyor, ama hem savunanlar hem reddedenler bu perspektifi sık sık göz ardı ediyor
  Henüz LLM ile code review yapmayı denemedim ama yapılacaklar listeme eklemeliyim. Şimdiye kadar daha çok fikir üretimi, SQL ya da VimScript yardımı için kullandım; kodu ise kendim yazıyorum
  Bir risk şu ki code review de bir beceri; modele fazla yaslanırsanız bu beceri körelebilir. Ama ticari ortamda en iyi code review bile genelde “makul süre” ile “bu kişiye güveniyor muyum” kombinasyonudur; matematiksel doğruluğa yakın bir şey değildir

  • Bu da doğru, ama bu iş akışının aksine benim code review becerimi artırdığını hissettim. Çünkü “bug”ın gerçekten mümkün olup olmadığını yoksa sadece teorik mi kaldığını değerlendirmek, düzeltmeye değip değmeyeceğine ve bir sonraki PR'a mı bırakılması gerektiğine karar vermek gerekiyor
    Karmaşık bug'ları ise hâlâ bizzat sonuna kadar düşünüyorum; çünkü 1) halüsinasyonlar hâlâ işin içine karışıyor, 2) zaten sistemi uçtan uca anlamanın değeri var

• Meta bir not ama bu yazının aldığı flag'leri anlamıyorum. 1 tane konu dışı, 3 tane spam çok tuhaf
  Ana sayfanın en tepesindeki yazı da LLM kullanımına dair ve genel yazma pratiğiyle ilgili; kodlamaya odaklanan bu yazıdan bile daha az konuya uygun görünüyor ama onda flag yok gibi

  • Muhtemelen kendini tanıtma olarak görülüp spam flag'i alıyordur

• Lobsters'ta böyle bir bakış açısı görmek ferahlatıcı. Baştan savma anti-AI tutumu giderek yorucu oluyor. Düşük kaliteli çıktıları seven kimse yok; bunda herkes hemfikir olabilir
  Ama AI'ı tamamen boykot edip dogmatik bir tavır alanlar, daha pragmatik yaklaşanlara kıyasla geleceği kabullenmekte daha çok zorlanacak
  En başından beri AI'ın elektrikli el aletlerinin icadına benzediğini söylüyorum. Lastiği el anahtarıyla değiştirmek istiyorsanız sorun yok, ama darbeli matkap çıktığında tamirciler boykot etmedi. Yazının bağlamında en iyi benzetme olmayabilir ama yine de böyle olduğunu düşünüyorum
  Doküman okuyarak öğrendiğimden daha fazlasını AI kullanırken öğrendim. Çünkü dokümana ek bağlam, açıklama ya da örnek gerektiğinde soru soramıyorsunuz. “Bir şey yap, hata yapma” da diyebilirsiniz ama gerçekten öğrenmek için ben yavaş yaklaşımı tercih ediyorum

  • Burada toptan bir anti-AI tutumu görmedim. Örnek verebilir misin?
    Benim gördüğüm şey, LLM ile milyonlarca satır kodu tek seferde değiştirip insan incelemesi olmadan dağıtıma çıkarma yönündeki değişimlerin eleştirisiydi. Özellikle Bun'un Zig'den Rust'a taşınmasıyla ilgili başlık gibi
    Bu yazı da zaten bunu eleştiriyor