Eski PHP'nin modernizasyonu üzerine LLM araştırması: modeller onardığından çok daha fazlasını bozuyor

Kurulum

arXiv'e yüklenen ve Hacker News'te ilgi gören bir makale, birçok geliştiricinin tanıdığı bir senaryoyu inceliyor: eski bir dosyayı büyük bir dil modeliyle yapılan sohbete yapıştırmak ve koda güncellenmesini istemek. Yazarlar bu kısayol hakkında net bir soru soruyor — sonuç, kodu olduğu gibi bırakmaktan gerçekten daha mı iyi?

Deneyde beş LLM çalıştırıldı; her birinden WordPress 4.0'dan alınan 100 PHP dosyasını davranışı birebir koruyarak PHP 8.3'e uygun hale getirmesi istendi. Modeller ne çevresel proje bağlamı aldı ne de kodu çalıştırma imkânına sahipti. Üretilen her dosya, 630 gizli davranışsal kontrolün yanı sıra kural tabanlı bir PHP yeniden düzenleme aracı olan Rector'ın belirlediği 511 modernizasyon fırsatına göre puanlandı. Karşılaştırmayı iki referans çerçeveledi: dokunulmamış orijinal dosyalar ve Rector'ın kendi çıktısı.

Sonuçlar

Makaleye göre hiçbir şey yapmamak çoğu zaman daha güçlü bir strateji. Olduğu gibi bırakıldığında 100 dosyanın 83'ü zaten tüm davranış kontrollerini geçiyor. En iyi performansı gösteren LLM ise yalnızca 59 dosyayı tamamen geçer durumda tutabiliyor. Her model daha önce çalışan 32 ila 51 dosyayı bozarken en fazla 10 dosyayı onarıyor; Rector 7 dosyayı bozuyor ve 6 dosyayı onarıyor.

Hasarların büyük bölümü hiçbir amaca hizmet etmiyor. 11 bulgunun yalnızca 37'si — kabaca yüzde 7'si — PHP 8.3'ün gerçekten gerektirdiği değişiklikleri yansıtıyor. Oysa zaten uyumlu olan ve hiçbir değişiklik gerektirmeyen dosyalar arasında LLM'ler bunların yüzde 36 ila 60'ını bozmuş; Rector'ın oranı ise yüzde 8.

İki hedef arasında bir kopukluk da var. En yüksek modernizasyon puanını elde eden model, en yakın rakiplerinden daha uyumlu çıkmadı; bu da agresif güncellemenin davranışsal güvenlikle birlikte ilerlemediğini gösteriyor.

Bozulmaların kaynağı

Başarısız davranış kontrollerinin çoğu, artık hiç yüklenmeyen dosyalara dayanıyor; çoğunlukla nedeni, modellerin PHP'nin kendisinin reddettiği tip bildirimleri üretmesi. Yazarlar, bunlardan kaçınmak için proje bağlamı gerekmeyen hatalar olduğuna dikkat çekiyor: yüklenemeyen bir dosya, dosyanın kendisinden görülebilen bir sorundur. Bir başka deyişle, zararın büyük bölümü, çıktı kabul edilmeden önce basit bir doğrulamanın yakalayacağı temel kusurlardan geliyor.

Neden önemli

Uygulayıcılar için mesaj somut: tek dosyalık, geri bildirimsiz iş akışı — eski bir dosyayı kopyala, bir modelden modernize etmesini iste, sonucu geri yapıştır — zaten çalışan kodu sessizce bozabilir ve yürütme geri bildirimi olmadan bu gerileme tamamen fark edilmeyebilir. Eski PHP kod tabanları, tam da böyle kısayolların en cazip göründüğü ortamlardır.

Makalenin metodolojik noktası en azından o kadar kalıcı olabilir. Yazarlar, LLM tabanlı modernizasyon değerlendirmelerinin her zaman bir değişiklik-yok referansı içermesi gerektiğini savunuyor; aksi halde bir model, kod tabanını bulduğundan kötü durumda bırakırken bile başarılı görünebilir. Ayrıca modernizasyon kazanımlarının ve davranışsal korumanın ayrı metrikler olarak raporlanmasını öneriyorlar; çünkü tek bir harmanlanmış puan, biçimsel güncellemeler uğruna ne kadar çalışan davranışın yok edildiğini gizleyebilir.

Yardımcı yapay zekâ yeniden düzenleme araçları geliştiren ekipler için araştırma ucuz bir güvenceye işaret ediyor: üretilen kodun, kabul edilmeden önce en azından hedef dil sürümünde çözümlenip yüklenmesini doğrulayın. Makale gösteriyor ki gözlemlenen hasarların çoğu, o en küçük kontrolün bile önleyeceği başarısızlıklardan kaynaklanıyordu.