Hiçbir İnsan LLM'lerden Daha İyi Kod Yazamayacak mı? Neyde Daha İyi?

Sosyal medyada sıkça paylaşılan bir iddiaya göre: "Hiçbir insan bir daha LLM'lerden (Büyük Dil Modelleri) daha iyi kod yazamayacak. Bu gerçeği kabul edin, rol yapmayı bırakın ve yolunuza devam edin."

Ancak bu iddianın içinde sorgulanmamış çok büyük bir "daha iyi" varsayımı gizli. LLM'ler doğru (right) olmak için değil, akla yatkın (plausible) görünmek için eğitilirler. İstediğiniz kadar şık, deyimsel ve pürüzsüz görünen bir kod üretebilirsiniz; fakat mevcut sistemler, takım alışkanlıkları, iş gereksinimleri, hata modları ve henüz netleşmemiş özellikler gibi kritik kısıtları yine de kaçırabilirsiniz.

Kıdemli (Senior) düzeyde yazılım mühendisliği sadece kod "yazmak" değildir; ne zaman kod yazmaması gerektiğini bilmektir. Gerçek uç durumları (edge cases) ve henüz olgunlaşmamış soyutlamaları fark etmek, bir problemin çok daha basit çözülebileceğini veya hiç çözülmemesi gerektiğini görebilmektir. Bu tür bir muhakeme yeteneğini ölçmek ve prompt ile tarif etmek oldukça zordur.

"Daha İyi" Kavramının Kusurlu Tek Boyutlu Ölçümü#

"Daha iyi" kelimesini genellikle tek bir sayısal (skaler) değermiş gibi ele alırız. Oysa "Neyde daha iyi?" diye sorduğunuzda işler değişir. Ölçtüğünüz boyuta göre bu kavram farklı anlamlar kazanır:

• Dakikada Yazılan Satır Sayısı (Verimlilik): Basit ve ölçmesi kolay bir metriktir, gelişim hissi verir. Ancak bu sadece klavye hızının ölçüsüdür. Bin satırlık yanlış kod, hiç kod olmamasından daha kötüdür. İlk bakışta çöken bin satırlık kod ise bundan bile beterdir.
• Doğruluk (Correctness): Kodun spesifikasyonları karşılaması ve testlerden geçmesidir. Önemli bir adımdır ancak tek başına yeterli değildir.
• Sürdürülebilirlik (Maintainability): Mükemmel çalışan ama değiştirilemeyen bir yazılım, tam da kaçınmak istediğimiz "legacy" (miras) koddur. Yazılımı acı çekmeden değiştirebilmemiz gerekir.
• İnşa Etmeme Cesaretini Gösterebilmek: Bazen en iyi mühendislik kararı, o özelliği veya kodu hiç yazmamaktır.

Gerçek Kâbus: Bozulana Kadar Çalışan Kodlar#

LLM tarafından üretilen kodlarla ilgili asıl tehlike, kodun çalışmayana kadar çalışması ve patladığında size hiçbir anlam ifade etmemesidir.

Örneğin; mantıklı görünen bir kod bir şekilde canlı ortama (production) çıkar. Model, işlem yöneticisi fonksiyonunuza kendi kendine bir retry_on_timeout dekoratörü eklemiştir. Bu dekoratör hatayı yakalar, bir WARNING logu basar ve None döndürür. Akışın devamındaki kod ise None değerini "sıfır dolarlık başarılı çekim" olarak yorumlar ve müşterileriniz sipariş ettikleri ürünleri bedavaya almaya başlar.

Gramli'nin "To Retry or Not to Retry" testinde benzer bir vaka incelenmiştir: Bir ödeme isteği idempotency key olmadan 503 hatası ve Retry-After başlığı döndürdüğünde, test edilen 8 modelin çoğu başlığı takip edip işlemi tekrar denemiş (çift çekim riski), yalnızca ikisi reddetmiştir.

Neden Böyle Oluyor ve Pratik Çıkarımlar#

HumanLayer'dan Dex'in açıkladığı üzere, birçok kodlama kıyaslaması (benchmark) modele yalnızca geçti/kaldı (pass/fail) ödülü verir. Test geçtiğinde model kazanır; kötü tasarım için hiçbir ceza almaz. Bu yüzden model, sırf testi geçirmek için rastgele try/catch blokları veya tip dönüşümleri (type cast) eklemeyi öğrenir.

Geliştiriciler İçin Pratik Çıkarımlar:

• Testlerin Geçmesi Yetmez: AI tarafından üretilen kodlarda gizli try/catch bloklarını ve sessiz hata yutma (silent failure) durumlarını mutlaka inceleyin.
• Kritik İş Mantığını Koruyun: Ödeme sistemleri ve idempotency gibi hata kaldırılmayacak noktalarda LLM çıktısına körü körüne güvenmeyin.
• Sürdürülebilirliği Önceliklendirin: Hızlı kod üretmek yerine, ekibin bakımını üstlenebileceği ve kolayca değiştirebileceği mimarilere odaklanın.