- LLM kodu sürekli sizin yerinize yazsa bile, yinelenen koşul ifadelerini ve geçici uygulamaları olduğu gibi merge ederseniz, daha sonra üretilen kod bu pratiği proje kuralı gibi izleyebilir
- Erişim yetkisi kontrol mantığını route handler, background job, API endpoint, webhook vb. yerlere tekrar tekrar koyarsanız testler geçse bile bakım yükü olduğu gibi kalır
- Model açık dosyalara, mevcut kalıplara ve son değişikliklere bakarak bir sonraki kodu ürettiği için, kopyalanmış 4 koşul ifadesi beşinci kopyayı çağıran bir sinyal hâline gelir
- Daha sonra refactoring isteseniz bile LLM’in mevcut tüm kopyaları düzgünce temizleyeceğini garanti etmek zordur; kötü kalıplar tek seferlik hatadan çok kod tabanının stiline yaklaşır
- Yinelenen koşul ifadeleri, “god” fonksiyonlar ve “sonra temizleriz” diye merge edilenler biriktikçe yalnızca prompt ile geri döndürmek zorlaşır ve sonunda bir insanın doğrudan düzeltmesi gerekir
LLM’in referans aldığı şey mevcut kod tabanıdır
- LLM kodu “vakumda” yazmaz; kullanıcının kod tabanını okur
- Açık dosyalar
- Zaten var olan kalıplar
- Son değişiklikler
- Kod tabanına merge edilmiş kestirmeler, “burada böyle yapılıyor” diyen bir öğrenme sinyali hâline gelir
- Aynı erişim kontrolü koşulu birden fazla yerde tekrarlanabilir
if (user.isActive && user.hasPermission('read') &&
!user.isSuspended && account.status === 'open') {
// do a thing
}
- Bu koşul ifadesi ortak bir helper’a çıkarılabilir, ancak LLM’in ürettiği kod çalıştığı ve testler geçtiği için olduğu gibi merge edilebilir
- Aynı kurala sahip beşinci endpoint’i istediğinizde, modelin baştan tasarlamak yerine repository içindeki mevcut kopyaları izlemesi daha olasıdır
Bakımı LLM’e bıraktığımız yanılgısı
- “Daha sonra değiştirirken de LLM halleder” düşüncesi, tekrarları ve code smell’leri görmezden gelmeye yol açar
- Birkaç yinelenen koşul ifadesi ölümcül olmayabilir, ancak bu tür code smell’ler birikmeye devam eder
- Yinelenen koşul ifadeleri
- “god” fonksiyonlar
- “sonra temizlenecek” diye yapılan merge’ler
- Kötü kalıplar çoğaldıkça bir sonraki prompt’un sonucunu da etkiler ve daha sonra tüm örnekleri LLM’in eksiksiz düzelteceğine inanmak zorlaşır
- Bakımı LLM’e outsource ettiğinizi düşünseniz bile, gerçekte giderek kötüleşen alışkanlıkları tekrar ettirdiğiniz bir duruma düşebilirsiniz
- Kodu, bir insan bakımını yapacakmış gibi yazmalısınız; LLM’in özümseyip size geri vereceği kod kalıplarını iyi durumda tutmalısınız
1 yorum
Hacker News yorumları
.claude/commands/review.mdiçinde boş bir Markdown dosyası olarak /review komutu oluşturup ajanın kontrol etmesi gereken bir checklist koymak iyi olabilirKod incelemesi gerektiğinde
/reviewyazarsanız, ajan bu checklist’e bakıp düzeltilebilecek maddeleri planladıktan sonra size soruyorBenim dosyam “Plan moduna gir. Bu branch ile main arasındaki farkları incele. Dikkate alınacaklar: ...” diye başlıyor; kod incelemesi sırasında bulup ajana düzelttirdiğim maddeleri sürekli ekleyince şimdi yaklaşık 200 madde oldu
Ajan genel bir geri bildirim duvarı alsa da aldırmadan maddeleri tek tek inceliyor; “Yeni yapılanların mevcut kodla tekrar etmediğini doğrula” maddesini ekleyince gerçekten temizlik çalışması planlamaya başlamasına şaşırdım
Hâlâ sadece yüzeyi kazıyan bir seviyede ve aracın daha iyi bir araç olabilmesi için araç için araçlar vermek gerekiyor
Şu anda bile oldukça basit talimatlar kullanıyorum ama Claude, “izin almadan git’e commit atma”, “commit mesajına imza ekleme” gibi ilk talimatları sık sık ihlal ediyor
Sorunca “evet, böyle bir talimat vardı ama görmezden geldim” diye yanıtlıyor; oturum içinde kibarca düzeltince anlıyor ama sonrasında bazen hiç commit atamaz hale geliyor
200 maddelik checklist inceletirseniz, bunların kayda değer bir kısmını sessizce kaçırıyor olma ihtimali yüksek
İnsan bir mühendis, mevcut 200 testin kullandığı bir assertion kütüphanesi varken yeni testte tamamen farklı bir kütüphane kullanmazdı; ama Claude bunu birkaç kez yaptı
Bu yüzden “yazmadan önce test konvansiyonlarını incele” gibi maddeler eklemeye devam ediyorum
Öte yandan bir fonksiyonun ne olduğu ya da testin değişiklik diff’ini ele alması gerektiği gibi temel şeyleri özellikle söylemeye gerek yok; fakat hangisini söylemek gerektiği, hangisinin sorun olmayacağı konusunda net bir liste olmadığı için kullanılabilir bir yöntem oluşturmayı deneme yanılmayla yapıyormuşum gibi hissediyorum
Benim durumumda ajanla gidip gelerek “gözüme ve zevkime iyi görünene kadar” rafine ettiğim çok oluyor ama henüz böyle bir liste oluşturmadım
Projeye göre önemsiz sorunlara veya magic number’lara izin verilebiliyor; başka projelerde ise
SECONDS_IN_A_DAY = 24 * 60 * 60gibi anlamlı adlandırılmış sabitleri zorunlu tutabiliyoruz, yani bağlama bağımlıhttps://github.com/alibaba/open-code-review
https://layandreas.github.io/personal-blog/posts/beyond-vide...
Örneğin Senior Engineer, Security Engineer, WCAG specialist gibi uzun bir rol listesinden değişikliğe en uygun N rolü seçmesini sağlıyorum
Claude bu review’ları paralel çalıştırıp geri bildirimleri birleştiriyor
Spesifikasyon tabanlı geliştirme yaptığım için, bulunan sorunları spesifikasyona ekleyerek sorunların ve kararların izini bırakıyorum
Burada birçok mühendisin üstüne bir de başka bir prompt ekliyor olması tuhaf geliyor.
Benim deneyimime göre bunu yaptıkça işler daha da kötüleşti; soyutlama yapıyor ama yanlış soyutlamalar üretiyor, gereğinden fazla yorum ekleyerek sonraki LLM çağrılarını bile karıştırıyor.
İyi bir kod tabanında idare eder çalışıyor ama kodu giderek kötüleştiriyor; kullanmaya devam edip bir noktada çalışmaz hâle geldiğinde, bunca zaman kendin yapmamış olmanın bedelini ödeyerek düzeltmek zorunda kalıyorsun.
Yeni bir kod tabanına ajan koyduğunda genelde koda dair bir zihinsel model oluyor ve kod da bir ölçüde sade kalıyor; ama tekrarlar biriktikçe ikisi de kayboluyor ve LLM performansı da düşüyor.
Bu yüzden LLM’i keşif ve inceleme için kullanıyorum, kodu ise kendim yazıyorum.
Kod yazmak çok da zaman almıyor ve işin en keyifli kısmı; insanların bundan neden kaçınmaya çalıştığını anlamakta zorlanıyorum. Ara sıra
/bugprompt’uyla yapay zekâyla aynı anda hata ayıklama yarışı yaptığımda da yapay zekâ her zaman daha hızlı olmuyor.Son birkaç yılda yazılım işi, meraklı tamirciler ve bulmaca bağımlıları için pratik mühendislik sığınaklarından biri olmaktan çıkıp, finans, hukuk ve tıp gibi para peşindeki zeki insanların kariyer yoluna dönüştü.
Bugün “yazılım mühendisi” unvanına sahip birçok kişi aslında bu işi hiç sevmemiş; sadece zeki ve sorumluluk sahibi oldukları için işverenin verdiği makul hedeflere ulaşmış kişiler.
Bu kişiler en çok, AI ajanlarının titiz tasarım ve bulmaca işini önlerine bariyer gibi koyup doğuştan gelen zekâlarını daha tembelce kullanmalarını sağlamasını istiyor.
Kodlama ve mühendislik ilkelerini içselleştirmedikleri için, aynı zihniyetteki iş arkadaşlarıyla çevrili olduklarında bu yaklaşımın ileride ne sonuçlar doğuracağını öngörmek zor.
Kodlamanın kendisi en başından beri çok bunaltıcı ve sürtünmesi yüksek bir deneyim olduysa, AI daha hızlı diye hissetmek kolay.
Kodu sadece okumak yeterli değil; acı çekerek deneyimlemek gerekiyor ki içselleşsin.
Ajanlar, mevcut yolun hâlâ var olması gerekip gerekmediğini sormak yerine eski kodu savunmacı biçimde sarmalamaya sıkça meylediyor; bu da muazzam miktarda savunmacı kodun Rus matruşkaları gibi katman katman yığılması etkisini doğuruyor.
https://softwaredoug.com/blog/2026/07/09/write-code
Opus 4.8 bir dönüm noktası oldu; özellikle karmaşık sorunlarda artık Opus 4.8’e karşı pek sık kazanamıyorum.
Herkes her iş ve soru için Opus 4.8 veya üstünü kullansa genel hava çok daha farklı olurdu; yapay zekâ şüphecisi de pek kalmazdı gibi geliyor.
Kodu hâlâ elle yazıyorum; tamamını değil ama bir kısmını Opus üretiyor.
Saçma bir fikir olabilir ama sadece kodu kendin yazmak da mümkün.
Yapay zekâ çağında inanması zor bir kavram gibi gelebilir ama insanların okuyup bakımını yapacağı kod söz konusuysa, onu o insanlar için bizzat yazmak daha iyi.
Aşırı uzun ve kopyala-yapıştır yapılmış kodu okudukça sinir olursun; başkaları için de aynı şey geçerli.
Kendin yazarsan kendi kendini düzeltir, başkalarının bakımını yapmasına anlamlı gelecek bir şekilde yazarsın.
Ya da gelecekteki bakımcının bekleyeceği kod biçimini ajanla döngünün anlaması için Markdown dosyalarından oluşan karmaşık bir ağ kurup onu yatıştırmaya çalışabilirsin.
Uzun vadede hangi yolun daha kolay olacağını bilmiyorum; döngü tabanlı, ajan güdümlü bir kod tabanını devralıp anlamaya çalışmış biri var mı merak ediyorum.
“Bir dahaki sefere aynı erişim kurallarına sahip bir endpoint’i LLM’den istediğinizde, model sıfırdan düşünmez; depoda zaten bulunan dört kopyadan başlar” sözünün ne kadar doğru olduğundan emin değilim.
Gerçekte, temel yapıyı tekrar etmeye ve yeniden kullanım ya da soyutlamayı daha az yapmaya yönelik yerleşik bir önyargı var gibi görünüyor.
Mevcut kalıp böyleyse onu izliyor gibi görünür; ama aslında her iki durumda da muhtemelen öyle yapacaktı.
Önceden sıkı bir soyutlama ve kullanım örnekleri koyup, yalnızca belirli bir soyutlama API’sini kullanmasını ve benim yazdığım biçimi de kopyalamasını açıkça söylesem bile, modern LLM’lerin ikisini de yapmayıp alttan başlayarak temel yapıyı yeniden uyguladığı ve soyutlamayı kısmen ya da tamamen yok saydığı çok oldu.
Bunun nedenini tam bilmiyorum ama eğitim kodunda bu tarz koddan o kadar çok var ki ağırlıklar bu şekilde sonuç üretmeyi daha iyi “biliyor” olabilir diye düşünüyorum.
Yine de LLM’i hızlı bir uygulama motoru olarak kullanmanın makul olduğunu düşünüyorum.
Asıl görev, model yanlış yöne koşmaya başlamadan önce bu uygulama kararlarını ortaya çıkarmasını sağlamak.
Büyük bir değişiklikten sonra şu prompt’la iyi sonuçlar aldım:
“Şimdi son kod kontrolünü yap. Her şey düzenli mi ve bileşenler sorumlulukların ayrılması ilkesini izliyor mu? Anlaşılır ve bakımı yapılabilir durumda mı? Artık doğru olmayabilecek varsayımlarda bulunuyor mu? Önceki düzenlemelerden veya denemelerden kalma kod kod tabanına girmiş mi? Dokümantasyon hâlâ kodun güncel durumunu yansıtıyor mu?”
O zaman yukarıda söylenenleri ve daha fazlasını çoğunlukla çıkarıyor.
Ancak sürekli özellikle belirtmem gereken şey, “ilerleme takibi” amaçlı tüm yorumları silmesi ve yalnızca uzun vadeli bakıma uygun yorumları bırakması.
Claude, “butona tıklamak artık kaydetmeyi tetikliyor ve artık onBlur kullanılmıyor” gibi yorumlar bırakıyor; oysa gerçek kod hiç onBlur kullanmamış oluyor ve bu sadece aynı iş/branch içinde Claude’un az önce yapmaya çalıştığı şeyi benim geri çevirmiş olmamın izi olabiliyor.
Model bunu kafasına göre yorumlayacaktır ama yine de çoğu zaman hiçbir şey yapmamaktan daha iyi olabilir.
Yapay zekâya her şeyi öğretip doğru öğrenip öğrenmediğini sorma yöntemi; sonuçlar şaşırtıcı derecede iyi oluyor.
Bu yazıdakine benzer adımları izliyorum.
https://www.lucasfcosta.com/blog/backpressure-is-all-you-nee...
Eski bir deyiş vardır:
“Bir sonraki bakımcının nerede yaşadığını bilen bir katil manyağı olduğunu varsayarak koduna yorum yaz.”
Yakın zamanda bir PR incelemesinde böyle bir şeyle kaçıncı kez karşılaştığımı bilmeden öfkeyle yorum yazdım; sonra kendim de şaşırdım
Böyle bir tepki verebileceğimi bilmiyordum
Yani kodun kendisi yeterince açık olmadığı için yorum vardır demek; böyle durumlar da var, ama genel olarak yorumun az olmasındansa çok olmasının daha iyi olduğunu düşünüyorum
Özellikle kodun gerçek iş ya da özellik gereksinimleriyle nasıl bağlantılı olduğunu açıklıyorsa ve yalnızca kodun ne yaptığını tekrar etmiyorsa daha da iyi
Birkaç yıl önce önce yorumları yazardım
Genel hedefi açıklar, bunu rutinlere ve iş sırasına böler, tatmin olunca yorumların arasına kod bloklarını doldururdum
Bir tür edebi programlama gibi; ama bu terimi bilmeden önce de yaptığım bir yöntemdi ve hedefe doğru kendime prompt vermeye daha yakındı
Dezavantajı, yorumların sonunda kolayca kodun yaptığı işi İngilizce açıklama düzeyine inebilmesi ve gelecekteki bakımcı için pek yararlı olmayabilmesi
Kod kendi kendini açıklamalı; yorumlar da ejderhanın olduğu yerlere yazılmalı
Benzer bağlamda sevdiğim bir prompt şu: “Yazdığın testleri gözden geçir. Bu test gerçekten amaçlanan şeyi test ediyor mu? Kod bozulursa test de başarısız olur mu?”
LLM’lerin hiçbir şeyi doğrulamayan boş testleri ne kadar sık yazdığı şaşırtıcı
Hâlâ böyle şeyleri ciddi ciddi tartışmak zorunda mıyız diye düşünüyorum
LLM ile bu kadar “deney” yaptıysak artık bunu doğal kabul etmemiz gerekmez mi?
Elle kod yazmayı yeniden tabu gibi ele almadan ne zaman konuşabileceğimizi merak ediyorum
LLM birçok açıdan yararlı, ama insanların tüm kaynak kodu yazımını ajanlara devrettiğini görmek
web iyi olduğu için mutlu olmamız gerektiğinin söylenmesine benzer bir his veriyor
Kod tabanını sürekli birkaç modele verip yinelenen kod gibi kötü kokuları bulduruyorum
Oldukça etkili oldu; zamanla sürekli bakımı yapılmazsa dağınık bir yığına dönüşüyor ve bunun birikeceğini düşünüyorum
Bunlar build pipeline’a eklenebilir ve hiç token harcamaz
Yoksa inceleme süreci ve bağlamı sıfırlamak mı daha önemli?
İnsanların 20 yıl boyunca bakımını yaptığı kodlarda da bu tür tekrarları ve daha kötü şeyleri çok gördüm
Dürüst olmak gerekirse, çoğu durumda insanlar tarafından yazılıp bakımı yapılan kod, şu anda LLM’lerin ürettiğinden daha kötüydü
Bazen deneyim eksikliğinden, bazen kasıtlı özensizlikten; ama çoğunlukla sıkışık takvimlerden ve hemen bitirme baskısından kaynaklanıyordu
İnsanlar daha iyisini yapmayı biliyor, ama bunu gerçekten yapacak zaman ve bütçeleri yok
LLM de bunu öğrendi