Decision Gate v2: Çoklu AI ile Spec Tribunal

TL;DR

Tek bir AI'a 'bu iyi mi?' diye sormak, kendi sınav kağıdınıza not vermeniz gibidir. /court skill'i, Decision Gate'in 8 kriterini birden fazla (örnekte üç) ve bağımsız AI'a (Claude + Gemini + Kimi) adversarial modda değerlendirtir. Herhangi bir jüri Security veya Conflict'te FAIL verirse, karar otomatik KILL olur.

Hızlı Referans	Değer
Kurulum	Tek dosya, sıfır dependency
Jüri sayısı	1-3 (Claude + opsiyonel Gemini, Kimi)
Knockout kriterleri	Security, Conflict
Karar çıktıları	GO / DEFER / KILL
Kaynak	ceaksan/decision-gate

Decision Gate yazısında 8 kriterlik bir değerlendirme framework’ü tanımlamıştım. Framework işliyordu, ancak bir sorun vardı: değerlendiren de, önerilen de aynı AI’dı. Bu yapısal bir confirmation bias’tır.

Bu yazıyla birlikte Decision Gate’i açık kaynak bir araca dönüştürdüm. Ardından, bu aracı daha kapsamlı ve tutarlı bir yaklaşıma dönüştürmek amacıyla /court haline getirdim. Bir Claude Code skill’i olarak /court, birden fazla ve mümkünse bağımsız AI’ı adversarial modda çalıştırıyor ve SPEC değerlendirmesi yapıyor.

Sorun: Tek AI, Tek Perspektif

Bir AI’a spec yazdırıp aynı AI’a “bu spec iyi mi?” diye sorduğunuzda, yüksek ihtimalle “evet, iyi” yanıtı alırsınız. Bu rubber-stamp sorunudur.

Rubber stamp, mecazi anlamda bir kişi veya kurumun, herhangi bir kararı derinlemesine incelemeden, sorgulamadan, otomatik olarak onaylaması durumunu ifade eder. Politika yapıcılar, başkalarının emirlerini (üst makamlar, başka aktörler, vb.) meşrulaştıran “göstermelik” kurumlar veya kişiler için kullanılan bir ifadedir.

Bunu gerçek bir codebase audit’inde yaşadım. Üst üste aynı hatalar ve sorunlu yaklaşımlar sebebiyle (genelde üçüncü tekrarda) takip edilen yaklaşımı durdurur ve bu yaklaşımın kendisini analiz etmeye başlarım. Bu aşamada kendimi de dahil ettiğim, ancak paralelde farklı eğitimlere sahip AI’ları da dahil ederek ilerlerim. Eğer bir kararı tek bir AI’a değerlendirtsem, büyük ihtimalle 28’i de “GO” olurdu. Bunun yerine 3 bağımsız AI’a (kararlarını tutarlı gördüğüm, güncel modeller olarak; Claude, Gemini, Kimi) Decision Gate kriterlerini ayrı ayrı uygulattığımda:

Sonuç	Sayı	Anlamı
GO	22	Uygula
DEFER	4	Şimdiye değil, backlog’a al
KILL	2	Yapma

6 görev elendi veya ertelendi. Bu, tahminen günün bir bölümünü anlamsızca tüketecek kayıp çalışmanın önlenmesi anlamına geliyor.

Rubber-Stamp Neden Oluşur?

LLM’lerin değerlendirme yaparken düştükleri tipik tuzaklar:

Confirmation bias: Eğitildikleri veri bağlamında, kendi önerdiğini “iyi” bulma eğilimi
Sunk cost yanlılığı: “Zaten bu kadar yazıldı, iptal etmek israf” düşüncesi
Optimism bias: “Sorun çıkmaz” varsayımı, edge case’leri görmezden gelme
Consistency baskısı: Daha önce verdiği kararlara sadık kalma eğilimi, hataya rağmen
Task-driven evaluation: Hızlıca görevi tamamlayıp sonuca ulaşayım ve bir sonraki adıma geçeyim düşüncesi

Çözüm: değerlendirmeyi öneriden ayırmak ve birden fazla bağımsız perspektif almak. Bu yaklaşım, ADR ve OpenSpec yazısında tartıştığım karar yönetimi prensipleriyle de örtüşüyor: kararları belgelemek ve bağımsız değerlendirmeye açmak.

/court: Multi-AI Tribunal

/court, bir Claude Code skill’idir. /court yazarak tetiklenir, bir spec dosyası veya konu üzerinde Decision Gate değerlendirmesi yapar.

Mimari

