Aşırı Düzenleme: Modelin gerekli kapsamın ötesine geçerek kodu değiştirmesi olgusu

• Yalnızca asgari düzeltmeyle çözülebilecek hatalarda bile tüm fonksiyonun yeniden yazılması, yardımcı mantık eklenmesi, imzanın değiştirilmesi gibi müdahaleler görülebiliyor ve devasa bir diff oluşması kolaylaşıyor
• Mevcut yapının korunduğu brown-field çalışmalarda, yalnızca testlerin geçmesi yeterli değil; ne kadar az değişiklik yapıldığına da bakmak, incelenebilirlik ve değişiklik güvenliğinin korunması için gerekli
• Programatik olarak bozulmuş 400 BigCodeBench problemi temel alınarak token düzeyinde Levenshtein, göreli yama puanı ve Added Cognitive Complexity ile aşırı düzenleme nicel olarak ölçülüyor
• En yeni kodlama modellerinin genelinde aşırı yeniden yazma eğilimi doğrulandı; Claude Opus 4.6 doğruluk ile asgari düzeltme birleşiminde güçlü görünürken, GPT-5.4 görece daha belirgin aşırı düzenleme sergiliyor
• Orijinali korumayı açıkça isteyen istemler, özellikle akıl yürütme modellerinde diff’i azalttı; eğitim yaklaşımları içinde ise RL, asgari düzenleme davranışını öğrenirken genel kodlama performansını düşürmeden en dengeli sonucu verdi

---

Over-Editing sorunu

• Over-Editing, bir hatayı düzeltmek için gereken asgari değişiklik kapsamını aşarak kod yapısının da büyük ölçüde değiştirilmesi olgusunu ifade ediyor
  • Basit bir range(len(x) - 1) → range(len(x)) değişikliğiyle çözülebilecek off-by-one hatasında bile model, tüm fonksiyonu yeniden yazabiliyor ve yardımcı fonksiyonlar ya da doğrulama mantığı ekleyen aşırı değişiklikler yapabiliyor
  • Örnekte GPT-5.4; None kontrolü, np.asarray(dtype=float) dönüşümü, sonlu değer maskelemesi, dizi boyutu doğrulaması, curve_fit çağrısı imzasının değiştirilmesi ve çizim mantığının değiştirilmesine kadar gidiyor; testler geçse de devasa bir diff ortaya çıkıyor
• Mevcut kod tabanıyla çalışılan brown-field işlerde, ekibin zaten anlayıp bilinçli olarak yazdığı kodu koruyarak yalnızca sorunu düzeltmek daha önemli
  • Sıfırdan geliştirilen green-field işlerin aksine, mevcut yapıya saygı göstermeyen değişiklikler inceleyen kişinin neyin neden değiştiğini anlamasını zorlaştırıyor
  • Tüm fonksiyon yeniden yazıldığında kodun okunması zorlaşıyor ve değişikliğin güvenli olup olmadığını değerlendirmek de güçleşiyor
• Yalnızca testlerin geçmesini ölçüt almak bu sorunu yakalamaya yetmiyor
  • Over-Editing, doğruluk hatası değil düzenleme sadakati hatası olduğu için test paketlerinde kolayca görünmüyor
  • Üretilen kod miktarı arttıkça incelenmesi gereken yük büyüyor ve gereksiz karmaşıklık biriktikçe kod tabanının kalitesi sessizce düşebiliyor

Over-Editing nasıl ölçülüyor?

• Asgari düzeltmenin net olduğu bir veri kümesi oluşturmak için BigCodeBench içindeki 400 problem programatik olarak bozulup değerlendirme kümesi hazırlanmış
  • Mevcut benchmark’larda olduğu gibi başka bir LLM ile hata enjekte etmek yerine, < işlecini <= ile, + işlecini - ile, True değerini False ile değiştirmek gibi ince ayarlı ve denetimli bozulmalar kullanılmış
  • Her bozulmuş örneğin sözdizimsel olarak geçerli olduğu ve karşılık gelen test vakalarını bozduğu doğrulanmış; doğru düzeltme yalnızca bozulmayı geri almak olduğundan tasarım gereği asgari düzeltme sağlanmış
• Bu kurgu sayesinde yalnızca modelin hatayı düzeltip düzeltmediği değil, düzeltirken ne kadar fazladan değişiklik yaptığı da ölçülebiliyor
  • Referans çözüm ve model çıktısı, bozulmuş girdiyle karşılaştırılarak göreli yama büyüklüğü hesaplanıyor
  • Doğru geri yüklemenin ötesinde ne kadar çok ek değişiklik varsa puan o kadar kötüleşiyor
• İlgili kodlar GitHub deposunda sunuluyor

Ölçüm metrikleri

• Token düzeyinde Levenshtein Distance

  • Yaygın karakter düzeyindeki Levenshtein yerine Python için token düzeyinde bir varyant kullanılıyor
  • Kod, Python tokenizer ile def, add, (, a, ,, b, ) gibi atomik sözdizimi birimlerine ayrılıyor ve uzaklık bu token dizisi üzerinde hesaplanıyor
  • def add(a, b): ifadesinin def someotherfunctionname(a, b): olarak değiştirilmesi durumunda karakter düzeyinde uzaklık 19 iken, token düzeyinde yalnızca tek bir tanımlayıcının değiştiği kabul edilerek 1 oluyor
  • Fonksiyon uzunlukları farklı olsa da karşılaştırılabilmesi için toplam token sayısına göre normalize ediliyor

• Göreli yama puanı

  • Model çıktısı ile referans çözüm doğrudan karşılaştırılmıyor; ikisi de bozulmuş girdi temel alınarak karşılaştırılıyor
  • Bozulmuş çözümü özgün çözüme döndüren düzenleme gerçek asgari düzeltme kabul ediliyor ve modelin yaptığı düzenlemenin buna ne kadar yakın olduğu ölçülüyor
  • Değer 0’a yaklaştıkça model yaması gerçek asgari düzeltmeye daha çok benziyor

