AI ile PR Review Darboğazı: SLA ile Yönetme (Alios)

AI ile PR Review Darboğazı: SLA ile Yönetme (Alios)

AI araçlarıyla kod üretimi hızlandığında sprint'e giren PR sayısı da artıyor. Cursor bir feature'ı saatlerde yazıyor, Copilot boilerplate'i tamamlıyor, Claude entegrasyon kodunu üretiyor. Geliştirici Salı sabahı üç PR açıyor — geleneksel tempoda bunlar haftaya yayılırdı.

Ama review hızı değişmedi.

Üç PR açıldı, üçü de sırada bekliyor. Reviewer kendi işiyle meşgul. Birinci gün geçti, ikinci gün geçti. PR'lar "REVIEW" durumunda asılı. Geliştirici başka görevlere geçti. Review nihayet geldi ama geliştirici context'ten çıkmış. Düzeltmeler yapıldı, tekrar review, tekrar bekleme. Cuma günü merge edilmesi gereken kod Salı'ya taşındı.

AI yazma hızını artırdı. Review darboğazını büyüttü.

PR Sayısı Artınca Ne Oluyor?

Review beklemesi küçük bir gecikme gibi görünüyor. Ama sprint ölçeğinde büyüyor.

Bağımlılık zinciri kırılıyor. Frontend API'yi bekliyor, API PR review'u bekliyor. Review gecikince zincirin tamamı duruyor. Bir PR'ın iki gün beklemesi dört görevin gecikmesine yol açabiliyor.

Context maliyeti artıyor. Geliştirici review beklerken başka göreve geçiyor. Review geldiğinde o PR'ın context'ine geri dönmek zaman alıyor. AI hızıyla kazanılan süre context switch maliyetiyle harcanıyor.

Review kalitesi düşüyor. Kuyrukta bekleyen PR sayısı arttıkça reviewer "hızlı bakıp geçeyim" moduna giriyor. Dikkatli review yerini yüzeysel onaya bırakıyor. Hatalar canlıya geçiyor.

Görünmez bekleme birikimi. "REVIEW" durumundaki node'lar aktifmiş gibi görünüyor. Aslında beklemede. Bu fark sprint takibinde görünmüyor — her şey yolunda gibi durur ta ki Cuma'ya kadar.

Alios'ta REVIEW ve WAITING Görünürlüğü

Alios'ta review sürecini yönetmek için iki durum birlikte çalışıyor: REVIEW ve WAITING.

👀 REVIEW   → PR açıldı, reviewer aktif inceleme yapıyor
              veya incelemeye henüz başlamadı
⏳ WAITING  → Review tamamlandı, düzeltme bekleniyor
              veya onay için başka bir adım bekleniyor

Bu ayrım önemli. REVIEW'da top reviewer'da. WAITING'de top geliştiriciye geri döndü — düzeltme, ek test veya başka onay bekliyor.

PR Açılırken: REVIEW Node'u Formatı

PR açıldığı anda görev node'u REVIEW durumuna geçiyor ve şu bilgiler ekleniyor:

👀 REVIEW — [Tarih / Saat]

PR linki: [GitHub / GitLab URL]
Branch: [Branch adı → target branch]
Reviewer: [Atanan kişi]
Review deadline: [Açılış tarihi + SLA süresi]
Öncelik: [ ] Kritik  [ ] Normal  [ ] Düşük

Değişiklik özeti:
[Ne değişti — 2-3 cümle. AI üretilen kod mu,
elle yazılan mı, karma mı?]

Test edilmesi gereken senaryolar:
- [Senaryo 1]
- [Senaryo 2]

Özel dikkat noktaları:
[Reviewer'ın bilmesi gereken risk, bağımlılık
veya bağlam — varsa]

AI kullanıldıysa:
[Hangi kısımlar AI üretimi, reviewer neye
özellikle bakmalı]

"AI kullanıldıysa" alanı bu şablonun AI çağına özgü kısmı. AI üretilen kod review'da farklı dikkat gerektiriyor: edge case'ler, projeye özgü iş kuralları, entegrasyon noktaları. Bu bilgi reviewer'a önceden verildiğinde review kalitesi artıyor, süresi kısalıyor.

24 Saat SLA Kuralı

SLA (Service Level Agreement) kurumsal bir kavram gibi görünüyor. Ama küçük ekipte de işe yarıyor — çünkü beklenti belirsizliğini ortadan kaldırıyor.

"PR'ı review et" talep edildiğinde "ne zaman?" sorusu yanıtsız kalıyor. SLA bu soruyu yanıtlıyor.

📋 PR REVIEW SLA — Temel Kural Seti

Kritik (hotfix, prod bug, güvenlik):
→ Review başlangıcı: 2 saat içinde
→ Tamamlanma: Aynı gün

Yüksek öncelik (aktif sprint görevi, bağımlılık zincirinde):
→ Review başlangıcı: İş günü içinde (8 saat)
→ Tamamlanma: 24 saat

Normal (feature, iyileştirme):
→ Review başlangıcı: 24 saat içinde
→ Tamamlanma: 48 saat

Küçük (dokümantasyon, minor fix, style):
→ Review başlangıcı: 48 saat içinde
→ Tamamlanma: 72 saat

SLA node'a yazıldığında iki şey oluyor: reviewer ne zaman bakması gerektiğini biliyor, geliştirici ne zaman takip edeceğini biliyor. "Baktın mı?" Slack mesajı yerini node'daki deadline takibine bırakıyor.

SLA Aşılınca Ne Olur?

SLA aşılmış REVIEW node'ları için otomatik eskalasyon adımları:

