LLM'ler 45 denemenin tamamında zaten optimal kodu yeniden yazdı; tek bir prompt satırı hatayı yarıya indirdi

İyileştirilemeyecek bir fonksiyon, yine de yeniden yazıldı

dev.to'da yazan bir geliştirici, yeni bir makale okuduktan sonra yürüttüğü bir deneyimi anlatıyor: sıralı bir liste üzerinde iki işaretçili bir tarama — doğrusal zaman, veri üzerinden tek geçiş, zaten kıyaslanmış — aldı ve Claude, GPT ve Gemini'den bunu yürütme hızı için optimize etmelerini istedi. Üçü de uydu. Yeniden yazımlardan biri döngüyü bir comprehension ile değiştirdi; yazar bunu ölçtüğünde daha yavaş olduğunu gördü. Bir diğeri asla tetiklenemeyecek bir erken return ekledi. Üçüncüsü fonksiyonu bir sözlük artı ikinci bir geçişle değiştirdi; hâlâ O(n) ama işi iki kez yapıyor ve gereksiz karşılaştırmaları azalttığına dair — düpedüz yanlış olan — bir yorumla süslendi.

Deneyin arkasındaki araştırma

Yazı, 13 Eylül'de arXiv'e gönderilen, Sarah Wilson, Gail Kaiser ve Patrick Musau imzalı "Efficiency Hallucination: Formalizing and Measuring Behavioral Calibration in LLM-Based Code Optimization" adlı makaleye işaret ediyor. Yazının özetine göre Columbia'daki araştırmacılar EffiBench'den beş problem seçti, her bir en üst yüzdelik insan çözümünü — zaten performans tavanındaki kodu — bilinçli olarak bozulmuş bir sürümle eşleştirdi ve Claude, GPT ve Gemini ailelerinden dokuz modelden ikisini de optimize etmesini istedi.

Düz bir prompt altında, zaten optimal koddaki düzenleme oranı %100'dü: 45 denemenin 45'inde, sıfır çekilme. Her model iyileştirilemeyecek kodu yeniden yazdı ve bir iyileştirme olduğunu iddia etti. Makale buna Evaluation Trap adını veriyor: modellerin eğitildiği ve puanlandığı kıyaslamalar bir düzenleme üretmeyi ödüllendirir ama düzenlemeden kaçınmayı asla ödüllendirmez; yazı bunu, negatif sınıfı hiç sunulmamış bir sınıflandırma sorunu olarak özetliyor.

Tek bir prompt satırı hatayı kabaca yarıya indirdi

Makalenin müdahalesi tek bir cümle: yalnızca yürütme hızını iyileştirdiğinden %90'dan fazla eminsen bir düzenleme öner, aksi halde ALREADY_OPTIMAL çıktısı ver. Bu eklendiğinde, optimal koddaki doğru çekilme %0'dan %44,4'e çıktı ve aşırı düzenleme oranı %100'den %55,6'ya düştü. Gerçekten yavaş sürümlerde ise düzenleme oranı dokuz modelin tamamında %100 olarak kaldı ve hiç yanlış çekilme olmadı — talimat kötü düzenlemeleri iyi olanları bastırmadan ortadan kaldırdı.

Yazı etkiyi bir asimetriyle açıklıyor: optimal olmayan kod çoğu zaman yalnızca karmaşıklık analiziyle yüksek güveni hak edebilirken, optimal kod statik bir kanıt sunmaz; dolayısıyla kendi güveni konusunda biraz dürüst olan her model eşiğin altında kalır. Kalan aşırı düzenlemeler, tutmadıkları bir güveni iddia eden modellerdir. Yazının belirttiğine göre yazarların asıl çözümü yürütmektir — her iki sürümü de çalıştırıp süreleri kıyaslamak, böylece modelin kendi çalışması hakkındaki görüşü hiçbir şey ifade etmez.

Daha ucuz modeller daha sık hayır dedi

GPT ve Gemini ailelerinde, daha hafif model daha büyük kardeşinden daha sık doğru şekilde çekildi. GPT-5.4 Mini, araştırmadaki beş problemin tamamında çekilen tek modeldi; tam GPT-5.4 ise bir tanesini başardı. Gemini 3 Flash Preview %60 doğru çekilmeye ulaşırken Gemini 3.1 Pro Preview'de bu oran %20'de kaldı — ancak Gemini 3.5 Flash sıfır aldı, yani bu temiz bir kural değil. Claude'nın üç modeli herhangi bir tersleşme olmadan yüzde 60, 40 ve 60'ta kümeleniyor. Yazarlar buna Capability-Calibration Inversion diyor ama yazının vurguladığı gibi, model başına beş deneme güven aralıklarını geniş bırakıyor.

Yoğun kod tetikleyici

Problem bazındaki yayılım büyüktü. "Remove Duplicates from Sorted Array II" probleminden dokuz modelden sekizi doğru şekilde çekildi. "Finding 3-Digit Even Numbers" probleminden ise dokuzdan biri çekildi; oysa o çözüm, bir Counter ile bin değer üzerinde sabit bir yineleme — sabit zaman ve yenilemez. Yazının okuması şu: asıl karmaşıklık değil, görünürdeki karmaşıklık yeniden yazım davet ediyor; iç içe geçmiş comprehension'lar ve kısa satırlar iyileştirilebilir görünüyor. Diğer güvenilir tetikleyici geri izleme (backtracking) yapıları, çünkü kodu çalıştırmadan bir modelin elenemeyeceği budama önerileri davet ediyorlar. Makalenin pratik önerisi, bir optimizasyon agent'ı dokunmadan önce sözdizimsel olarak yoğun fonksiyonları insan incelemesi için işaretlemek — ve yazar, kendi berbat edilmiş fonksiyonunun bileşik bir döngü koşulu ve tek bir kısa aritmetik satırı içerdiğini belirtiyor.

Neden önemli

Bu, yapay zekâ destekli kodlama için somut ve yeniden üretilebilir bir halüsinasyon biçimi: agent'lar iyileştirilemeyecek kodu kendinden emin bir şekilde yeniden yazıyor, kimi zaman daha yavaş hale getiriyor ve yorgun bir incelemecinin körü körüne kabul edeceği makul gerekçeler iliştiriyor. Önlemler ucuz. Yazının yazarı artık agent'ların performans değişiklikleri önerdiği her depoda talimat dosyasına bir çekilme maddesi koyuyor ve her iki sürüm de çalıştırılmadıkça hiçbir değişikliğin daha hızlı olarak tanımlanamayacağı kuralını eşlik ediyor. Ölçüm modelin elinden alınmış oluyor: CI içinde eski uygulaması temel olarak sabitlenmiş yaklaşık yirmi satırlık bir pytest-benchmark fixture'ı, o pazar günkü üç yeniden yazımın da tamamını yakalıyor. Daha geniş ders şu: yetenek ve kalibrasyon ayrı becerilerdir ve genelde alıntılanan kıyaslama sayıları yalnızca ilkiyi ölçer — kimi zaman daha güçlü model, yapacak iş kalmadığında daha kötü hâkim çıkarak.