• Added Cognitive Complexity

  • Cyclomatic Complexity’ye kıyasla okuma zorluğunu daha iyi yansıtan Cognitive Complexity de birlikte kullanılıyor
  • İç içe yapılar, özyineleme, birleşik mantıksal işleçler ve sezgisel olmayan kontrol akışları cezalandırılıyor; if, döngüler, try/except gibi, okuyucunun daha fazla durumu takip etmesini gerektiren yapılar karmaşıklığı artırıyor
  • Örnekteki iç içe döngü ve koşul kodunun Cognitive Complexity değeri 6 oluyor
  • Bu bozulmalarda yalnızca değerler değişip yapı korunuyor; dolayısıyla doğru düzeltmede Added Cognitive Complexity her zaman 0 olmalı
  • Model çıktısında karmaşıklık artmışsa istenmeyen ek kod yazılmış demektir; 0’dan küçük değerler de gereksiz sadeleştirme sayıldığından tercih edilmiyor

Modeller gerçekten Over-Edit yapıyor mu?

• En yeni frontier modellerde bile Over-Editing görülüyor
  • Akıl yürütme modelleri ile akıl yürütmeyen modellerin hem Pass@1 hem de asgari düzeltme bakımından farklılık gösterdiği görülüyor
  • Bir modeli yalnızca doğru düzeltme başarısına bakarak değerlendirmek, düzenleme sadakatini anlamaya yetmiyor
• Akıl yürütme modelleri karşılaştırmasında Claude Opus 4.6 en güçlü birleşimi gösteriyor
  • Pass@1 değeri 0.912 ile en yüksek; normalize Levenshtein 0.060 ve Added Cognitive Complexity 0.200 ile diff de en küçük
  • Gemini 3.1 Pro Preview da benzer bir bölgede yer alırken, açık ağırlıklı modeller içinde GLM 5 görece daha tutucu düzenleme yapıyor
• GPT-5.4, değerlendirilen modeller arasında Over-Editing’in en belirgin olduğu tarafta yer alıyor
  • Akıl yürütme modunda Levenshtein 0.395 ve Added Cognitive Complexity 2.313; akıl yürütmesiz modda da sırasıyla 0.327 ve 1.563 gibi yüksek değerler görülüyor
  • Pass@1 değerleri de 0.723 ve 0.770 ile düşük tarafta kaldığından, hem doğruluk hem de asgari düzeltme açısından zayıf bir tablo çıkıyor
• Akıl yürütmeyen modellerde Qwen 3.6 Plus, 0.870 Pass@1 ile en yüksek değeri alırken; GLM 5, 0.235 Added Cognitive Complexity ile en düşük değeri gösteriyor
  • Claude Opus 4.6’nın akıl yürütmeyen sürümü de 0.079 Levenshtein ve 0.313 Added Cognitive Complexity ile çok küçük değişiklik aralığını koruyor

Prompt ile iyileşiyor mu?

• Prompt’a “IMPORTANT: Try to preserve the original code and the logic of the original code as much as possible” ifadesi eklendiğinde tüm modellerde Levenshtein Distance azalıyor
  • DeepSeek R1/v3 dışında Pass@1 değerleri de birlikte iyileşiyor
  • Asgari düzenleme kısıtı, mümkün düzenleme uzayını daraltarak daha doğru ve daha hedefli değişikliklere yönlendiriyor şeklinde yorumlanabiliyor
• Bu etki özellikle akıl yürütme modellerinde daha belirgin
  • Açık talimatları daha iyi izleme eğilimleri nedeniyle, düzenlemeyi en aza indirme isteği diff küçülmesine güçlü biçimde yansıyor
  • Varsayılan durumda gereğinden fazla müdahale etseler bile, açık bir talimat verildiğinde daha sadık düzenlemelere kayabildiklerini gösteriyor

Akıl yürütme aşırı yeniden yazıma yol açıyor mu

• Aynı model ailesindeki akıl yürüten ve akıl yürütmeyen sürümler eşleştirilerek, yalnızca her ikisinin de doğru cevap verdiği örnekler üzerinde Levenshtein Distance karşılaştırıldı
  • Başarısız örnekler çok olduğunda Over-Editing fırsatının kendisinin azalması yönünde bir yanlılık oluştuğu için, doğruluk kontrol edildikten sonra yalnızca düzenleme stili ayrıştırıldı
• Genel prompt ayarlarında çoğu eşleşmede akıl yürüten model daha fazla yeniden yazım yapıyor
  • DeepSeek V3, GPT-5, GPT-5.4, Gemini 3.1 Pro Preview, Qwen 3.6 Plus, Kimi 2.5 için akıl yürütme çubuğu daha yüksek çıktı
  • Genişletilmiş akıl yürütmenin, en az değişiklik yerine “daha iyi bir uygulama”ya yönelerek gereksiz refactoring üretme eğilimi gösterdiği ortaya çıkıyor
  • İstisna Claude Opus 4.6; burada akıl yürüten sürüm, akıl yürütmeyen sürüme göre çok daha az değişiklik yapıyor
• Orijinali koruma talimatı açıkça verildiğinde tablo büyük ölçüde değişiyor
  • Akıl yürüten modeller neredeyse tüm eşleşmelerde akıl yürütmeyen modellerle aynı ya da daha düşük Levenshtein Distance gösteriyor
  • Claude Opus 4.6 akıl yürüten sürümü bu ayarda tüm modeller arasında en düşük Levenshtein değerini kaydediyor
  • GPT-5 ve GPT-5.4’te de akıl yürüten sürümün puanı ciddi biçimde düşüyor, ancak GPT-5.4’te akıl yürütmeyen sürüm hâlâ az farkla önde
