Üç Aylık Hatalı Onay: LLM’ler Neden Yanlış Düzeltmeler Sunar?

Geçenlerde bir Slack botu bana bir betiğin hiç çalışmadığını bildirdi. Oysa sadece iki dakika önce aynı betik 81 hava durumu verisi çekmişti. Üç saatlik bir araştırmanın ardından gerçeği anladım: hem bu anlık uyarı yalanı, hem de üç aydır süren büyük yalanın kaynağına ulaşmıştım.

Üç aylık ‘tamam’ döngüsü

Üç ay boyunca haftada iki-üç kez aynı sorunla karşılaştım: cron sağlık uyarısı tetikleniyordu. Her seferinde uyarıyı bir Claude Code oturumuna yapıştırıp LLM’den sorunun kaynağını bulmasını istedim. Model her defasında makul bir açıklama sunuyor, bir düzeltme öneriyor ve ardından "İşte bu, sorun çözüldü" diyordu. Ben de düzeltmeyi uyguluyor ve yoluma devam ediyordum.

Ancak bu düzeltmeler asla kalıcı olmadı. Bazen model sadece alerted_until tarihini birkaç ay ileriye taşıyarak uyarıyı geçici olarak susturuyordu. Bazense yanlış dosyayı düzenliyor, böylece sorun bir-iki hafta içinde farklı bir betikte yeniden ortaya çıkıyordu. Her oturumda model geçmişi hatırlamadığı için bu döngü sürekli tekrarlanıyordu.

Benim hatam, 15 ayrı hata ayıklama oturumunu tek bir konuşma gibi görmemdi. Oysa model yalnızca o anki oturumu görüyordu. Geleneksel bir inbox sistemi ve LLM’in "tamam" yanıtı, yeterliydi benim için.

Asıl sorunun kaynağı

Kullandığım cron sağlık monitörü, ölü adamın düğmesi prensibiyle çalışıyordu. Her planlanan betik çalıştığında sistemde bir kalp atışı (ping) göndermeliydi. Eğer belirlenen süre içinde ping alınmazsa Slack’e uyarı geliyordu.

Bu sistemi kendim kurmuştum; sağlayıcı hizmetleri yerine yerel bir çözüm kullanıyordum. Healthchecks.io, Cronitor veya Dead Man’s Snitch gibi hizmetler her kontrol için ayrı bir HTTP uç noktası sunarken, benim sistemimde üç bileşen birbiriyle eşleşmeliydi:

• crontab.txt (slug etiketi)
• checks.json (kayıt defteri)
• Kaynak kodundaki health_run() fonksiyonu ve pings.json (çalışma kaydı)

Sorun, sistemdeki hiçbir bileşenin diğerlerini zorunlu kılmamasıydı. Örneğin, bir betiği checks.json dosyasına ekleyip kaynak kodunda health_run() çağırmayı unutabiliyordunuz. Ya da cron satırına bir slug ekleyebilir, ancak bu slug’un kayıt defterinde karşılığı olmayabilirdi. Bu şekilde sistem sürekli hata üretiyor, ben de uyarıları süresiz olarak susturuyordum.

Verilerin neredeyse silinmesine yol açan hata

Bir oturumda Opus 4.6 modelini sistem mimarisi incelemesi için kullanırken, Codex CLI (GPT-5) aynı anda doğrulayıcıyı yeniden yazdı ve 66 cron satırını slug’larla etiketledi. Toplamda sadece 35 dakika sürdü.

Ancak dördüncü bir denetim sırasında Sonnet 4.5, crontab-apply.sh betiğinde hem Opus hem de Codex’in kaçırdığı kritik bir hata buldu. Betik, yeni cron işlerini güvenli bir şekilde kurması gerekiyordu. Oysa gerçek akış şöyleydi:

# ESKİ YAPI: önce kur, sonra doğrula
crontab new.txt  # zaten yeni cron devrede
crontab -l > verify.txt
diff crontab.txt verify.txt || exit 1  # çok geç

