17 PR/Gün, Tek QA: E2E Hata Triyajını Otomatikleştirmek

pdf.net'te 18 geliştirici günde ortalama 17, zirve günde 33 pull request birleştiriyor; bunların hepsini tek bir QA mühendisi izliyordu. Ekip, e2e testlerini release anından staging'e her merge sonrasına çekince, kırmızı koşuların sayısı da artmış ve manuel triyaj sürdürülemez hale gelmişti. Çözüm, her koşudan sonra tetiklenen bir GitHub Action ile Claude'un (Opus/Sonnet) hata loglarını, diff'leri ve deploy aralığını değerlendirip 'PR ile ilgili', 'PR ile ilgisiz' veya 'yetersiz veri' kararı vermesi; bu karar doğrudan bir işlem akışına (Linear ticket'ı mı, tek seferlik rerun mı) yönlendiriliyor.

Sistem yalnızca metin üretmiyor, karar veriyor: PR ile ilişkili bulgular Linear ticket'ı ve Slack bildirimiyle sonuçlanırken, belirsiz durumlarda tek bir otomatik rerun deneniyor; rerun yeşil çıkarsa flake olarak kapatılıyor, kırmızı çıkarsa nöbetçi mühendis etiketlenerek ticket açılıyor. Ekip; ticket'ların sonsuza dek açık kalmasını önleyen idempotent bir kurtarma sırası, masum katkı sağlayanların yanlışlıkla 'düzeltme için teşekkür' mesajı almasını engelleyen saf bir neden sınıflandırıcısı ve karışık (hem düzelen hem yeni kırılan testli) koşularda kurtarma adımının atlanmasını önleyen çift yollu bir dispatcher gibi gerçek üretim hatalarını da paylaşıyor.

Sonuç, ayda tek bir mühendislik saatinden daha ucuza mal olan, gürültüyü dedup, otomatik kapatma, kanal ayrımı ve manuel susturma ile kontrol eden bir triyaj hattı. Mühendisler için asıl mesaj şu: LLM tabanlı triyaj, insan gözetimini ortadan kaldırmıyor ama doğru yönlendirme mantığıyla birleşince tek bir QA mühendisinin onlarca günlük PR'ı güvenle takip etmesini mümkün kılıyor.