SLA + 0 saat: Normal — reviewer kendi takibinde
SLA + 4 saat: Geliştirici node'a hatırlatma notu ekler
SLA + 8 saat: Ekip liderine görünür — Pazartesi/Çarşamba
              risk kontrolünde yakalanır
SLA + 24 saat: Reviewer değişikliği değerlendirilir
               veya PR önceliği yükseltilir

Review Checklist

AI üretilen kod arttığında review checklist daha da kritik hale geliyor. Reviewer neye bakacağını biliyor ama AI'a özgü riskler standart checkliste girmediyse gözden kaçıyor.

📋 PR REVIEW CHECKLİST

TEMEL KONTROLLER
- [ ] PR açıklaması dolu — ne değişti anlaşılıyor
- [ ] Değişiklik tek bir amaca odaklı
      (çok büyükse bölünmeli)
- [ ] Testler var ve geçiyor
- [ ] CI/CD pipeline yeşil

FONKSİYONEL KONTROL
- [ ] Kod beklenen davranışı karşılıyor
- [ ] Edge case'ler ele alınmış
- [ ] Hata yönetimi var

AI KODU ÖZEL KONTROL
- [ ] AI üretilen bölümler projeye özgü iş
      kurallarını doğru yansıtıyor mu?
- [ ] Edge case'ler ve null/empty durumları
      ele alınmış mı — AI bunları sık atlar
- [ ] Hardcoded değer veya test verisi
      üretime sızmamış mı?
- [ ] Naming ve kod stili ekip standardıyla uyumlu mu?
- [ ] Gereksiz AI çıktısı (açıklama, yorum, ölü kod)
      temizlenmiş mi?

GÜVENLİK
- [ ] Input validation yapılıyor
- [ ] Hassas veri log'a yazılmıyor
- [ ] Yetki kontrolü doğru uygulanmış

ENTEGRASYON
- [ ] Mevcut modüllerle çakışma yok
- [ ] API kontratı değişmediyse bağımlı
      servisler etkilenmiyor
- [ ] Migration gerekiyorsa hazır ve test edilmiş

REVIEW KARARI
[ ] Onaylandı — merge edilebilir
[ ] Küçük düzeltme — approve + düzeltme sonrası merge
[ ] Değişiklik gerekiyor — açıklama ile geri döndü
[ ] Bloke — mimari sorun, önce tartışılmalı

Review notu:
[Ne iyi yazılmıştı — 1 madde]
[Ne değiştirilmeli — spesifik]
[AI koduna özel gözlem — varsa]

"Review notu" bölümü opsiyonel görünüyor ama zamanla ekip hafızası oluşturuyor. Aynı yorum tekrar tekrar verilmiyorsa geliştiriciler o geri bildirimi içselleştiriyor. AI prompt'larına da yansıtılabiliyor: "geçen review'da şu eksik çıktı, bu sefer promptta belirttim."

Örnek Ekip Kural Seti

Kural seti toplantıda söylenip unutulan şeyler değil — Alios'ta "Review Kuralları" node'u olarak kayıt altında ve her yeni ekip üyesine onboarding'de gösteriliyor.

📌 REVIEW KURALLARI — [Ekip Adı]
Son güncelleme: [Tarih]

PR AÇARKEN (Geliştirici)

1. PR açılır açılmaz görev node'u REVIEW'a geçer
   ve reviewer atanır — aynı gün, bekletilmez

2. PR açıklaması doldurulur:
   • Ne değişti (2-3 cümle)
   • Test senaryoları
   • AI kullanıldıysa hangi kısımlar

3. PR büyüklüğü: 400 satırı geçen PR'lar
   bölünür — büyük PR review kalitesini düşürür

4. Draft PR açılmaz — review'a hazır olmayan
   kod REVIEW'a girmez, In Progress kalır


REVIEW YAPARKEN (Reviewer)

5. SLA takip edilir:
   Kritik → 2 saat | Yüksek → 24 saat | Normal → 48 saat

6. Review başladığında node'a not düşülür:
   "Review başladı — [saat] — tahmini bitiş: [saat]"
   Bu not "kimse bakmıyor mu?" sorusunu ortadan kaldırır

7. Review checklist'teki AI özel kontroller atlanmaz

8. "Approve" vermek onay değil, sorumluluk paylaşımıdır
   — checklist tamamlanmadan approve verilmez


DÜZELTME DÖNGÜSÜ

9. Değişiklik istendiyse görev WAITING'e geçer,
   geliştirici düzeltmeleri yapar

10. Düzeltme tamamlanınca tekrar REVIEW —
    reviewer aynı gün bakma sorumluluğu alır
    (düzeltme revizyonu için SLA: 4 saat)

11. İki reviewdan fazla döngü varsa yüz yüze
    veya sesli görüşme yapılır —
    async tartışma üçüncü döngüyü önlemez

GENEL

12. "Bakacağım" SLA başlatmaz —
    review başladığında node güncellenir

13. SLA aşıldığında geliştirici node'a not ekler,
    ekip liderine bildirmez — sistem görünür kılıyor

14. Reviewer değişikliği gerekirse ekip lideri
    node'u günceller — geliştirici bekletilmez

Son Düşünce

AI PR sayısını artırıyor. Review kapasitesi artmıyor. Bu uçurum yönetilmezse hız kazancı review kuyruğunda eriyor.

Alios'ta REVIEW ve WAITING görünürlüğü, 24 saat SLA kuralı ve review checklist bu uçurumu kapatıyor. Her PR nerede, kimde, ne zamandır bekliyor — node'a bakılarak görülüyor. SLA aşıldığında sistem alarm veriyor, geliştirici sormak zorunda kalmıyor.

AI hızıyla yazılan kod, review kalitesinden ödün vermeden canlıya çıkıyor.