Hashline ve Replace: Düzenleme Biçimi Önemli mi?

içerik

Can Bölük'ün Harness Sorunu başlıklı yazısı, kodlama ajanlarında hashline tarzı düzenlemelerin (satır numarasına dayalı, 4#WB gibi) geleneksel replace modu düzenlemelerinden (old_string/new_string eşleştirmesi) daha iyi sonuç verdiğini gösterdi. Kendi harness sistemimi (tau) geliştirmeye yönelik denemeler yapıyorum ve bu sonucu doğrulamak, ayrıca orada varsayılan düzenleme stratejisi olarak hashline kullanmayı değerlendirmem gerekip gerekmediğini görmek istedim. Bu yüzden bunu birden fazla dil ve modelde kendim test etmek için edit-bench aracını geliştirdim.

Deney Düzeni

edit-bench, mevcut kod tabanlarından mutasyona dayalı testler üretiyor. Bir betiğe bir dizini gösteriyorsunuz; betik de bir deyimi silmek, bir Boolean değerini tersine çevirmek, argümanların yerini değiştirmek gibi mutasyonlar üretiyor.

Diller: Python (kaynak: hive), TypeScript (kaynak: oh-my-pi), Rust (kaynak: irradiate)
Modeller: gpt-4.1-mini, google/gemini-3-flash-preview, qwen/qwen3.5-397b-a17b
Düzenleme modları: replace (old_string/new_string) ile hashline (satır numarasına dayalı) karşılaştırması
Her dil için 20 görev, tek denemelik, tek seferlik çalıştırmalar
Kısa süre önce tau için bulanık eşleştirme de ekledim (kademeli kırpma: trim_end → trim_both → unicode normalization) ve bunun işe yarayıp yaramadığını görmek istedim

Sonuçlar

Replace modu:

Model	Python	TypeScript	Rust
gemini-3-flash	%95	%80	%95
qwen3.5-397b	%90	%85	%85
gpt-4.1-mini	%65	%75	%45

Hashline modu (önceki çalıştırmalardan):

Model	Python	TypeScript	Rust
gemini-3-flash	%70	%85	%90
qwen3.5-397b	%85	%85	%90
gpt-4.1-mini	%50	%70	%55

Hashline, Python'da sonuçları belirgin biçimde kötüleştiriyor; TypeScript ve Rust'ta ise etkisi aşağı yukarı nötr görünüyor. Bu dile bağlılık ilginç — Python'da boşlukların sözdizimsel anlam taşıması, satıra dayalı düzenlemeleri hataya daha açık hâle getiriyor olabilir.

Bulanık Eşleştirme İşe Yarıyor mu?

Görünüşe göre hayır.

tau'nun bulanık eşleştirmede kullandığı kademeli kırpma işleminin replace modu çalıştırmalarında hiç devreye girip girmediğini görmek için iz toplama özelliği ekledim. Toplam 114 başarılı düzenlemede ve 20 başarısız düzenlemede (3 model × 3 dil), bulanık eşleştirme hiç tetiklenmedi.

Başarısız olan 20 düzenlemenin:

1'inde satır sonunda boşluk vardı (teorik olarak düzeltilebilir)
~8'inde old_string içinde satır numaraları vardı (model hatası)
~11'inde tamamen uydurulmuş içerik vardı

Modeller old_string içeriğini doğru ürettiğinde, boşlukları da doğru üretiyor. Yanlış ürettiklerindeyse sonuç tamamen yanlış oluyor — kademeli kırpma işe yaramıyor.

(İz analizi ayrıntıları)

Çıkarımlar

Hashline ile replace arasında net bir kazanan yok. Etki hem dile hem modele bağlı. Python'da hashline daha kötü sonuç veriyor; TypeScript'te etkisi nötr; Rust'ta ise üstünlük belirsiz.
Can'ın sonuçlarını genellemek zor. react-edit-benchmark yalnızca JavaScript kullanıyor ve doğrulama geri bildirimi için bir LSP'den yararlanıyor. Bizim deney düzeneğimiz (LSP yok, birden fazla dil var) farklı bir tablo ortaya koyuyor. Özellikle LSP geri bildirim döngüsü, muhtemelen düzenleme biçiminin etkisini ayırt etmeyi zorlaştırıyor. Modele yeniden denerken dikkate alabileceği tür hataları vermek, düzenleme biçimiyle etkileşime giren kayda değer bir avantaj sağlıyor.
Güncel modellerde bulanık eşleştirmeyi gerektiren bir sorun yok. LLM'ler ya kaynak metni birebir yeniden üretiyor ya da tamamen farklı bir şey uyduruyor. Bulanık eşleştirmenin hedeflediği, yalnızca boşluklarda küçük farkların bulunduğu durumlar pratikte neredeyse hiç yaşanmıyor.
Güncel harness sistemlerinde mevcut nesil modeller için darboğaz düzenleme biçimi değil. Modeller arasındaki fark (gemini-3-flash %90+, gpt-4.1-mini ise %55-65 düzeyinde), düzenleme biçimleri arasındaki farktan çok daha büyük. Düzenleme biçimine kafa yormadan önce model seçimine ve istem mühendisliğine yatırım yapın.

Zorunlu uyarı: n küçük, istatistiksel açıdan titiz bir çalışma değil; buna göre değerlendirin.

Tüm veriler: nwyin/edit-bench, #13 ve #14 numaralı issue'lar.