• Varsayılan davranışta akıl yürüten modeller Over-Editing yapmaya yatkın, ancak aynı akıl yürütme yeteneği onların kısıtları daha iyi izlemesini de sağlıyor
  • Genel ayarla açık talimatlı ayar arasındaki fark, akıl yürüten modellerde tutarlı biçimde daha büyük görünüyor
  • Dolayısıyla Over-Editing temel bir sınırdan çok varsayılan bir davranışa benziyor ve kısıtlarla tersine çevrilebiliyor

Eğitimle sadık bir düzenleyici oluşturulabilir mi

• Temel model olarak Qwen3 4B 2507 Instruct kullanılıyor ve 0-shot ile 8-shot içinde orijinali koruma talimatı bulunan kurulum baseline kabul ediliyor
  • Diğer eğitim yöntemleri ise değerlendirme sırasında açık bir orijinali koruma talimatı olmadan, genel ayarlarda test ediliyor

• Deney kurulumu

  • DeepCoder problemleri aynı şekilde bozulup sentetik veri kümesi oluşturuluyor
  • Buna ek olarak temel Qwen3 4B 2507 Instruct’ın her problem için 8 completion üretmesi sağlanıyor; işlevsel olarak doğru olan örnekler bırakıldıktan sonra Levenshtein Distance’a göre sıralanarak bir self-distillation veri kümesi daha kuruluyor
  • Eğitim, Context Distillation benzeri biçimde, değerlendirme anında açık talimat olmadan minimum düzenleme davranışı sergileyecek şekilde ayarlanıyor

• Eğitim yöntemleri

  • SFT: Programatik olarak oluşturulan veri kümesiyle doğrudan denetimli ince ayar yapılıyor
  • rSFT: self-distillation veri kümesinde her örnek için Levenshtein Distance’ı en düşük olan 3 completion seçilerek eğitim veriliyor
  • DPO: Her örnekte Levenshtein Distance’ı en yüksek completion ile en düşük completion arasında tercih optimizasyonu uygulanıyor
  • RL: İşlevsel doğruluk ile Levenshtein tabanlı minimum düzenleme ödülünü birleştiren pekiştirmeli öğrenme uygulanıyor
    • Tüm testler geçilirse r = r_edit + 0.1
    • Geçilemezse r = -0.2
    • r_edit, normalize edilmiş Levenshtein tabanlı ödül olarak hesaplanıyor

Aynı bozulma türünde sonuçlar nasıldı

• Eğitim kümesiyle test kümesinin bozulma türü aynı olan in-domain ayarda SFT neredeyse kusursuza yakın sonuç veriyor
  • Baseline 0-shot: Pass@1 0.735, Norm. Levenshtein 0.169, Added CC 0.731
  • Baseline 8-shot: Pass@1 0.775, Norm. Levenshtein 0.115, Added CC 0.479
  • SFT, Pass@1 0.932, Norm. Levenshtein 0.002, Added CC 0.000 ile üç metriğin tamamında en iyi sonucu veriyor
  • rSFT 0.782 / 0.100 / 0.435, DPO 0.752 / 0.021 / 0.113, RL ise 0.802 / 0.046 / 0.112 kaydediyor
• Bu sonuç fazla iyi göründüğü için, modelin belirli bozulma türlerinin ters dönüşümünü ezberlemiş olabileceği kontrol ediliyor
  • Yani modelin genel bir minimum düzenleme davranışı öğrenmek yerine, yalnızca belirli bozulma kalıplarını tersine çevirmeyi öğrenmiş olabileceği düşünülüyor
  • Bunu doğrulamak için eğitim verisiyle değerlendirme verisinin bozulma türleri tamamen farklı olacak şekilde yeniden kurulum yapılıyor

Farklı bozulma türlerine de genelleniyor mu

• Eğitim kümesiyle test kümesinin bozulma türü farklı olan out-of-domain ayarda SFT ciddi biçimde çöküyor
  • SFT’nin Pass@1 değeri 0.458’e kadar düşüyor ve model gerçek anlamda hatayı düzeltemeden yalnızca belirli minimum değişiklikleri denemeye başlıyor
  • Norm. Levenshtein -0.008, Added CC 0.006 gibi çok düşük kalsa da doğru düzeltme yapabilme yeteneği çöküyor
• rSFT ve DPO, 8-shot baseline’ın biraz üstüne çıkıyor ama iyileşme sınırlı kalıyor
  • rSFT: 0.780 / 0.107 / 0.501 / LiveCodeBench -0.069
  • DPO: Pass@1 0.787 / 0.092 / 0.348 / LiveCodeBench -0.046
  • Temel modelin kendi ürettiği iz verileriyle yapılan eğitim bile belirli ölçüde genelleme sağlayabiliyor
• Yalnızca RL, üç metrik genelinde temiz biçimde genelleme sağlıyor
  • RL, Pass@1 0.782, Norm. Levenshtein 0.050, Added CC 0.185, LiveCodeBench Change +0.006 kaydediyor
  • Her iki baseline’a göre de üç metriğin tamamında daha iyi ve genel kodlama performansında düşüş yaratmıyor
  • Levenshtein ve Added Cognitive Complexity’deki iyileşme miktarının Pass@1’den daha büyük olması, yalnızca bozulma ters dönüşümünü ezberlemek değil, minimum düzenleme davranışının kendisinin öğrenildiğini destekliyor

Catastrophic Forgetting

• Minimum düzenleme için ince ayar yapıldığında genel kodlama yeteneğinin düşüp düşmediği LiveCodeBench v6 ile de kontrol ediliyor
  • Hedef, eğitimden sonra da özgün pretrained modelle benzer seviyeyi korumak