Eğer diff başarısız olursa betik 1 koduyla çıkış yapıyordu — ancak yeni cron zaten devredeydi. Yanlış biçimlendirilmiş bir crontab.txt dosyası, VPS üzerindeki tüm cron işlerini hiçbir kurtarma yoluna izin vermeden silebilirdi.

Doğru akış ise şöyle olmalıydı:

# YENİ YAPI: önce doğrula, sonra kur
crontab -n new.txt || { restore_backup; exit 1; }
crontab new.txt
crontab -l > verify.txt
diff crontab.txt verify.txt || { restore_backup; exit 1; }

Bu hata, betik oluşturulduğundan beri sistemdeydi — ne Opus ne de Codex tarafından fark edilmişti. Ben de hiç bakmamıştım. Sistemdeki diğer bileşenlerin aksine, shellcheck aracı bu hatayı tespit etmişti. Sonnet 4.5, qa-bash yeteneğiyle betiği taradı ve sorunu doğrudan bildirdi. Modelin kendisi değil, deterministik bir araç hata bulmuştu.

Elde edilen sonuçlar ve dersler

Üç saatlik yoğun bir oturumun ardından sistemde 18 ayrı hata tespit edildi (9’u uygulama sırasında, 9’u dört denetim turunda). 66 cron satırı slug’larla etiketlendi ve kapsam oranı %0’dan %94’e yükseldi. 15 uyarı süresiz olarak susturulmuşken, sadece biri meşru bir şekilde kalıcı olarak susturuldu.

LLM’lerle çalışırken dikkat edilmesi gerekenler:

1. Belirleyici araçları kullanın

shellcheck, pytest-cov, mypy, tip denetleyicileri, linterlar ve şema doğrulayıcıları gibi araçlar, olasılıksal katmanları olmayan, deterministik sonuçlar veren sistemlerdir. LL’lerin katmanlarını artırmak yerine, ilk önce bu araçları kullanın. Model yalnızca deterministik kontrollerin yakalayamadığı sorunlar için devreye girmelidir.

1. Konuşmaları biriktirmeyin

Her oturum bir öncekini hatırlamaz. Benzer hataları birbirine bağlamak yerine, her seferinde aynı sorunla karşılaşmaya devam edersiniz. Sorunları belgeli olarak izleyin ve modelin geçmişi hatırlamasını beklemeyin.

1. Doğrulama katmanlarını çeşitlendirin

Bir modelin çıktısını doğrulamak için farklı modelleri, araçları ve manuel kontrolleri kullanın. Örneğin, qa-bash yeteneğiyle shellcheck entegrasyonu, sadece model taramasına göre çok daha güvenilir sonuçlar verir.

1. Güven, otomatik sistemler kadar tehlikelidir

LLM’ler size "tamam" yanıtı verdiyse, sorun gerçekten çözülmüş demektir — ancak sadece modelin görüş açısından. Dışarıdan bir doğrulama sistemi olmadığında, sistematik hatalar gözden kaçabilir.

Sonuç: Güvenilirlik için süreç tasarımı

Bu hikaye, LLM’lerin gücünü gösterirken aynı zamanda sınırlarını da ortaya koyuyor. Model ne kadar yetenekli olursa olsun, belirleyici araçlar ve çok katmanlı doğrulama sistemleri olmadan yapılan iyileştirmeler geçici olabilir. Kendi sistemimin mimarisindeki kusurları üç ay boyunca görmezden gelmem, sistematik bir hata yerine bireysel hatalara odaklanmamdan kaynaklandı.

Artık cron işlerimin %94’ü otomatik olarak etiketlenmiş durumda. Uyarı sistemi sadece iki güncel olmayan durumu bildiriyor. Ve en önemlisi, bir sonraki sistem güncellemesinde crontab-apply.sh betiğinin silinmesi riski ortadan kalktı.

LLM’ler araçtır — sistemler inşa etmek için değildir. Güvenilir yazılım geliştirmenin temelinde, insanların tasarladığı, makinelerin desteklediği süreçler yatar. Bu hikaye, süreç tasarımının ne kadar kritik olduğunu bir kez daha hatırlatıyor.