/court docs/specs/my-feature.md
        |
        v
  1. Spec Quality Gate
     (Yeterli bilgi var mı?)
        |
        v
  2. Claude değerlendirmesi
     (8 kriter, orchestrator)
        |
        v
  3. Gemini değerlendirmesi (MCP)
     (Adversarial mod, security/performance focus)
        |
        v
  4. Kimi değerlendirmesi (MCP)
     (Adversarial mod, architecture/necessity focus)
        |
        v
  5. Sentez + veto kontrolü
        |
        v
  6. Verdict: GO / DEFER / KILL

Jüri Rolleri

Her AI farklı bir perspektif taşır:

AI	Rol	Odak
Claude	Orkestratör + Hakim	8 kriterin tamamı, nihai karar
Gemini	Güvenlik ve Performans Uzmanı	Derin teknik inceleme, adversarial mod
Kimi	Mimari ve Gereklilik Uzmanı	Geniş context analizi, yapısal kaygılar

Adversarial Protokol

Dış jüriler şu system prompt’uyla çalışır:

Bir teklifi inceleyen hostile bir senior mühendissiniz. İşiniz sorun bulmak, teklifi onaylamak değil. En az bir somut kaygı belirlemeniz veya “adversarial inceleme sonrası kaygı bulunamadı” diye açıkça belirtmeniz gerekiyor.

İngilizce kullanmak isterseniz;

You are a hostile senior engineer reviewing a proposal. Your job is to find problems, not to approve. You must identify at least one concrete concern or explicitly state “no concerns found after adversarial review”.

Bu, rubber-stamp’i yapısal olarak önler. Jürinin görevi onaylamak değil, saldırganca sorgulamaktır.

Veto Sistemi

Security ve Conflict kriterleri must-meet (knockout) olarak tanımlıdır. Herhangi bir jüri bu ikisinden birinde FAIL verirse:

Diğer skorlar ne olursa olsun
Ortalama ne kadar yüksek olursa olsun
Karar otomatik KILL olur

Bu, pazarlık edilemez bir kuraldır. Güvenlik ve uyumluluk taviz verilecek konular değildir.

Graceful Degradation

MCP tool’ları her zaman mevcut olmayabilir. /court bunu yumuşak geçişle yönetir:

Durum	Çalışma Modu
Hepsi mevcut	3 jürili tam tribunal
Sadece Gemini	2 jürili tribunal
Sadece Kimi	2 jürili tribunal
Hiçbiri yok	Solo değerlendirme (çıktıda açıkça belirtilir)

Kurulum

1. Skill’i Kur

mkdir -p ~/.claude/skills/court && curl -sL \
  https://raw.githubusercontent.com/ceaksan/decision-gate/main/SKILL.md \
  -o ~/.claude/skills/court/SKILL.md

2. (Opsiyonel) Jürileri Kur

Gemini ve Kimi MCP server’larını kurmak opsiyoneldir. Kurulmazlarsa Claude tek başına değerlendirir.

Gemini MCP:

npm install -g @anthropic-ai/gemini-mcp
claude mcp add gemini -s user -- gemini-mcp

Kimi MCP:

Kendi MCP server’ınızı yazabilir veya mevcut bir Kimi MCP implementasyonu kullanabilirsiniz.

3. (Opsiyonel) Proje Konfigürasyonu

Proje kökünüzde .court.yml oluşturun:

criteria:
  must_meet: [Security, Conflict]
  scored: [Benefit, Necessity, Burden, Performance, Bottleneck, Currency]
  threshold:
    go: 6
    defer: 4
jurors:
  gemini: true
  kimi: true
context_sources:
  - docs/architecture.md
  - CLAUDE.md

Kullanım

Spec Dosyası Değerlendirme

/court docs/specs/my-feature.md

Çıktı, dosyanın sonuna ## Court Verdict olarak eklenir.

Konu Değerlendirme

/court "Session storage için Redis cache eklemeli miyiz?"

Çıktı terminale yazdırılır, dosyaya yazılmaz.

Örnek Çıktı

## Court Verdict

**Tarih:** 2026-03-07
**Jüriler:** Claude (orkestratör), Gemini (güvenlik/performans)
**Karar:** DEFER
**Skor:** 5.3/10

| Kriter      | Claude | Gemini | Ort  |
| ----------- | ------ | ------ | ---- |
| Security    | PASS   | PASS   | PASS |
| Conflict    | PASS   | PASS   | PASS |
| Benefit     | 7      | 6      | 6.5  |
| Necessity   | 4      | 3      | 3.5  |
| Burden      | 5      | 4      | 4.5  |
| Performance | 7      | 7      | 7.0  |
| Bottleneck  | 6      | 5      | 5.5  |
| Currency    | 6      | 5      | 5.5  |

### Muhalif Görüşler