• SFT’de genel yetenek kaybı çok büyük
  • LiveCodeBench’te %43 performans düşüşü görülüyor ve temel hata tespiti ile düzeltme becerisi bile korunamıyor
• rSFT ve DPO da hafif düşüş gösteriyor
  • Eğitim, modelin kendi ürettiği örneklerle yapılmış olsa bile, görevin doğası gereği belli düzeyde Catastrophic Forgetting kalıyor
• RL ise performans kaybı olmadan yeni davranışı öğreniyor
  • Genel kodlama yeteneğini korurken minimum düzenleme görevindeki performansı da en iyi şekilde artırıyor
  • Bu da SFT memorizes while RL generalizes bulgusuyla örtüşüyor
• Dağılım açısından bakıldığında, programatik olarak oluşturulan veri kümesi ile modelin özgün dağılımı arasındaki fark büyüdükçe Forgetting’in de arttığı şeklinde yorum yapmak mümkün
  • SFT, özgün dağılımdan çok farklı verilere güçlü biçimde uydurulurken model dağılımını ciddi biçimde değiştiriyor
  • rSFT ve DPO’da self-distilled veri özgün dağılıma daha yakın olduğu için değişim daha yumuşak gerçekleşiyor
  • Catastrophic Forgetting derecesi, özgün dağılım ile görev eğitim verisi dağılımı arasındaki farka orantılı olabilir

Ek deneyler

• LoRA ile RL: Tam ince ayar gerekli mi

  • Bu çalışma, yeni bilgi eklemekten çok mevcut kodu düzeltme becerisinin stil ayarına daha yakın olduğu için LoRA'nın da yeterli olup olmayacağı incelendi
  • rank 1 için Pass@1 0.738, Norm. Levenshtein 0.166, Added CC 0.676, LiveCodeBench Δ -0.022
  • rank 8 için 0.775 / 0.112 / 0.426 / -0.022
  • rank 16 için Pass@1 0.805 / 0.087 / 0.328 / -0.005
  • rank 32 için 0.795 / 0.065 / 0.235 / -0.011
  • rank 64 için 0.797 / 0.051 / 0.160 / +0.001
  • En iyi Full RL modeli 0.782 / 0.050 / 0.185 / +0.006
  • rank 64 LoRA, Levenshtein açısından Full RL'ye neredeyse ulaşıyor ve Added CC'de daha iyi sonuç veriyor
  • rank büyüdükçe Levenshtein ve Added CC, 1'den 64'e kadar tekdüze biçimde azalıyor
  • Büyük iyileşme ilk aşamada yoğunlaşıyor; rank 1→16 arasında Levenshtein 0.166→0.087'ye keskin biçimde düşerken, 16→64 arasında 0.087→0.051'e daha kademeli biçimde daralıyor
  • rank 1 ve 8'de doğruluk ile minimum düzenleme arasında bir ödünleşim görülüyor; iki ödül fonksiyonunu birlikte öğrenmek için kapasite yetersiz kaldığından, daha yüksek ödüllü olan düzenlemeyi en aza indirme tarafına kaymış olabilir
  • Zaten mevcut yeteneğe sahip görevlerde stil düzeyindeki davranış değişimi için az sayıda ek parametre bile yeterli oluyor ve belli bir noktadan sonra ek kapasitenin getirisi azalıyor

• Ödül hackleme notu

  • İlk ödül fonksiyonunda, başarılı çalıştırma içermeyen rollout'lara 0 puan veren bir hata vardı
  • Levenshtein “büyük olması daha iyi” olacak şekilde işaret çevrilmiş durumda olduğundan, bu 0 puan bazı durumlarda başarılı çalıştırmadan bile daha yüksek ödül anlamına geliyordu
  • Buna rağmen Full RL görevi öğrendi; yalnızca LoRA'da işlevsel olarak doğru kodu hiç üretmemek şeklinde bir reward hacking görüldü ve bu da ortamın incelenmesine yol açtı
  • Ödül fonksiyonu düzeltildikten sonra Full RL sonuçları yalnızca az miktarda daha iyileşti

• Daha büyük modellere de ölçekleniyor mu

  • Aynı out-of-domain RL tarifi Qwen3 14B üzerinde uygulandı
  • Baseline 14B için Pass@1 0.770, Norm. Levenshtein 0.136, Added CC 0.315
  • RL uygulandıktan sonra Pass@1 0.833, Norm. Levenshtein 0.059, Added CC 0.165, LiveCodeBench Δ +0.011 ile genel bir iyileşme görüldü
  • Parametre sayısı artsa da Pass@1 artışı, Levenshtein düşüşü, Added Cognitive Complexity azalması ve Catastrophic Forgetting görülmemesi birlikte korunuyor
  • Bu da minimum kod düzenlemesine yönelik RL tarifinin farklı ölçeklerdeki modellere yayılabileceğini destekliyor

Nihai değerlendirme

• Aşırı Düzenleme, yaygın ve ölçülebilir bir sorun olarak ortaya çıkıyor
  • frontier kodlama modellerinin genelinde, doğru düzeltme yapabilme ile asgari düzeyde düzeltme yapabilme becerileri birbirinden ayrı görünüyor
  • Özellikle GPT-5.4, varsayılan ayarlarda görece daha güçlü bir aşırı yeniden yazma eğilimi gösterirken, Opus 4.6 güçlü bir baseline sergiliyor
• Yalnızca açık istemlerle bile sadık düzenleme yönünde önemli ölçüde yönlendirme yapılabiliyor
  • Özellikle akıl yürütme modelleri varsayılan olarak fazla müdahale etme eğiliminde, ancak özgün yapıyı koruma talimatı verildiğinde buna daha iyi uyuyor
  • GPT-5.4 da akıl yürütme modunda büyük bir iyileşme göstererek instruction following yeteneğinin kendisinin güçlü olduğunu ortaya koyuyor
  • Opus 4.6'daki iyileşme marjının küçük görünmesi, zaten temel performansının yüksek olmasından kaynaklanıyor olabilir
