AI kodlama asistanları hızlı kod üretir, ancak her “accept” bir karardır. Stage-Gate konseptinden uyarlanan 8 kriterlik Decision Gate framework’ü (Fayda, Gereklilik, Yük, Conflict, Performans, Security, Darboğaz, Güncellik) ile bu kararlar sistematize edilir. Security ve Conflict “must-meet” (knockout), diğerleri scored olarak değerlendirilir.
| Hızlı Referans | |
|---|---|
| Köken | Stage-Gate (Robert Cooper, 1980’ler) |
| Adaptasyon | Solo developer için mikro ölçekli karar filtresi |
| Kriter sayısı | 8 (2 knockout + 6 scored) |
| Karar türleri | Go / Kill / Defer |
| İlişkili kavramlar | ADR, OpenSpec |
KISS, SoC ve ADR/OpenSpec yazılarının yer aldığı şeriye, AI destekli geliştirmede giderek daha kritik hale gelen bir kavramla devam ediyorum: Decision Gate.
Sorun: Hız Var, Filtre Yok
Şubat 2025’te Andrej Karpathy, “vibe coding” terimini tanıttı1: LLM’lerin ürettiklerini sorgulamadan kabul etmek, kodu okumamak, diff’leri kontrol etmemek. Bir yıl sonra Karpathy’nin kendisi bile bu yaklaşımı “passe” ilan ederek “agentic engineering” kavramına geçti2.
Aradaki süreçte veriler birikti:
| Metrik | Değer | Kaynak |
|---|---|---|
| AI-generated kod oranı | %41 | Qodo, 20253 |
| AI co-authored kodda majör issue artışı | 1.7x | CodeRabbit, Aralık 20254 |
| AI co-authored kodda güvenlik açığı artışı | 2.74x | CodeRabbit, Aralık 20254 |
| AI ile deneyimli dev’lerin gerçek hız değişimi | -%19 (yavaşlama) | METR, 20255 |
| Dev’lerin subjektif hız algısı | +%20 (hızlandık sanıyoruz) | METR, 20255 |
Rakamlar bir paradoksa işaret ediyor: AI daha fazla kod üretiyor, ancak daha fazla kod daha fazla kalite sorunu demek. Kurumsal ortamda code review, PR approval ve tech lead gibi doğal filtreler var. Solo developer’da ise tek filtre kendinizsiniz ve AI’ın confidence bias’ı (kendimizi %20 daha hızlı sanmamız) bu filtreyi zayıflatıyor.
Bir de pipeline sorunu var: 2024-2025’te birçok organizasyon junior developer alımını kıstı ya da durdurdu. 2-4 yıl içinde, kod neden çalışıyor veya neden bozuluyor sorusuna yanıt verebilecek deneyimli mühendis sayısı azalacak. AI’ın ürettiği technical debt’i temizleyecek insan kaynağı daralıyor.
Peki, bu filtreyi nasıl sistematize edebiliriz?
Stage-Gate: Konseptin Kökeni
Phase-Gate (veya Stage-Gate), Robert G. Cooper tarafından 1980’lerde geliştirilen bir proje yönetim tekniğidir6. Temel fikir basittir: bir proje fazlara bölünür, her faz arasında bir “gate” (karar noktası) bulunur. Gate’lerde bir yönetim komitesi projeyi değerlendirir ve şu kararlardan birini verir:
- Go: Devam et, sonraki faza geç
- Kill: Projeyi durdur
- Hold: Beklet, koşullar değişince yeniden değerlendir
- Recycle: Geri dön, yeniden çalış
Gate’ler salt durum raporu veya bilgi güncellemesi değildir. Cooper’ın ifadesiyle, “gates with teeth” (dişli kapılar): zayıf projeleri eleyerek pipeline’ı temiz tutan karar noktalarıdır7.
Gate kriterlerinde iki katman vardır:
- Must-meet (knockout): Sağlanmazsa proje doğrudan durdurulur
- Should-meet (scored): Puanlama ile değerlendirilen, beklenen özellikler
Decision Gate: Mikro Ölçekli Adaptasyon
Stage-Gate kurumsal ürün geliştirme için tasarlanmıştır: fazlar aylar sürer, gate’lerde komiteler oturur, başkanlık eden bir yönetici karar verir. Solo developer’ın veya küçük ekibin buna ihtiyacı yoktur, en azından bu formda.
Ancak temel mekanizma, yani her ilerleme öncesi kriterlere dayalı Go/Kill kararı, ölçek bağımsız çalışır. Decision Gate, bu mekanizmayı tekil karar anlarına uyarlar:
| Stage-Gate (Cooper) | Decision Gate | |
|---|---|---|
| Kapsam | Proje yaşam döngüsü (İdea-to-Launch) | Tekil karar anı |
| Karar veren | Yönetim komitesi, steering board | Solo developer |
| Kararlar | Go / Kill / Hold / Recycle | Go / Kill / Defer |
| Süreç | Aylık gate meeting | Saniyeler içinde mental checklist |
| Bağlam | Kurumsal ürün geliştirme | AI-assisted bireysel geliştirme |
Decision Gate’te “Hold” ve “Recycle”, tek bir Defer altında birleşir: backlog’a at, koşullar değişince yeniden değerlendir.
8 Kriter
Decision Gate, her teknik kararı 8 kriter üzerinden değerlendirir. İlk ikisi must-meet (knockout): herhangi biri kırmızıysa karar doğrudan Kill’dir. Diğer altısı should-meet (scored): toplam skor eşik değerinin altındaysa Kill veya Defer.
| # | Kriter | Tip | Gate Sorusu |
|---|---|---|---|
| 1 | Security | Must-meet | Güvenlik riski oluşturuyor mu? |
| 2 | Conflict | Must-meet | Mevcut pattern ile çatışıyor mu? |
| 3 | Fayda | Should-meet | Kullanıcıya/projeye ne kazandırıyor? |
| 4 | Gereklilik | Should-meet | Şu an gerçekten lazım mı? |
| 5 | Yük | Should-meet | Ne kadar bakım yükü getiriyor? |
| 6 | Performans | Should-meet | Bundle size/latency/runtime etkisi ne? |
| 7 | Darboğaz | Should-meet | Bottleneck veya tek nokta bağımlılığı yaratır mı? |
| 8 | Güncellik | Should-meet | Dependency maintained mi, yaklaşım güncel mi? |
Should-meet kriterlerde puanlama 1-10 arasıdır: 1-3 düşük (olumsuz), 4-6 nötr, 7-10 yüksek (olumlu). Eşik değeri proje ve ekibe göre belirlenir; genel bir başlangıç noktası olarak ortalama 6/10 üzeri Go, 4-6 arası Defer, 4 altı Kill olarak uygulanabilir.
Must-Meet (Knockout)
1. Security
Gate sorusu: Bu değişiklik güvenlik riski oluşturuyor mu?
AI-generated kodda güvenlik açıkları 2.74 kat daha yaygın4. Input validation eksikliği, auth bypass, secret exposure, XSS ve injection vektörleri LLM çıktılarında sıkça görülen sorunlardır.
Security kırmızıysa başka kritere bakmaya gerek yoktur. Öncelik sıralaması burada geçersizdir.
Örnek: LLM bir API endpoint öneriyor, ancak rate limiting ve input sanitization içermiyor. Gate sonucu: Kill. Önce güvenlik katmanını ekle, sonra yeniden değerlendir.
2. Conflict
Gate sorusu: Mevcut pattern, convention veya dependency ile çatışıyor mu?
LLM’ler farklı projelerin kalıplarını karıştırabilir. Projede Zustand varken Redux önermek, ESM kullanılırken CommonJS syntax üretmek, mevcut bir utility varken yeni bir helper yazmak gibi durumlar doğrudan conflict’tir.
Örnek: Proje boyunca fetch wrapper kullanılıyor, LLM ise axios import eden bir kod bloğu öneriyor. Gate sonucu: Kill. Mevcut pattern’a uyumlu hale getir.
Should-Meet (Scored)
3. Fayda
Gate sorusu: Bu değişiklik kullanıcıya veya projeye ne kazandırıyor?
LLM’ler bazen “olsa güzel olur” önerilerde bulunur: ekstra abstraction, kullanılmayacak configler, prematüre optimization. Sözcüğün geniş anlamında fayda: kullanıcı deneyimini iyileştiriyor mu, bakım maliyetini düşürüyor mu, performansı artırıyor mu?
Fayda net olarak ifade edilemiyorsa, bu bir uyarı işaretidir.
4. Gereklilik
Gate sorusu: Bu, şu an gerçekten lazım mı yoksa “olsa iyi olur” mu?
YAGNI (You Ain’t Gonna Need It) prensibinin gate formudur. AI kodlama asistanları, sorunun kapsamını genişletme eğilimindedir: bir buton eklemek istersiniz, karşınıza tema sistemi çıkar. Gereklilik kriteri, scope creep’e karşı ilk savunma hattıdır.
Örnek: Tek seferlik bir veri dönüşümü için LLM genel amaçlı bir transformer class öneriyor. Gate değerlendirmesi: Gereklilik düşük, basit bir fonksiyon yeterli.
5. Yük
Gate sorusu: Bu değişiklik ne kadar complexity ve bakım yükü getiriyor?
Her eklenen dependency, her yeni abstraction, her konfigürasyonun bir bakım maliyeti vardır. LLM’ler bu maliyeti hesaba katmaz; çünkü bakım yapan onlar değildir.
Yük değerlendirmesi: yeni dependency sayısı, oluşan abstraction katmanı, config/env değişikliği gereksinimi, dokümantasyon gerekliliği.
6. Performans
Gate sorusu: Bundle size, latency veya runtime üzerindeki etkisi ne?
LLM’ler bazen tüm kütüphanenin import edilmesini önerir (tree-shaking uyumsuz), gereksiz polyfill ekler veya performans açısından maliyetli pattern’lar kullanır. Özellikle frontend ve edge ortamlarında her kilobyte önemlidir.
Örnek: LLM tarih formatlaması için moment.js (300KB+) öneriyor, projede zaten Intl.DateTimeFormat kullanılıyor. Gate değerlendirmesi: Performans kırmızı, mevcut çözüm yeterli.
7. Darboğaz
Gate sorusu: Bu değişiklik bottleneck yaratır mı veya tek noktadan bağımlılık oluşturur mu?
Tek bir servise, tek bir API key’e veya tek bir veritabanı bağlantısına bağımlılık, ölçeklenebilirlik sorunu yaratır. LLM çıktıları genellikle “happy path” için optimize edilmiştir; hata senaryoları ve ölçeklenme düşünülmez.
Örnek: LLM tüm cache işlemlerini tek bir Redis instance’a bağlıyor, connection pool veya fallback mekanizması yok. Trafik artışında bu tek nokta tüm sistemi durdurur. Gate değerlendirmesi: Darboğaz kırmızı, en azından fallback stratejisi ekle.
8. Güncellik
Gate sorusu: Önerilen dependency maintained mi? API deprecated mi? Yaklaşım güncel mi?
LLM’lerin bilgi kesimi (knowledge cutoff) vardır. Önerilen kütüphanenin artık maintained olmadığı, API’nin deprecated olduğu veya daha iyi alternatiflerin çıktığı durumlar sıktır. Bu kriter, LLM’in temporal sınırlamalarına karşı bir korumadır.
Örnek: LLM request (deprecated 2020) kütüphanesiyle HTTP çağrısı öneriyor. Gate sonucu: Güncellik kırmızı, fetch veya undici kullan.
Karar Matrisi
AI bir öneri sunuyor
|
v
[Security kontrol] --Red--> KILL
|
Green
v
[Conflict kontrol] --Red--> KILL
|
Green
v
[6 kriter scored]
Fayda + Gereklilik + Yük
+ Performans + Darboğaz + Güncellik
|
v
Toplam skor >= eşik? --Hayır--> KILL veya DEFER
|
Evet
v
GODefer kararı, Kill’den farklıdır: öneri değerli olabilir ancak zamanlama yanlıştır. Gereklilik düşük ama Fayda yüksekse, backlog’a alınır ve koşullar değiştiğinde yeniden gate’den geçirilir.
Pratik Senaryolar
Senaryo 1: Yeni State Management Kütüphanesi
Projede Zustand kullanılıyor. LLM, bir component için Jotai ile çözüm öneriyor.
| Kriter | Değerlendirme | Sonuç |
|---|---|---|
| Security | Nötr | Pass |
| Conflict | Mevcut Zustand pattern’ıyla çatışıyor | KNOCKOUT |
Gate sonucu: Kill. Zustand ile yeniden implement et.
Senaryo 2: “Nice to Have” Feature
Auth flow’a “remember me” checkbox’u eklenmesi öneriliyor. Roadmap’te yok.
| Kriter | Değerlendirme | Skor |
|---|---|---|
| Security | Session süresi uzatma riski, ama yönetilebilir | Pass |
| Conflict | Mevcut auth pattern’la uyumlu | Pass |
| Fayda | Kullanıcı deneyimini iyileştirir | 7/10 |
| Gereklilik | Roadmap’te yok, kullanıcı talebi yok | 3/10 |
| Yük | Session management’a ek complexity | 4/10 |
| Performans | Olumsuz etkisi yok | 6/10 |
| Darboğaz | Tek nokta bağımlılığı yaratmıyor | 6/10 |
| Güncellik | Standart pattern, güncel | 8/10 |
Ortalama skor: 5.7/10. Gate sonucu: Defer. Backlog’a al, kullanıcı talebi gelirse yeniden değerlendir.
Senaryo 3: Deprecated Kütüphane
LLM, HTTP istekleri için request kütüphanesini kullanıyor.
| Kriter | Değerlendirme | Skor |
|---|---|---|
| Security | Bakım almıyor, bilinen açıklar olabilir | Pass (ama uyarı) |
| Conflict | Projede fetch kullanılıyor | KNOCKOUT |
Gate sonucu: Kill. fetch ile yeniden yaz.
ADR ve OpenSpec ile İlişki
Decision Gate, ADR ve OpenSpec yazısında ele alınan kavramlarla tamamlayıcı bir ilişki içindedir. Üçü birlikte bir karar döngüsü oluşturur:
| Soru | Araç | Zamanlama |
|---|---|---|
| Yapmalı mıyız? | Decision Gate | Pre-decision |
| Neden bu yolu seçtik? | ADR | Post-decision |
| Ne yapacağız, nasıl doğrulayacağız? | OpenSpec | Pre-implementation |
flowchart TD
A[AI bir öneri sunuyor] --> B[Decision Gate - 8 kriter]
B -->|Kill| C[Reddet]
B -->|Defer| D[Backlog'a al]
B -->|Go| E{Karar tipi?}
E -->|Mimari karar| F[ADR yaz - WHY]
E -->|Feature/capability| G[OpenSpec proposal - WHAT]
E -->|Minor change| H[Doğrudan implement et]
F --> I[Implementation]
G --> I
H --> IGate, ADR/OpenSpec öncesindeki ilk filtredir. “Ne yapacağız” ve “neden” sorularına yanıt vermek önemlidir, ancak öncelikle “yapmalı mıyız” sorusunun yanıtlanması gerekir.
Uygulama Rehberi
Decision Gate’i günlük iş akışınıza dahil etmek için karmaşık araçlar gerekmez. Birkaç pratik yaklaşım:
Mental Checklist
Her AI çıktısında, kabul öncesi 30 saniye:
- Güvenlik sorunu var mı?
- Mevcut pattern’la çatışıyor mu?
- Gerçekten lazım mı?
- Bakım yükü ne?
İlk iki soru “evet” ise, doğrudan Kill. Diğerleri tartışılabilir.
PR Self-Review Rutini
Solo çalışırken bile PR açın. Diff’i Gate kriterleriyle tarayın. AI “accept all” yerine, commit bazında değerlendirin.
”Neden?” Sorusu
LLM’e önerdiği çözümün nedenini sorun. Gerekçeyi savunamıyorsa veya genel bir yanıt veriyorsa, bu zayıf bir sinyal.
Haftalık Debt Review
Haftada bir, geçen haftaki kararları gözden geçirin. Gate’den geçen ama sorun yaratan kararlar var mı? Varsa, kriterleri kalibre edin.
Sonuç
AI kodlama asistanları giderek daha yetenekli hale geliyor. Ancak yetenek, karar kapasitesi değildir. LLM’ler öneri motoru olarak çalışır; kabul/red kararı hâlâ geliştiricinindir.
Decision Gate, bu kararı sezgiden sisteme taşır. Hız ile kalite arasında bir denge kürar. “Accept All” yerine “Accept with Intent” yaklaşımını benimser.
Sekiz kriter, her teknik kararı 30 saniyede filtrelemenizi sağlar. Gate, hızı kesmez; hızın yönünü belirler.
İleri Okumalar
- The Stage-Gate Model: An Overview
- Wikipedia: Phase-gate process
- ADR, OpenSpec ve Spec-Driven Development
- Context Engineering Ekosistemi: /court skill’inin daha geniş bağlamda nasıl kullanıldığı
- AI Destekli Codebase Audit: Decision Gate’in 6 audit track’ine uygulanması, guardrailed vibe coding yaklaşımı
- Addy Osmani: Code Review in the Age of AI
- Addy Osmani: My LLM Coding Workflow Going Into 2026
- Qodo: State of AI Code Quality 2025
Footnotes
- Andrej Karpathy, Vibe Coding, Şubat 2025 ↩
- The New Stack, Vibe Coding is Passe, 2026 ↩
- Qodo, State of AI Code Quality 2025 ↩
- CodeRabbit analizi, 470 açık kaynak GitHub PR incelemesi, Aralık 2025. IEEE Spectrum, AI Coding Degrades: Silent Failures Emerge ↩ ↩2 ↩3
- METR, Randomized Controlled Trial on AI coding tools, 2025 ↩ ↩2
- Robert G. Cooper, Stage-Gate Systems: A New Tool for Managing New Products, 1990. Konsept 1980’lerde geliştirilmiş, NASA’nın 1960’lardaki Phased Review Process’inden esinlenmiştir. ↩
- Robert G. Cooper, Winning at New Products, “Gates with teeth” kavramı için bkz. Stage-Gate International kaynakları. ↩
- 01 Decision Gate, Robert Cooper'ın Stage-Gate konseptinin solo developer için mikro ölçekli adaptasyonudur
- 02 8 kriterden Security ve Conflict 'must-meet' (knockout); diğer 6 kriter scored olarak değerlendirilir
- 03 AI co-authored kod 1.7x daha fazla majör issue, 2.74x daha fazla güvenlik açığı içeriyor; bilinçsiz kabul tehlikeli
- 04 Gate hızı kesmez, hızın yönünü belirler: 'Accept All' yerine 'Accept with Intent'
+ Decision Gate nedir?
Decision Gate, AI-assisted geliştirmede her teknik karar anında uygulanan 8 kriterlik bir değerlendirme framework'üdür. Stage-Gate konseptinden uyarlanmıştır ve Go/Kill/Defer kararlarını sistematize eder.
+ Decision Gate ile Stage-Gate arasındaki fark nedir?
Stage-Gate proje yaşam döngüsü boyunca fazlar arası yönetim komitesi kararlarıdır. Decision Gate ise tekil karar anlarında solo developer'ın uyguladığı mikro ölçekli bir filtredir.
+ Vibe coding neden bir Decision Gate'e ihtiyaç duyar?
Vibe coding hız sağlar ancak kalite filtresi içermez. Araştırmalar AI co-authored kodda 1.7x daha fazla majör issue ve 2.74x daha fazla güvenlik açığı olduğunu göstermektedir.
+ Decision Gate, ADR ve OpenSpec ile nasıl ilişkilidir?
Decision Gate 'yapmalı mıyız?' sorusunu yanıtlar (pre-decision). ADR 'neden bu yolu seçtik?' sorusunu belgeler (post-decision). OpenSpec 'ne yapacağız?' sorusunu tanımlar (pre-implementation). Üçü birlikte tam bir karar döngüsü oluşturur.