Yapay zekayı kullanarak daha iyi kodu daha yavaş yazmak
(nolanlawson.com)- 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
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-meskill’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
2 yorum
Hacker News yorumları
AI ile çalışınca artık tek seferlik basit bir süreç değil, uzun bir ileri geri inceleme döngüsü haline geliyor
Orta ölçekli, birden fazla alana yayılan özelliklerde önce AI ile uygulama tasarımını çıkarıyor, ayrıntıları gözden geçiriyor, ardından yavaş ama sonucu iyi olan Claude 4.7 Max ile uyguluyorum
Sonrasında uygulamayı inceliyor ve Codex GPT 5.5 xhigh fast ile tekrar review ettirdiğimde neredeyse her zaman sınır durumlarını buluyor. Düzeltmeleri Claude'a yaptırıyorum; çünkü Codex hata bulma ve review konusunda güçlü olsa da kodu fazla tasarlama ya da kestirme çözümler karıştırma eğiliminde, buna karşılık Claude daha sezgisel ve bakımı kolay kod yazıyor
Ardından yeni bir Claude/Codex instance'ıyla staged değişiklikleri yeniden gözden geçirtiyor, geri bildirimi uyguluyor ve en son test de yazdırıyorum. Hâlâ elle yazmaktan daha hızlı, ama zamanın çoğu review ve sınır durumlarıyla uğraşmaya gidiyor; sonuçta ortaya çıkan v1 özellik, sanki birkaç kez tekrar edilmiş bir v3 benzeri uygulama gibi hissettiriyor
Verimli hissettiriyor, AI'ın çıktıları da iyi oluyor ve genelde kodu anlamış olarak kalıyorum. Bütün gün robotla tasarım ve mimari üzerine tartışınca, AI devriminin beni daha iyi bir mühendise dönüştürdüğü yerin tam da burası olduğunu hissediyorum
Benim yöntemim araştırma/planlama/test planını 5 tur döndürmek ve her önemli kararda kendimi döngüye dahil etmek. Büyük çerçeveden başlayıp ayrıntılara iniyorum; yalnızca planlama bile kendi zamanımdan 2-3 gün alabiliyor ve uygulama ajanı (Opus 4.7) saatler sürebiliyor
Uygulama birden çok aşama/commit'e bölünüyor ve her aşamada kod inceleme-düzeltme döngüsü var. Son derin kod incelemesi de 1-2 saat sürebiliyor; PR açınca Gemini review yapıyor, ben de bunu okuyup çözüyorum
Projeler yine birkaç gün ya da birkaç hafta sürüyor ama her şeyi tek başıma yapmaktan 5 kat daha hızlı
Ek: o skill şu depoda var: https://github.com/scosman/vibe-crafting
Bazı durumlarda AI'ın ürettiğini çöpe atıp doğrudan kendim yaptım. Bence insanların öğrenmesi gereken beceri bu. Bir noktada zararı kesmeyi bilmek gerekiyor. Özellikle basit değişikliklerde, ekip arkadaşlarımın LLM ile inatlaşarak bir şey yaptırmaya çalıştığını gördüm
AI'ları sürekli gözeterek biraz hız kazanma karşılığında, AI'ın ne yaptığına dair bilgi ve kontrolü azaltmış olmuyor musun
LLM'lerin birbirlerinin kod review'larını eleştirmesini anlatan yazı[1], magpie aracı[2] ve Cloudflare'in yakın tarihli kod review stack yazısı[3] oldukça ikna edici
Ben AI'a şüpheyle yaklaşıyorum ama sebebi “çalışıyor mu”dan çok “dünya için iyi mi” tarafı. Bu tür review işleri, ender biçimde, düşünmeyi dışarıya devretmeyen ya da çalışanların yetkinliğini köreltmeyen örnekler gibi geliyor. AI'a kod yazdırmak ya da AI'ın bulduğu sorunu yine AI'a düzelttirmek kadar aynı alarm zillerini çaldırmıyor. Elbette çevresel meseleler ve diğer etik kaygılar hâlâ büyük ölçüde ortada duruyor
Son dönemde AI kod review kalitesi beni etkiledi, ama GitHub PR üzerinde 3 ayrı AI revieweriyle tek tek etkileşime girme deneyimi korkunç. Daha yerel odaklı ve jj/rebase'i anlayan review turları olsa keşke
Bağlam: epey büyük bir PHP/Laravel backend ve Vue frontend
[1]: https://milvus.io/blog/ai-code-review-gets-better-when-model...
[2]: https://github.com/liliu-z/magpie
[3]: https://blog.cloudflare.com/ai-code-review/
LLM review/düzeltme döngüsüne harcadığım süre, ortalamada kodu doğrudan elle yazmaktan daha uzun sürüyor
Bunun bir nedeni, akışa girdiğimde kodu çok hızlı yazabilmem ve bazen kodun beklediğimden de hızlı çıkması. Bir diğer neden de LLM'in ilk birkaç denemede verdiği kodun çoğu zaman gerçekten kötü olması
Yine de ilginç olan şu: Kendim inceleyip tekrar tekrar review ve düzeltme talimatı verdiğimde, ortalamada aynı sürede benim yazacağım koda göre daha yüksek kaliteli bir sonuç çıkıyor. Başkasının kodunun birkaç tur yinelendiğini görünce, sanki odak akışında ortaya çıkan sonuçtan daha bütüncül biçimde ulaşmak istediğim hedefi anlıyorum
Bu yazı AI ile kod yazmaktan değil, yalnızca kod reviewdan söz ediyor
Ajan tabanlı kodlamada benim yaşadığım sorun şu: Programlama sırasında sayısız mikro mimari kararı veriyorum. Baştan eksiksiz bir spesifikasyonun olduğu durum neredeyse hiç olmuyor; yazdıkça spesifikasyonu da oluşturuyorum
Claude Code ya da Codex kullandığımda bu süreç ortadan kalkıyor. Claude Code hedefe ulaşma konusunda fazla istekli olduğu için, birlikte kod yazma deneyimi ateşli bir rüya gibi geliyor. Sonunda sınır durumları ya da projenin mimari/tasarım hedeflerine ne kadar uyduğuna dair güvenim azalıyor
Üstelik ben programlamadan, reverse engineering'den vb. keyif alıyorum. LLM bir problemi çözebilir ya da bir özelliği teslim edebilir, ama sanki işin eğlencesini elimden alıyor. Güvenle kullanabileceğim bir akış bulmaya çalışıyorum ama sonunda bu akışın sadece sohbet, arama ve düşüncelerim için bir rubber duck rolüne indirgenmesinden korkuyorum
Tersine, bazı şirketler mühendislerin insan geri bildirimini döngüye kattığı öz değerlendirme ajanı pipeline'larını sağlamlaştırıp, ajanların production kodunun büyük kısmını yazmasını sağlamaları gerektiğini savunuyor
Creao'nun CEO'su bu yıl ocak ayında tüm production sistemini 2 haftada yeniden mimarilediklerini söyledi. Ayrıca ajanların çok fazla özelliği çok hızlı hayata geçirdiğini ve iş geliştirme tarafının yetişmesini beklemek zorunda kaldıklarını da iddia etti
AI ile çıktıyı 100 kat artırma seçeneğiyle, AI sayesinde kendi becerisini geliştirme seçeneğinin nasıl değerlendirilebileceğini merak ediyorum
Bu arada AI'nin verimlilik artışı gerçek. Örneğin Snowflake'teki bir mühendislik organizasyonu, şirket tarihinde ilk kez 1. çeyrekte tüm OKR'lerini erken tamamladı. Normalde planlanan OKR'lerin %70'ine ulaşmak bile başarı sayılırdı; bunu gören mühendislerin hissedeceği stresi tahmin edebiliyorum
Bu yazının başlığı daha derinlikli olacakmış gibi görünüyordu ve gerçek kod örnekleri beklemiştim
Ama diğer görüş yazılarına benziyor. Yazarın işine yarayan prompt'ları, yani AI'ye bug bulmasını söyleme biçimini önerip herkesin de bunu yapmasını tavsiye etme düzeyinde
Bu araçları işte ve kişisel yan projelerimde kullandığım için görüp bir şeyler öğrenmeyi umuyordum, ama örneksiz görüş yazıları artık fazla çoğaldı
Yazar bunun için bir kod harness'i oluşturabilir ya da hızlıca bir şeyler bağlayabilirdi, ama şu anda bu tür araçlaştırma pratikte daha çok sizin alanınıza yakın görünüyor. Otomatikleştirip denemek istiyorsanız, ne istediğinizi kendiniz tanımlamak dürüst olmak gerekirse onun koduyla uğraşmaktan daha hızlı olabilir
Bunu okurken oldukça yoğun bir özellik üzerinde çalışıyordum ve epey yineleme gerekti
Nihai sonuç, ortalarda duran koda kıyasla aslında çok daha az kod oldu. Bu yüzden AI'nin gerçekten yardımcı olup olmadığını sorguladım. Yinelemeye harcadığım süre içinde kodu doğrudan kendim de yazabilirdim
Ama AI sayesinde hoşuma gitmeyen 4 özellik varyantını hızlıca kabaca deneyebildim ve aynı hızla çöpe atmak da dert olmadı
Eskiden yeni bir özelliği uygulamaya koymadan önce plan üzerinde çok fazla düşünmem gerekirdi ve mevcut kodla uyumsuzlukları ancak epey implementasyon yazdıktan sonra fark ederdim. Şimdi AI'den ayrıntılı bir uygulama planı isteyerek bu ufak tefek ayrıntı sorunlarını birkaç saat, hatta daha da kısa sürede bulabiliyorum
Son birkaç yılda ilginç olan şeylerden biri, kodlama tembelliğimin sınırını takip etmek oldu
Bir kodlayıcı olarak boilerplate koddan nefret ediyorum. Yazmaktan da nefret ediyorum, bakımını yapmaktan da. Bu yüzden tasarım ve mimariyi sık sık bu tercihin etrafında kurdum; bazen akıllıcaydı, bazen değildi. Her hâlükârda bu benim tercihimdi ve yapması zor gelen işleri kendimden uzak tuttum
Birkaç yıl önce LLM'ler kodlama için bir ölçüde işe yarar olmaya başladığında, aslında boilerplate konusunda çok iyi olduklarını ve 2023 civarında neredeyse sadece bunu iyi yaptıklarını fark ettim. Bu da beni, tasarım ve sistem mimarisinde birlikte çalıştığımız insanların güçlü ve zayıf yanlarını ne kadar örtük biçimde anlayıp buna göre ne kadar çok uyum sağladığımızı düşünmeye itti
En yeni modeller, insanlarla kıyaslandığında çok farklı güçlü ve zayıf yönlere sahip; bunları konumlandırmak ise farklı türde mimari ve mühendislik becerileri gerektiren ilginç bir alıştırma. Bundan keyif alıyorum ve umarım böyle devam eder
LLM'e prompt atıp ne çıkacağını bilememektense
django-admin startproject,npm init,meteor createile deterministik çıktı almak çok daha iyidirOlgun web ekosistemlerinde boilerplate en aza iner. Artık bu işi LLM'lere devrettiğimize göre,
startprojecttürü CLI'ler ve iyi varsayılanlar üretmeye dönük geliştirme çabasının azalmasından endişe ediyorumHoşuma gitti. Ben de benzer bir ralph-loop yaklaşımı kullanıyorum
Onaylanmış bir plandan başlayıp bunu koordinatöre veriyorum; basitleştirilmiş hâliyle süreç build ve review olmak üzere 2 oturuma bölünüyor ve her oturuma ayrı bir model bağlanıyor
Kodlama ajanları kullanmamın önündeki engel, ücretli harici hizmetlere bağımlı olmak zorunda kalmam
Kodlama için yeterince iyi sayılabilecek bir yerel model var mı?
Bu da yardımcı olabilir: https://hnup.date/hn-sota
Qwen modelleri bu hafta günlük kullanım için benim başvurduğum modeller
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
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
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
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
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