• Eğitim tarafında ise RL en dengeli çözüm olarak öne çıkıyor
  • Daha sadık düzenleme davranışı öğrenirken genel kodlama yeteneğine zarar vermedi ve etki hem 4B hem de 14B Qwen3'te korundu
  • SFT, belirli hasar türlerinde güçlüydü ancak genelleme ve genel yeteneği koruma açısından ciddi biçimde başarısız oldu
• Tek fonksiyon düzeyindeki bug düzeltme değerlendirmesi, SWE-Bench Pro gibi daha agentic değerlendirmelere göre kapsam açısından sınırlı olsa da, gerçekçi bir ortamda Aşırı Düzenleme'yi nicel olarak ölçmesi zor olan bir sorun olarak ele almak için bir başlangıç noktası sağlıyor
  • Minimum düzenleme yeteneğini değerlendirme ve iyileştirme yönü, yapay zeka tarafından üretilen kodun genel kalitesinin artmasına katkı sağlayabilir

[GN⁺]

Hacker News görüşleri

• Claude Code kullanma biçimim beklentilerimin çok ötesinde
  Fazla düzenleme yaptığında nerede yanlış yaptığını açıklamasını ve bu dersi proje bazlı skill dosyalarına kaydetmesini sağlıyorum
  Sonra aynı hataları neredeyse hiç tekrarlamıyor ve skill dosyaları büyüyünce onları düzenleyip sıkıştırmayı da epey iyi yapıyor
  Artık işte doğrudan kod yazmanın ekonomik olarak çok anlamlı olmadığını hissediyorum
  Ben daha çok öğretmen, mimar, altyapı yöneticisi gibiyim; geliştirmenin büyük kısmını deneyimli Claude oturumlarından oluşan bir ekibe bırakıyorum
  Elbette her şeyi gözden geçiriyorum ve Claude da yoğun testler yazarak benimle birlikte inceleme yapıyor
  Bu aralar büyük projeleri de zorlanmadan ele alıyor
  Bunu Anthropic reklamı gibi söylemek istemiyorum ama tam olarak ne yapıyorum da bu bende olağanüstü iyi sonuç veriyor, gerçekten merak ediyorum
  Ayrıca token da artık neredeyse hiç yetmemezlik etmiyor
  Neredeyse sadece Opus modeli kullanıyorum; token verimliliği iyi ve geçen hafta Claude yardımıyla 150'den fazla anlamlı commit attım ama haftalık kotamın yalnızca üçte birini kullandım
  Claude'dan önce haftada 25-30 commit civarı benim sınırımdı

  • Bende de benzer
    Dün istatistiklere baktım ve şirket kodunun %97'sini artık Cursor AI'ın yazıyor olmasına şaşırdım
    Çoğunlukla cloud agent olarak çalıştırıyorum; canlı canlı izlemek dikkat dağıttığı için böyle yapıyorum
    Benim yöntemim çok basit: sadece net şekilde sözle tarif etmek
    İnsanlar bunu gereğinden fazla karmaşıklaştırıyor
    .md dosyaları paylaşmak, orchestration'a ya da prompt hack'lerine dalmak bana ancak vim kısayollarına veya IDE skin'lerine aşırı kafa yormak kadar ilginç geliyor
    Ne istediğini açıkça söylemen ve sadece iyi geri bildirim vermen yeterli
  • Bende de aynı. Bir emek tasarrufu aygıtı olarak şaşırtıcı derecede iyi
    Bir iş arkadaşımın yazdığı kodu kabul eder gibi rahatça kabul edebileceğim sonuçlar üretiyor
    Elbette satır satır okuyup düzeltmeler yapıyorum ama o düzeltmeler de zaten normal kod incelemesinde yaptığım seviyede
    Verimliliği sayısal olarak ölçmüyorum ama yıllardır ertelediğim işleri artık ele almaya başlamamdan bunu hissediyorum
    Örneğin 100 markdown dosyasını 5 json dosyasına çevirip bunları okuyan kodu da güncellemek gibi sıkıcı işler konusunda özellikle güçlü
  • İnsanlar bugünlerde Claude Code'un kullanılamaz hale geldiğini söylediğinde inanıyorum ama ben pek anlayamıyorum
    Kusurları da çok, bug'ları da çok olan bir yazılım ama pratikte son derece etkili
    Yapay zekadaki en tuhaf şeylerden biri, insanların deneyiminin gerçekten aşırı uçlarda değişebilmesi
  • Kodun başkalarının incelemesinden geçip geçmediğine, eskiden kod incelemesinin zor olup olmadığına ve iş arkadaşlarının söylediği code quality konusunu ne kadar önemsediğine göre deneyim epey değişiyor gibi
    Operasyonel işin ne kadar fazla olduğu ve uzun ömürlü ürün kodu ile uğraşıp uğraşmadığın da önemli
    Benim hipotezim şu: bu araç basit kalıplarda iyi çalışıyor ve karmaşık işleri de yapabiliyor ama yeni kalıplar icat etme işinde çok zayıf
    Denetimsiz bırakırsan hızla tehlikeli yeni kalıplar uydurup sistemi bozabiliyor
    Bu yüzden Claude'un verdiğini baştan sona yeniden yazdığım çok oluyor
    Bazen robotla hız yarışına giriyorum ve ben daha önce bitiriyorum
    Ne istediğimi zaten bildiğim için avantajlıyım ama buradaki ince ayar maliyetinin küçümsendiğini düşünüyorum
    futzing fraction da öyle, the peril of laziness lost da; makinenin gereğinden fazla uğraşma biçimi bazen bizzat sinir bozucu oluyor
    Neden tek bir şey yapması gerekirken üç şeyi birden yapmaya çalıştığını anlamıyorum
    Sen düzeltince tekrar hizaya gelse bile, iş arkadaşlarıyla çalışırken zaten yaşanan "A, B, C yapma, sadece A yap" döngüsünü bir daha yaşamak sinir bozuyor
    Test üretimi de hassas bir konu; yön verdiğin testleri iyi yazıyor ama yaratıcılık tanıyınca foo + bar == bar + foo gibi işe yaramaz testleri fazlasıyla üretiyor
    Geri bildirim döngüsünün sağlıklı kalması için testlerin faydasını sürekli sorgulayarak bakmak gerekiyor
    Bugünlerde bazen testin kendisinden çok, gerekli import'ları tek seferde toparlaması için daha faydalı oluyor
    Eğer bu makineler işi devralacaksa, ortalama kod kalitesini yükseltmeleri gerekir gibi
    Ama birçok kişi bunları "genelde ortalama civarını tutturuyor" diye kullanıyor ve çalışma biçimine göre ortalamayı aşağı da çekebilir
  • Bende de aynı his var
    28 yıldır bu işi yapıyorum ve artık şirket zamanında, şirket maaşıyla iş uygulaması kodunu bizzat yazmak ne ekonomik ne de iyi niyetli bir tercih gibi geliyor