- **Gemini:** Necessity skoru 3. Mevcut in-memory cache yükü karşılamaya yetiyor. Redis operasyonel karmaşıklık ekliyor, kanıtlanmış bir ihtiyaç yok.

### Gerekçeler

Redis caching performansı iyileştirir ancak mevcut yük bunu gerektirmiyor. p99 latency SLA eşiklerini aştığında yeniden değerlendirilmeli.

Neden Bu Yaklaşım?

Alternatifler ve Neden Seçilmediler

Yaklaşım	Avantaj	Dezavantaj	Karar
CLI aracı	Separation of concerns	Yeni dependency, build step, bakım yükü	Reddedildi
MCP server	Standart protokol	Over-engineering, gereksiz karmaşıklık	Reddedildi
Claude Code skill	Sıfır dependency, tek dosya	Claude’a bağlı	Seçildi

Skill yaklaşımı, solo developer için en düşük burden’ı sunar: tek bir markdown dosyası, build step yok, dependency yok. ~/.claude/skills/court/SKILL.md kopyalanır, /court yazılır, çalışır.

MCP: AI’lar Arası İletişim Katmanı

Model Context Protocol (MCP), Claude Code’un dış araçlarla iletişim kurmasını sağlayan standart bir protokoldür. Bu bağlamda MCP, Claude’un Gemini ve Kimi’yi “çağırmasına” olanak tanır.

Claude Code
    |
    |-- mcp__gemini__gemini-query --> Gemini
    |
    |-- mcp__kimi__kimi_query --> Kimi

Her jüri bağımsız olarak değerlendirir. Claude sonuçları sentezler ve karar önerisini sunar.

Tasarım Kararları

Neden 3 AI?

Tek AI confirmation bias oluşturur. İki AI’da bile “çoğunluk” kavramı zayıftır. Üç AI ile:

Herhangi ikisi aynı yönde ise, güçlü sinyal
Üç farklı görüş varsa, dikkatli inceleme gerektiren bir durum
Bir AI farklı düşünüyorsa, bu “muhalif görüş” olarak kaydedilir

Neden Adversarial?

“Bu öneriyi değerlendir” demek ile “bu önerideki sorunları bul” demek arasında önemli bir fark vardır. İlki olumlu yanıt eğilimi yaratır, ikincisi eleştiri odaklı düşünmeyi tetikler.

Adversarial protokol, jürilere açıkça “sorun bul” talimatını verir. Bu, rubber-stamp oranını yapısal olarak düşürür.

Neden Veto?

Güvenlik ve uyumluluk konuları skorlanabilir değerlendirmelere tabi tutulmamalıdır. Bir endpoint’te auth bypass varsa, faydası 10/10 olsa bile karar KILL olmalıdır. Must-meet kriterlerin veto gücü, bu gerçeği yansıtır.

Neden Red Team/Blue Team Değil?

Bu yazının taslağını /court ile değerlendirdiğimde, jürilerden biri (Kimi) alternatif bir mimari önerdi: Red Team/Blue Team yaklaşımı. Blue Team (Claude) çözüm önerir, Red Team (Gemini) yalnızca saldırır, deterministik bir kural motoru ise nihai kararı verir. Böylece sentez katmanındaki bias riski tamamen ortadan kalkar.

Bu öneriyi yine Decision Gate kriterleriyle değerlendirdim:

Kriter	Değerlendirme	Sonuç
Benefit	Sentez bias’ını yapısal olarak çözer	8/10
Necessity	Mevcut veto sistemi Security/Conflict için zaten deterministik	4/10
Burden	Ayrı bir kural motoru = yeni dependency, build step, bakım yükü	3/10
Conflict	Tek dosya, sıfır dependency tasarım kararıyla doğrudan çelişir	FAIL

Karar: KILL. Conflict kriterinde FAIL olduğu için veto kuralı devreye girer. Platform ölçeğinde doğru bir mimari eleştiri, ancak solo developer için tek dosya skill’ini platform mimarisine dönüştürmek, çözdüğünden daha büyük bir sorun yaratır.

Bu değerlendirmenin kendisi, /court sisteminin çalıştığının bir göstergesidir: bir jüri alternatif önerdi, öneri aynı framework ile değerlendirildi ve veto kuralıyla elendi.

Sınırlılıklar