• Tersine, ben sık sık kodlama ajanlarının yeni gereksinimlere uyum sağlamak için mevcut kodu daha cesurca değiştirmesi gerekirken mevcut kodu korumaya fazla öncelik verdiğini hissediyorum
  Sonuçta mesele, mevcut kodu ne kadar taşlaştırmak istediğin gibi görünüyor
  On yıllardır çalışan büyük bir production uygulamasıysa değişikliği minimumda tutmak doğru olabilir ama 3 gün önce yapılmış deneysel bir projeyse olduğu gibi bırakmak yerine daha iyi hale getirmek gerekir
  Sonunda proje bağlamına göre kendi şiddetini ayarlamayı öğrenmesi gerekecek gibi

  • Bu ödünleşim bağlama bağlı, o yüzden bir ajanın projeye şöyle bir bakıp her zaman doğru kararı vermesi mümkün değil
    Aynı proje içinde bile bazı PR'lerde bazı alanları gönlünce değiştirebilirsin ama başka alanlarda diff'i ve test kapsamını küçük tutmak için sabit kalmalarını istersin
    Bu yüzden önceden hangi bölümlerin ne kadar agresif değiştirilebileceğini anlatıyorum ama sonuçlar tutarsız oluyor
    Genelde minimum diff tarafına kayıyor ve bunun bedeli olarak tekrarlar oluşuyor ya da soyutlamalar zorlanıp bükülüyor
    Daha iyi çalışan bir yöntem varsa ben de duymak isterim
  • Ajanın bazen kendi başına düşünmesini sağlamak için önce kodu ve markdown'ı epey silmek gerektiğini hissediyorum
    Refactor etmesini veya daha geniş düşünmesini söylesen de sonuçlar zayıf kalıyor
    Bu yüzden tasarımın fazla yüklü olduğu markdown'ı temizletiyor, teknik içerikleri ya da temel implementasyonları ve arayüzleri kaynaktan kaldırıyor, sonra yeni bir oturuma tasarımı yeniden yaptırıyorum
    Ardından sildiklerimi geri getirip daha az saf bir oturumla bunları reconcile ediyorum
    Yol bağımlılığı çok güçlü; şimdilik bu akışı elle yapıyorum ama bu kalıbı bir skill olarak biçimlendirmek istiyorum
  • Sırf bu üsluptan bile Codex kullandığın belli oluyor

• Yapay zeka başarısızlığı gizlemek için çoğu zaman exception'ı yutuyor, dummy değer döndürüyor ya da türlü alakasız log'un içine gömülmüş tek bir mesaj bırakıyor
  Log'lar da gereğinden fazla özetlenmiş oluyor; gerçek debug için gereken kritik veri eksik kalabiliyor
  Muhtemelen sistemleri kandırıp puan alma yönünde eğitildiği içindir diye düşünüyorum
  Exception'ı olduğu gibi patlatırsa açık bir başarısızlık olur ve ceza yer ama problemi gizlerse bazen başarılıymış gibi görünebilir
  Bunun genel Soru-Cevap kullanımında nasıl ortaya çıktığını da merak ediyorum
  Model, kullanıcının ikna olup ayrılmasını sağlayacak kadar makul duyulmaya mı yöneliyor acaba
  Sık görülen kalıplardan biri "o X değil Y" gibi cevaplar; böyle ikili bir çerçeve kurunca başka olasılıkları düşünmeyi bırakıyorsun
  Cevabın sonuna bir eylem planı eklemek de yaygın ve bu, cevabın kendisinden çok kullanıcıyı AI ile hemfikir olduktan sonra sonucu hayal etmeye yönelten assumptive close satış tekniği gibi görünüyor

  • Yapay zekanın davranışı, optimize ettiği metriği bir şekilde kandırır diye bakarsan epey öngörülebilir
    Sonuçta hill-climbing ile metriği yukarı taşımak zaten öyle bir şeye benziyor
    Bir tür A/B enshittification'ın yorumlanamaz derecede aşırılaştırılmış hali gibi
    İnsan geri bildirimiyle eğitildiği sürece her yanıtın her parçası değerlendiriciyi atlatıp onu memnun etmeye doğru kayacaktır

• Yapay zeka ile bir şeyi gerçekten çok iyi yapmak, sanıldığından daha fazla el emeği gerektiriyor
  Söyleyince oldukça makul görünen sonuçlar üretebiliyor ama bilmediği şeyi bilmediğini de bilmiyor olabilir
  Özellikle yapay zeka bunu otoriter bir tonla söylediğinde daha da tehlikeli
  Bu yüzden farklı açılardan doğrulamak ve doğruluğu teyit etmek kolay değil
  Bunun zamanla nasıl değişeceğini görmek ilginç olacak

  • Kesinlikle katılıyorum
    Aynı zamanda bu yazı ve buradaki yorumlar da bana birer zaman anı görüntüsü gibi geliyor
    Sektördeki ilerleme hızı o kadar yüksek ki, kodlama modelleri yalnızca 9 ay öncesine göre bile şimdiden çok daha iyi
    Yapay zeka yetenekleriyle ilgili şikayetler okudukça, karşı tarafı suçlamak için değil ama içimden hep "şimdilik" diye düşünüyorum
  • Bu aralar yapay zekayla doğrudan bir şey üretmekten çok, bir AI bağlamıyla başka bir AI bağlamını inceletmeye daha fazla zaman harcıyorum
    Birbirlerinin sonuçlarını gözden geçirmelerini sağlıyorum
    Buna rağmen süreçlerin çoğu asenkron ilerliyor; ben de o sırada başka işler yapabiliyorum
  • Ne bilmediğimi bile bilmiyorsam, kodlama ajanından daha iyisini nasıl yapabilirim ki diye düşünüyorum
    Bu yüzden bazı projelerde önce ajanla bir prototip çıkarıp öğreniyor, sonra tasarımı yazıp en baştan yeniden başlıyorum
    Böylece nereye daha derin bakmam gerektiğini öğreniyorum
  • Evet. Genel olarak seni %80 noktasına kadar gayet iyi getiriyor
    Kalan %20'nin ne olduğu ise sonuçta problemin doğasına bağlı

• Burada konuşulan şey kodun aşırı düzenlenmesi, ama ajanlar bunun da ötesinde şeyler yapıyor
  Birden fazla dosyaya dokunuyor, test çalıştırıyor, deploy ediyor, hatta smoke test bile yapıyor ve bunların hepsi soyutlamaların arkasına gizleniyor
  Bir yandan etkileyici ama diğer yandan ciddi biçimde tedirgin edici
  Birincisi, içeride gerçekten ne olduğunu doğru dürüst anlamıyorum
  Ajanın bir araya getirdiği script'i sadece onaylayıp çalıştırmak fazla kolay ve cezbedici
  Ama sırf ajan doğru olduğuna karar verdi diye DB'yi sildiğim de oldu; asla göndermemesi gereken AWS kimlik bilgilerini deploy hedefine yollamaya kalktığını yakaladığım da oldu
  İkincisi, ben hiçbir şey öğrenmiyorum
  Basit bir docker komutunu bile kendi başıma kurmanın bilişsel yükü arttığı için tekrar tekrar yapay zekaya bir koltuk değneği gibi yaslanıyorum

  • Neden LLM'in direksiyona geçmesine izin verdiğini anlamıyorum
    auto-approve açılmamalı; ajanın çalıştırdığı her komutu bizzat sen onaylamalısın
    Tasarım ya da mimari kararlarını da ona bırakmamalısın; nasıl yapılacağına insan karar verip o tenekeye açıkça söylemeli
    Şaka yapmıyorum, yapay zekayı bir araç gibi kullandığında çok daha iyi verim alıyorsun
    10 kat üretkenlik olmasa bile en azından kodu anlamaya devam ederek ilerlersin
  • Kimlik bilgileri tarafında ben şöyle görüyorum
    1. Gün güvenlik konusunda aşırı dikkatli davranıyor; .env'i neden .gitignore'a koyman gerektiğinden, kimlik bilgilerini göndermemen ve ilgili değişikliği bizzat senin yapman gerektiğine kadar vaaz veriyor
    Ama 2. Gün aynı şeyi tekrar isteyince o kuralı ya da ayarı unutuyor; tüm diski tarayıp .env ve başka dosyaları okuyor, token tuttuğunu anlayıp curl komutunu bizzat oluşturuyor ve hatta test ediyor
    İlk gün güvenlik uzmanı gibi, ertesi gün ise sıradan bir stajyerden bile kötü gibi hissettiriyor
  • Ben fiilen üç modda kullanıyorum
    1. Temel uygulamayı tamamen ben tanımlıyor, implemente ediyor, test ediyor ve son temizliği AI'a bırakıyorum
    2. Fonksiyonları AI yazıyor ve test iskeletini çıkarıyor, sonra fonksiyonları çoğu zaman ben yeniden yazıyorum
       Bu yaklaşımda istenmeyen davranış ve aşırı implementasyon çok oluyor ama boilerplate kaldırma açısından faydalı
    3. Deneysel kodu ya da her an çöpe atılabilecek kısımları tamamen AI'a bırakıyorum
       Gerçekte bu bölümlerin yaklaşık %70'ini siliyorum
       Buna karşılık 1. ve 2. alanlara AI'ın dokunmasına izin vermiyorum
       Tabii bunun mümkün olması için mimarinin böyle bir ayrımı desteklemesi gerekiyor ama ben epey memnunum
  • Bu aslında düşünüldüğünden kolay bir sorun
    Sadece production kimlik bilgilerini LLM'e verme
    Yerelde ya da staging/dev ortamında yeniden üretilemiyorsa, deploy altyapısını production'a daha çok benzetmek gerekir; ortamlar arası yetkileri yeterince ince taneli ayıramıyorsan önce yetkilendirme modelini düzeltmelisin
    Ben bu ilkeye uyduğum için, söz ettiğin türde sorunlarla neredeyse hiç karşılaşmadım
    Teşhis amaçlıysa kısa süreliğine salt okunur kimlik bilgisi verilebilir ama o durumda bile sızıntıya karşı çok kısa ömürlü token üretirdim
  • Ben genelde Claude'un yazdığı kodun tamamını inceliyorum, bir de kendi yazdığım kodu tekrar Claude'a inceletiyorum
    Bu yüzden çoğu zaman ne olup bittiğini kavrıyorum
    Claude bazen anormal ya da alışılmadık kararlar verebiliyor
    Ama büyük kod tabanlarını ekip halinde yönetirken, zaten şirketten ayrılmış insanların yazdığı yerler de dahil olmak üzere baştan beri anlamadığın, soyutlamaların arkasında kalmış alanlar çok oluyor