Claude’a bağımlılık: Skill yalnızca Claude Code’da çalışır. Diğer AI IDE’lerinde kullanılabilmesi için adaptasyon gerekir.
MCP kurulumu: Gemini ve Kimi MCP server’larının kurulması ek adım gerektirir. Ancak opsiyoneldir.
Sentez katmanı riski: Claude öneriyi getirir, jürilere iletir ve sonuçları sentezler, ancak nihai kararı veren insandır. Risk, sentez aşamasındadır: Claude jüri çıktılarını özetlerken kendi değerlendirmesine yakın bir anlatı oluşturabilir. Bu nedenle jürilerin ham çıktılarını sentezden bağımsız olarak incelemek önemlidir.
Görece bağımsızlık: “Bağımsız AI’lar” ifadesi görece bir bağımsızlıktır. Tüm modeller benzer web verisiyle eğitilmiş olup benzer alignment eğilimleri taşır. Adversarial mod, prompt engineering düzeyinde bir ayrışmadır, yapısal bağımsızlık değildir. Bu nedenle sistematik kör noktalar (ör. ortak eğitim verisinden kaynaklanan) jüriler arasında korelasyon gösterebilir.
Subjektif skorlama: AI’ların verdiği 1-10 skorları deterministik değildir. Aynı spec için farklı çalıştırmalarda farklı skorlar çıkar. Bu, genel eğrilimi yakalamak için yeterlidir, kesin sayı olarak ele alınmamalıdır.
Context sınırı: Çok büyük spec dosyaları, özellikle Gemini ve Kimi’nin context limitlerini zorlayabilir.

Sonuç

Decision Gate’in ilk versiyonu bir mental checklist’ti: 8 kriter, 30 saniyede değerlendirme. Bu versiyonda framework’ü bir araca dönüştürdüm:

Tek AI yerine 3 bağımsız AI ile adversarial değerlendirme
Veto sistemi ile güvenlik ve uyumlulukta taviz yok
Graceful degradation ile MCP olmasa da çalışır
Açık kaynak ve tek dosya kurulumu

GitHub: ceaksan/decision-gate

Kurulum:

mkdir -p ~/.claude/skills/court && curl -sL \
  https://raw.githubusercontent.com/ceaksan/decision-gate/main/SKILL.md \
  -o ~/.claude/skills/court/SKILL.md

Decision Gate serisindeki diğer yazılar:

Decision Gate: Vibe Coding’in Eksik Parçası (framework tanıtımı)
ADR, OpenSpec ve Spec-Driven Development: Court’un ADR çıktısının ve spec-first yaklaşımın karar süreciyle ilişkisi
LLM’lerin Davranışsal Bozulma Modları: Multi-AI tribunal’ın adreslemek istediği pozisyon yanlılığı ve diğer bozulma modları
AI Agent Protokolleri Rehberi: A2A protokolünün multi-agent iletişimi standartlaştırması, tribunal yapısıyla ilişkisi

Önemli Noktalar

01 Tek AI değerlendirmesi rubber-stamp riski taşır; birden fazla ve bağımsız AI adversarial modda çalıştırıldığında daha kaliteli kararlar çıkar
02 /court skill'i Claude Code'a tek dosya kopyalayarak kurulur, hiçbir dependency gerektirmez
03 Jüriler MCP (Model Context Protocol) üzerinden çağrılır; Gemini ve Kimi opsiyoneldir, yoksa Claude tek başına değerlendirir
04 Gerçek bir codebase audit'inde 28 görevden 6'sı bu sistemle elenmiş veya ertelenmiştir

Sık Sorulan Sorular (FAQ)

+ /court nedir?

/court, Claude Code için bir skill'dir (slash command). Spec dosyalarını veya teknik kararları Decision Gate framework'ünün 8 kriteri üzerinden değerlendirir. Opsiyonel olarak Gemini ve Kimi'yi bağımsız jüri olarak ekler.

+ Neden birden fazla AI kullanılıyor?

Tek bir AI'a hem öneri hem değerlendirme yaptırmak confirmation bias yaratır. Farklı modeller farklı zayıf noktaları yakalar: Gemini güvenlik ve performansta, Kimi mimari ve gereklilik analizinde daha güçlü sonuçlar verir.

+ MCP nedir ve neden gerekli?

Model Context Protocol, Claude Code'un dış araçlarla iletişim kurmasını sağlayan standart bir protokoldür. Gemini ve Kimi, MCP server'ları üzerinden jüri olarak çağrılır. MCP kurulu değilse, Claude tek başına değerlendirir.

+ Veto sistemi nasıl çalışır?

Security ve Conflict kriterleri must-meet (knockout) olarak tanımlanır. Herhangi bir jüri bu iki kriterden birinde FAIL verirse, diğer skorlar ne olursa olsun karar otomatik olarak KILL olur.

+ Kendi projemde nasıl kurarım?

mkdir -p ~/.claude/skills/court && curl -sL https://raw.githubusercontent.com/ceaksan/decision-gate/main/SKILL.md -o ~/.claude/skills/court/SKILL.md komutu ile kurulur. Opsiyonel olarak proje kökünde .court.yml ile konfigüre edilir.

developer-tools ai