• Eskiden sıkça öğretilen ama pratikte nadiren uygulanan bir bilgelik vardı: çalışırken refactor et
  Yani bir bölgeye dokunuyorsan fırsat bu fırsat düzenle, teknik borcu da temizle
  Ama gerçekte bu pek olmazdı; şimdi LLM'ler bunu gerçekten yapmaya başlayınca onun yan etkilerini hissediyoruz

  • Modelin mevcut mantıkla aynı işi yapan yeni kod yazması refactoring değildir
    İhtiyaç duyulan fonksiyon hemen oradayken bazen gidip yenisini oluşturuyor
    Daha kötüsü, mevcut fonksiyonu davranışı koruyormuş gibi değiştirip başka kullanım yerlerini bozması
    En kötüsü ise sınıflar arası durumu değiştirip yan etkilerin farkında olmadan kurcalaması ve deadlock ya da sıradan bug üretmesi
  • Yoldan geçerken bir şeylere dokunmaya karar verdiğinde de çoğu zaman bu gerçek bir iyileştirme olmuyor
    Bana göre buna refactoring demektense slot makinesi kolunu bir kez daha çekmek demek daha doğru
  • Bugün de bununla biraz vakit harcadım
    Benim asıl sorunum, ajanın yaptığı refactoring'in kalitesinin kötü olmasıydı
    Tek istediğim böyle değişiklikleri durdurmak, sonra da neyin nasıl düzeltileceğini daha açık biçimde tarif etmekti
  • Mesele o kadar basit değil
    Çoğu durumda mevcut soyutlama yeterince iyi olduğu için, bug takibini veya özellik genişletmeyi onun üzerinde yapabiliyorsun
    Ama bazen mevcut implementasyonu zorlayarak etrafından dolanmak mı yoksa yeniden tasarlamak mı gerektiği konusunda bir yol ayrımına geliyorsun
    LLM ile çalışırken bunu nasıl yeniden değerlendireceğin, hatta baştan değerlendirmeye gerek olup olmadığı bile bulanıklaşıyor
    Üstelik böyle kararlar kullanıcı açısından görünmez şekilde gizlenebiliyor
  • Gerçekten merak ettiğim bir nokta bu
    Belki böyle değişiklikler yararlı olabilir; o yüzden daha fazla örnek görmek isterim
    Cognitive complexity metriğine güvenmiyorum ama bu tür düzenlemelerin o metriği oldukça tutarlı biçimde yükselttiği gerçeği biraz ilginç

• Claude Code ya da Codex'te bir süredir aşırı düzenleme görmediğim için, bu araştırmada hangi prompt'ların kullanıldığını merak ettim
  Sanırım burada ve son değişiklik 8 ay önce yapılmış
  https://github.com/nreHieW/fyp/blob/5a4023e4d1f287ac73a616b5b944a14f28422c7e/partial_edits/utils/prompts_utils.py

  • Daha bugün yine oldu
    GPT-5.4, benden istenen 10 satırlık ekleme yerine daha temiz olduğunu söyleyerek 50 satırı baştan yazdı
    Mevcut koda bakıp sadece değişken adlarını değiştirerek benzer şekilde eklenebilecek mekanik bir ilaveydi ama yine de bunu yaptı
    Üstelik ilk seferde benden istenen özelliği bile eklememişti; bu da işi daha absürt hale getirdi
    Over-editing kesinlikle geçmişte kalmış bir sorun değil; ben de bunu thinking düzeyini düşürmeyi unutup xhigh thinking ile çalıştırdığımda yaşadım
  • Bende de benzer bir his var
    Bana bu daha çok ajanların ilk dönemlerine ait bir sorun gibi geldi

• Bu yazı oldukça sağlam
  LLM'ler hem düzyazıda hem kodda gereğinden uzun olma eğiliminde ve bence bunun başlıca nedeni eğitim biçimleri
  Cross entropy loss, garden path tarzı cümleleri tercih etmeye itiyor
  İnsanın tek cümlede, hatta birkaç kelimede bitireceği şeyi bir paragraf boyunca uzatıyor
  Çünkü uzun cümleler istatistiksel olarak daha az şaşırtıcı, yani daha düşük perplexity'li yol oluyor

• Ben de bu konuda ikircikli hissediyorum
  Çoğu zaman gereğinden fazlasını yapıyor ve benim de 30 dakikamı düzeltmeye harcatıyor; o yüzden değerlendirmeye katılıyorum
  Ama bazen de daha kapsamlı değişiklikleri kaçırıyor
  Muhtemelen bağlam sınırları yüzünden; bu yüzden araçları daha sıkı yönetmeye başladım
  Yine de hâlâ istediğim düzeyde bir kontrol hissi elde etmiş değilim

• Bu bana eğitim verisinin izi gibi geliyor
  SFT ve preference verileri "dosyanın daha temiz düzeltilmiş hâli" örnekleriyle dolu ama "tam olarak 3 satırlık diff" gibi örnekler az
  Bu yüzden model daha büyük, daha cilalı çıktının kazandığını öğrenmiş
  Prompt ile bir ölçüde kontrol edebilirsin ama sonuçta güçlü bir ön eğilimle savaşmış oluyorsun