İnsan Her Kapıda Duramaz: Filtreyi Otomatikleştirmek
Bu yazıda anlattığım kalite kapısı sistemini, herhangi bir yapay zeka aracına — Claude Code, Cursor, Copilot, Windsurf, doğrudan chat — besleyebileceğiniz taşınabilir bir github gist dosyası olarak hazırladım. Oturumunuzun başında bu gist’i bağlam olarak verdiğinizde, agent kapı sistemini otomatik olarak uygulamaya başlıyor. Gist’e buradan erişebilirsiniz: AI Workspace Memory & Quality Gate System
İlk yazıda denklemi kurmuştum. Her yapay zeka çıktısı sinyal ve gürültünün bileşimi, ve insanın filtreleme fonksiyonu F(B(t)) (filtreleme gücü, insanın bilgi seviyesine bağlı) gürültünün ne kadarının projeye gireceğini belirliyor. İkinci yazıda o denklemi bir katman geriye taşımıştım — planlamanın kendisinin de gürültü kaynağı olduğunu, Ask → Plan → Agent pipeline’ının planlama zincirinin başındaki gürültüyü düşürdüğünü göstermiştim.
Ama iki yazının da çözümsüz bıraktığı bir gerilim var. Denklem diyor ki: her adımda filtrele. Gerçek diyor ki: insan her adımda filtreleyemez.
Bu sadece bir zaman problemi değil. İnsan dikkati sonlu bir kaynaktır. Sabah saat dokuzda F(B(t)) (filtreleme fonksiyonu) değeriniz yüksek olabilir — kafanız açık, bağlam taze, eleştirel düşünce keskin. Öğleden sonra beşte, dördüncü büyük görevin üçüncü iterasyonunun ikinci çıktısını kontrol ederken F (filtre) dramatik biçimde düşer. Dikkat dağılır, “bu doğru görünüyor” refleksi devreye girer, gürültü filtrelenmeden geçer.
Ve işte bu noktada çoğu kişi iki yoldan birine sapıyor. Birincisi vazgeçmek: “yapay zekaya güvenmek lazım, her şeyi kontrol edemem” deyip kapıları kaldırmak. İkincisi tükenmek: her çıktıyı satır satır kontrol etmeye çalışıp bir süre sonra ya yavaşlamak ya da kontrolü bırakmak. İkisi de aynı yere çıkıyor — filtresiz geçiş, kümülatif gürültü, projenin epistemik temelinin sessizce çürümesi.
Üçüncü bir yol var: filtreyi insanın anlık dikkatine bağımlı olmaktan çıkarıp sistematize etmek. F(B(t))’yi bir kişinin kafasındaki bilgi olmaktan çıkarıp, taşınabilir, tekrarlanabilir, her oturumda ve her araçta çalışan bir yapıya dönüştürmek.
Bu yazı o üçüncü yolu anlatıyor.
Bilgiyi Kodlamak: F(B(t))’den F(G)’ye
İlk yazıdaki denklemi hatırlayın:
Katkı(t) = S(t) + N(t) · (1 − F(B(t)))
F (filtre), insanın filtreleme kapasitesi. B(t) (bilgi seviyesi), insanın o andaki alan bilgisi. S(t) (sinyal), çıktının doğru ve işe yarayan kısmı. N(t) (gürültü), çıktının hatalı veya bağlamdan kopuk kısmı. B(t) yüksekse gürültü elenir, düşükse geçer. Ama B(t)’nin bir problemi var: uçucu. İnsanın kafasında yaşıyor. Yorgunlukla düşüyor, dikkat dağılmasıyla düşüyor, bağlam değişimiyle düşüyor. Dün gece ödeme sisteminin edge case’lerini derinlemesine biliyordunuz, bugün sabah bambaşka bir modülde çalışıyorsunuz — B(t) o ödeme sistemi için geçici olarak düştü, ama siz farkında değilsiniz.
Çözüm, B(t)’nin kalıcı kısmını — alan bilgisini, proje kısıtlarını, mimari kararları, anti-pattern’leri, sınırları — bir dokümana yazmak. Bu doküman her oturum başında yapay zekaya verildiğinde, filtreleme fonksiyonu artık sadece insanın anlık dikkatine değil, kodlanmış bilgiye de dayalı hale gelir:
Katkı(t) = S(t) + N(t) · (1 − F(B(t), G))
G (kodlanmış bilgi), gist, kural dosyası, proje hafızası, ne derseniz deyin. G sabit. Yorulmaz, dikkati dağılmaz, unutmaz. İnsan yorulduğunda B(t) (bilgi seviyesi) düşer ama G (kodlanmış bilgi) hâlâ orada. Model G’yi okuduğunda, olasılık uzayı daralmıştır — projeye uygun olmayan çıktılar üretme ihtimali azalmıştır. G (kodlanmış bilgi) tek başına F’yi (filtre) 1’e çıkarmaz — hâlâ insanın nihai onayı gerekir — ama F’nin alt sınırını yükseltir. İnsanın kötü bir günü bile, G olmayan bir insanın iyi gününden daha iyi filtreler.
Ama burada durup bir uyarı yapmam gerekiyor. G (kodlanmış bilgi) yi yazmak, “şu kuralları takip et” yazmak değil. G’nin değeri, projenin gerçek bağlamını — neyi neden yaptığınızı, neyi yapmadığınızı, hangi kararları hangi gerekçeyle aldığınızı — yapay zekanın anlayabileceği biçimde kodlamaktan gelir. “Temiz kod yaz” yazmak G değil, gürültü. “Bu projede repository pattern kullanıyoruz çünkü X, service layer’da iş mantığı Y şekilde organize ediliyor çünkü Z, şu anti-pattern’i kullanma çünkü geçmişte W sorununa yol açtı” yazmak G’dir.
Ama G(kurallar) Yetmez: Aktif Kapılar
Kodlanmış bilgi F’nin (filtre) alt sınırını yükseltir ama kendi başına yeterli değil. Bir dokümanın okunması, modelin olasılık uzayını daraltır — ama o daraltılmış uzay içinde hâlâ gürültü üretebilir. Kuralları bilmek ile her adımda kurallara uygunluğu kontrol etmek farklı şeyler.
Bunu gerçek hayattan düşünün. Bir fabrikada kalite el kitabı yazmak, ürünleri kontrol etmek anlamına gelmez. El kitabı bilgiyi kodlar — ama kalite kontrol istasyonları o bilgiyi her parça üzerinde uygular. El kitabı G (kodlanmış bilgi) dir, kontrol istasyonları aktif kapılardır.
Yapay zeka ile çalışırken de aynı ayrım geçerli. G (kodlanmış bilgi) modelin başlangıç bağlamını temizler. Ama uygulama zincirinin her adımında, modelin çıktısının gerçekten o bağlamla uyumlu olup olmadığını kontrol eden aktif mekanizmalar gerekir. Ve bu mekanizmaların insanın anlık dikkatine bağımlı olmaması — yani otomatik çalışması — gerekir.
İşte burada kalite kapısı sistemi devreye giriyor. Üç kapı ve bir meta-kontrol.
Meta-Kontrol: İterasyon Büyüklüğü Değerlendirmesi
Kapılardan önce gelen bir soru var: bu görev tek bir iterasyonda yapılacak kadar küçük mü?
İlk yazıda 500 satır vs 30 satır örneğini vermiştim. Büyük iterasyonlarda F (filtre) düşer çünkü dikkat dağılır, karmaşıklık artar, gürültü sinyalin arasına gizlenir. Ama orada bunu insanın bilinçli tercihine bırakmıştım — “adımlarını küçük tut” demiştim. Problem şu ki insan her zaman bilinçli tercih yapmaz. Bazen görevin büyüklüğünü hafife alır, bazen acele eder, bazen “bir seferde halledelim” dürtüsüne kapılır.
Bunu sistematize etmek demek, yapay zekanın kendisinin görev büyüklüğünü değerlendirmesi ve büyük görevi küçük adımlara bölmesi demek. Ama bu değerlendirme sessiz olmamalı — model kendi düşünce sürecini insana açıkça göstermeli.
Agent bir görev aldığında, uygulamaya geçmeden önce şu soruları sormalı: Kaç dosya/bileşen etkileniyor? Kaç bağımsız karar gerekiyor? Gereksinimlerdeki belirsizlik derecesi ne? Bu görev birden fazla katmanı/servisi kesiyor mu?
Eğer görev belirli bir karmaşıklık eşiğini geçiyorsa, agent direkt uygulamaya geçmemeli. Görevi alt adımlara bölmeli, bu bölümü insana sunmalı ve onay almalı. Bu, ilk yazıdaki “kaptan rotayı çizip dümeni bırakma” analojisinin otomatize edilmiş hali. Model kendiliğinden diyor ki: “Bu rota uzun, ara limanlara uğramamız lazım — şöyle bir plan öneriyorum.”
Ve burada şeffaflık kritik. Model sadece “görevi böldüm” dememeli — neden böldüğünü, karmaşıklığı nasıl değerlendirdiğini, hangi kriterlerin eşiği aştığını göstermeli. Çünkü insan ancak düşünce sürecini görürse, o değerlendirmenin kendisini filtreleyebilir. Belki model gereksiz yere bölmüştür — insan “hayır, bu yeterince küçük, devam et” diyebilmeli. Belki yeterince bölmemiştir — insan “bu adım hâlâ büyük, daha da parçala” diyebilmeli.
Birinci Kapı: Bağlam Yeterliliği Kontrolü
Görevin büyüklüğü değerlendirildi, adımlar belirlendi. Şimdi ilk adıma geçilecek. Ve tam burada, ilk satır çıktı üretilmeden önce, ilk kapı çalışmalı: Elimdeki bağlam bu görevi yapmama yeter mi?
Bu soru trivial gibi görünüyor ama değil. Yapay zekanın en tehlikeli özelliklerinden biri, bilmediği şeyleri güvenli bir şekilde uyduruyor olmasıdır. Bağlamda olmayan bir bilgiyi genel eğitim verisinden çeker, projeye özgü bir karar gibi sunar, ve çıktı formatı o kadar profesyoneldir ki insan bunu fark etmez. Bu, ilk yazıdaki “gürültü en tehlikeli haliyle değil, en ikna edici haliyle gelir” noktasının tam karşılığı.
Context gate şunu yapıyor: agent, görevle ilgili tüm bağlam dosyalarını okuduktan sonra, kendine “bu görevi yapmak için yeterli bilgiye sahip miyim” diye soruyor. Ve cevabı insana açıkça raporluyor.
Bunu somutlaştırayım. Bir ödeme entegrasyonu yapılacak. Agent proje dosyalarını okudu — mimariyi biliyor, kod pattern’lerini biliyor, domain modeli elinde. Ama görev Iyzico’nun 3D Secure akışını gerektiriyor ve Iyzico’nun hata kodları hiçbir bağlam dosyasında yok. Agent’ın iki seçeneği var: ya Iyzico hata kodlarını genel eğitim verisinden tahmin edip devam eder — bu gürültü üretir — ya da durur ve der ki: “Proje mimarisini ve kod kurallarını anlıyorum, ama Iyzico’nun hata kodları ve rate limit’leri bağlamda yok. Bu bilgi olmadan error handling yazarsam varsayıma dayalı olacak. Bu bilgiyi sağlayabilir misiniz?”
İkinci seçenek insana üç saniyeye mal olur. Birinci seçenek, hatalı error handling üretimde patladığında saatlere mal olur.
Context gate’in değeri burada: gürültüyü üretildikten sonra filtrelemek yerine, üretilmeden önce engelliyor. Proaktif filtreleme, reaktif filtreden çarpımsal olarak daha verimli. Çünkü gürültü bir kez bağlama girdikten sonra, sonraki her adımın bağlamını zehirliyor — ama hiç girmezse zincir temiz kalıyor.
Ve bu kapının bir yan faydası daha var: insanın kendi bilgi boşluklarını keşfetmesini sağlıyor. Agent “şu bilgi eksik” dediğinde, bazen insan “doğru, bunu ben de bilmiyordum, araştırmam lazım” diyor. Context gate sadece modelin değil, insanın B(t) (bilgi seviyesi) sini de yükseltiyor.
İkinci Kapı: Sinyal/Gürültü Oranı Değerlendirmesi
Context gate geçildi, bağlam yeterli. Agent çıktı üretti. Şimdi o çıktının kalitesini değerlendirmek lazım — ama bunu insanın satır satır okumasına bırakmak yerine, modelin kendisinin yapmasını istiyoruz.
Bu, F(B(t)) (filtreleme fonksiyonu) yi yükseltmenin ikinci yolu: insanın filtreleme yükünü azaltmak için modeli kendi filtreleme sürecine dahil etmek. Model mükemmel bir filtre değil — kendini de yanıltabilir — ama hiç filtre olmamasından kat kat iyi. Ve modelin kendi çıktısını değerlendirmesi, insanın dikkatini kritik noktalara yönlendiriyor: insan her satırı kontrol etmek yerine, modelin “buradan emin değilim” dediği yerlere odaklanıyor.
Sinyal/gürültü kapısı üç farklı yöntemle çalışıyor. Üçü de aynı şeyi farklı açılardan ölçüyor ve birlikte kullanıldığında tek başlarına yakalayamayacakları sorunları yakalıyorlar.
Birinci yöntem: öz-değerlendirme. Agent kendi çıktısına bakıp “hangi kısımlar verilen bağlamdan türetildi, hangileri varsayıma dayalı” diye soruyor. Bu basit bir ayrım ama güçlü. Bir ödeme servisi yazarken “strategy pattern kullanıyorum çünkü codegen.md’de bu pattern tanımlı” diyorsa bu bağlam-temelli bir karar — sinyal. Ama “timeout değerini 30 saniye olarak ayarladım” diyorsa ve bu değer hiçbir bağlam dosyasında yoksa, bu varsayım — potansiyel gürültü. Varsayım oranı belirli bir eşiği geçerse, agent duruyor ve insana soruyor.
İkinci yöntem: güven skorlaması. Agent çıktısının her bileşenine bir güven skoru veriyor. Veri modeli %92 güvenle doğru çünkü model.md’de net tanımlanmış. Servis mantığı %81 çünkü pattern açık ama bazı edge case’ler belirsiz. Error handling %55 çünkü Iyzico hata kodları tam dokümante edilmemiş. Webhook doğrulaması %48 çünkü HMAC implementasyonu genel bilgiden varsayılmış.
Bu skorlar insana neyi kontrol etmesi gerektiğini söylüyor. %92 güvenli veri modelini satır satır incelemek yerine, %48 güvenli webhook doğrulamasına odaklanmak — bu, insanın sınırlı dikkat kaynağını en verimli şekilde kullanması demek. F(B(t)) (filtreleme fonksiyonu) nin alt sınırı yükseliyor çünkü insan dikkatini boşa harcamıyor, kritik noktalara yoğunlaştırıyor.
Üçüncü yöntem: bağlam-çıktı uyumu. Bu en teknik olanı. Agent çıktısındaki her kararı, bağlamda somut bir karşılığı olup olmadığına göre sınıflandırıyor. “Strategy pattern kullan” — codegen.md satır 34’ten geliyor, temelli. “PaymentTransaction entity’si status enum ile” — model.md satır 78’den geliyor, temelli. “3 saniyelik polling interval” — hiçbir kaynakta yok, temelsiz.
Temelsiz kararların oranı, çıktının gürültü yoğunluğunun bir ölçüsü. Oran yüksekse kapı kapanıyor.
Üç yöntem birlikte bir bileşik skor üretiyor. Herhangi biri eşiği aşarsa, ya da ikisi aynı bileşen hakkında uyarı veriyorsa, kapı kapanıyor ve insan müdahalesi isteniyor. Bu sistem mükemmel değil — model kendi hatalarını her zaman yakalayamaz — ama kritik olan şu: insanın yapacağı işin %80’ini otomatize ediyor. İnsan sadece kalan %20’ye odaklanıyor. Ve o %20, zaten en kritik %20.
Üçüncü Kapı: Sapma Kontrolü
İlk iki kapı tek bir adıma bakıyor — girdi yeterli mi, çıktı kaliteli mi. Ama çok adımlı bir zincirde, her adım kendi başına temiz geçebilir ve yine de zincir bir bütün olarak hedeften sapmış olabilir. Bu, ilk yazıdaki kümülatif gürültü probleminin farklı bir tezahürü.
Bunu bir yürüyüş analojisiyle düşünün. Her adımda iki derece sağa sapıyorsunuz. Tek bir adımda bu fark edilmez — neredeyse düz yürüyorsunuz. On adımda yirmi derece — hâlâ hedefe doğru gidiyormuş gibi hissediyorsunuz. Yüz adımda iki yüz derece — tamamen ters yöne dönmüşsünüz. Ve her adımda “bu adım doğru” demiştiniz — çünkü tek başına bakıldığında doğruydu.
Drift gate bu birikimli sapmayı yakalıyor. Agent her adımda şunu kontrol ediyor: orijinal hedef ne? Onaylanan plan ne? Önceki adımların toplamı beni nereye getirdi? Bu adımın çıktısı beni hedefe yaklaştırıyor mu?
Somut bir örnek. Hedef: “Kullanıcı kimlik doğrulamasını SSO destekleyecek şekilde refactor et.” Plan beş adım. İlk iki adım düzgün gidiyor — SSO provider konfigürasyonu ve SAML response parsing. Üçüncü adımda agent JWT refresh mantığı ekliyor — ilgili ama planda yok. Dördüncü adımda session store’u sıfırdan yeniden yazıyor — plan “mevcut store’u genişlet” diyordu.
Her adım tek başına teknik olarak doğru olabilir. JWT refresh mantığı iyi yazılmış, session store yeni haliyle daha temiz. Ama plandaki hedeften sapmış. Kapsam genişlemiş. Ve her kapsam genişlemesi, gerçekleştirme sürecine yeni gürültü kaynakları ekliyor — test edilmemiş senaryolar, düşünülmemiş etkileşimler, beklenmeyen yan etkiler.
Drift gate burada durup diyor ki: “Üçüncü ve dördüncü adımlar onaylanan plandan saptı. Üçüncüde kapsam eklentisi var, dördüncüde plan değişikliği var. Devam etmeden önce insan onayı gerekiyor.”
Bu kapı özellikle uzun zincirlerde kritik. İlk birkaç adımda sapma küçük ve zararsız görünür — “evet, bu da güzel bir eklenti” diye geçilir. Ama beşinci adımda birikim öyle bir noktaya gelir ki projenin yarısını geri sarmanız gerekir. Drift gate bu birikimi her adımda ölçerek, küçükken müdahale etmenizi sağlıyor.
Şeffaflık: Kara Kutudan Cam Kutuya
Bu kapı sisteminin tamamını bir araya getiren prensip şeffaflık. Agent hiçbir kapıyı sessizce geçmemeli ya da sessizce kapatmamalı. Her değerlendirme, her skor, her karar insana açıkça raporlanmalı.
Neden? Çünkü kapı sisteminin kendisi de bir filtre — ve her filtre hata yapabilir. Model kendi bağlam boşluğunu fark etmeyebilir, güven skorunu olduğundan yüksek verebilir, sapmayı hafife alabilir. Şeffaflık, insanın meta-filtre olarak çalışmasını sağlıyor: insanın her çıktıyı satır satır incelemesine gerek yok, ama kapı sisteminin değerlendirmelerini kontrol edebiliyor.
Bu, dikkat ekonomisinin verimli kullanımı. Kapılar olmadan insan her şeyi kontrol etmeli — sürdürülemez. Kapılar şeffaf olmadan insan hiçbir şeyi kontrol edemiyor — kara kutuya güvenmek zorunda. Şeffaf kapılarla insan, dikkatini kapıların bayrak diktiği noktalara yoğunlaştırıyor — sürdürülebilir ve etkili.
Bunu pratikte şöyle düşünün. Agent beş adımlık bir görevin üçüncü adımını tamamladı. İnsana şu raporu sunuyor:
İterasyon büyüklüğü kontrol edildi, bu adım tek bir servis katmanına odaklı, yeterince küçük. Bağlam yeterli, tüm gerekli bilgi mevcut. Sinyal/gürültü değerlendirmesi geçti ama iki varsayım işaretlendi, ikisi de düşük riskli. Sapma kontrolü küçük bir kapsam eklentisi tespit etti, karar bekleniyor.
İnsan bu raporu beş saniyede okuyor. Dört maddeden üçü sorunsuz — geçiyor. Biri karar bekliyor — ona odaklanıyor. Beş saniyede, çıktının tamamını okumadan, neyin kritik olduğunu biliyor. Bu, F(B(t)) (filtreleme fonksiyonu) nin pratikte nasıl yüksek tutulduğunun somut mekanizması.
Ve şeffaflığın bir yan faydası daha var: öğretici. İnsan zamanla kapı raporlarından pattern’ler çıkarmaya başlıyor. “Bu tür görevlerde hep context eksik kalıyor, demek ki bağlam dosyasını güncellemem lazım.” “Agent hep şu bileşende düşük güven veriyor, demek ki o alanın dokümantasyonu zayıf.” Şeffaflık sadece anlık kontrolü değil, uzun vadeli iyileştirmeyi de besliyor.
Filtreyi Taşınabilir Kılmak: Gist Yaklaşımı
Buraya kadar kapı sistemini tanımladım ama bir soru cevapsız kaldı: bu kurallar nerede yaşıyor ve nasıl taşınıyor?
Eğer bu kuralları her konuşmada, her IDE’de, her projede sıfırdan tanımlamanız gerekiyorsa, sistem sürdürülemez. Sabah Claude Code’da çalışıyorsunuz, öğleden sonra Cursor’a geçiyorsunuz, akşam doğrudan claude.ai’de bir şey soruyorsunuz — her birinde kapı sistemi sıfırdan mı kurulacak?
Çözüm, kapı sistemini ve proje bilgisini birlikte taşıyan, her ortamda okunabilen bir yapı — bir gist. Gist, GitHub’ın sunduğu basit bir paylaşım mekanizması: tek bir URL üzerinden erişilebilen, versiyonlanan, herkesin okuyabileceği bir metin dosyası. Kod parçası paylaşmak için tasarlanmış ama aslında herhangi bir yapılandırılmış metni — kuralları, protokolleri, bağlam dosyalarını — taşımak için mükemmel bir araç. Bir gist’in URL’sini herhangi bir yapay zeka aracına verdiğinizde, araç o URL’yi okuyup içindeki talimatları uygulayabiliyor. Yani gist, kapı sisteminizi ve proje bilginizi tek bir link üzerinden her konuşmaya, her IDE’ye, her oturuma taşıyan portatif bir hafıza birimi.
Bu gist, projenizin .ai/ dizininde yaşıyor ve her AI aracı oturuma başlarken onu okuyor.
Yapı şöyle çalışıyor. Her projenin kök dizininde bir .ai/ klasörü var. Bu klasörde projenin ne olduğunu, nasıl çalıştığını, hangi kuralları izlediğini, hangi kararları aldığını anlatan dosyalar var. Ve en başta, agents.md dosyası var — bu, herhangi bir yapay zeka aracının o projeye girdiğinde okuması gereken ilk dosya. agents.md entry protocol’ü tanımlıyor: hangi dosyaları hangi sırayla oku, kendini nasıl tanımla, neleri yapabilirsin neleri yapamazsın, kapı sistemi nasıl çalışır.
Bu yaklaşımın gücü, IDE/araç bağımsız olması. Claude Code için CLAUDE.md dosyasına “önce .ai/agents.md’yi oku” yazıyorsunuz. Cursor için .cursor/rules/ altına aynı yönlendirmeyi koyuyorsunuz. Copilot için .github/copilot-instructions.md’ye. Her araç kendi bridge dosyası üzerinden aynı merkezi bilgiye erişiyor. Bilgi bir yerde yaşıyor, her araç oraya yönlendiriliyor.
Pratikte nasıl kullanılıyor? Herhangi bir yapay zeka aracında — Claude, ChatGPT, Cursor, Claude Code, fark etmez — oturumunuzun başında şu prompt’u veriyorsunuz:
Şu gist'i oku ve bu oturum boyunca içindeki kalite kapısı sistemini uygula:
https://gist.github.com/mikailcetinkaya/226e09df63056b0523a1f2533ee2f3db
Görevim: [görev tanımınız]
Bu kadar. Agent gist’i okuyor, kapı sistemini anlıyor ve çalışmaya o kurallara göre başlıyor. İlk iş olarak iterasyon büyüklüğünü değerlendiriyor, context gate’i çalıştırıyor, her çıktıda S/N oranını raporluyor, adımlar arasında sapma kontrolü yapıyor. Siz kapı raporlarını okuyup onaylıyor ya da müdahale ediyorsunuz. Aynı gist’i sabah Cursor’da, öğleden sonra Claude Code’da, akşam doğrudan chat’te kullanabilirsiniz — her yerde aynı kapı sistemi çalışır.
Ve bu bilgi git’te versiyonlanıyor. Ekip üyesi bir mimari karar aldığında decisions.md’ye ekliyor. Yeni bir anti-pattern keşfedildiğinde codegen.md güncelleniyor. Bir API kontratı değiştiğinde contracts.md güncelleniyor. Her güncelleme commit’leniyor, review ediliyor, onaylanıyor — tıpkı kod gibi. Projenin bilgi temeli, kodun yanında, aynı disiplinle yönetiliyor.
Denklemin Evrimi
İlk yazıda denklem şuydu:
Katkı(t) = S(t) + N(t) · (1 − F(B(t)))
İnsanın bilgisine dayalı, anlık, kırılgan bir filtre.
İkinci yazıda o denklemi planlama zincirine taşıdım — gürültüyü sadece uygulama zincirinin değil, planlama zincirinin başında da düşürmek gerektiğini gösterdim.
Bu yazıda denklem evrildi:
Katkı(t) = S(t) + N(t) · (1 − F(B(t), G, Q(t)))
G (kodlanmış bilgi) — gist, proje hafızası, taşınabilir bağlam. Q(t) (kalite kapıları) — context gate, S/N gate, drift gate. F (filtre) artık üç bacaklı: insanın anlık dikkati B(t) (bilgi seviyesi), kodlanmış bilgi G, ve otomatik kalite kontrolleri Q(t). Herhangi bir bacak zayıflasa bile diğer ikisi telafi ediyor.
İnsan yorulduğunda B(t) (bilgi seviyesi) düşer — ama G (kodlanmış bilgi) ve Q(t) (kalite kapıları) hâlâ çalışır. Bağlam dosyaları eksik olduğunda G zayıflar — ama B(t) ve Q(t) telafi eder. Kapı sistemi bir hatayı kaçırdığında Q(t) eksik kalır — ama B(t) ve G yakalar. Tek noktadan arıza yok.
Pratikte Ne Değişir?
Somut bir senaryo düşünün. Bir geliştirici sabah işe başlıyor, ödeme sistemi entegrasyonu yapacak.
Kapı sistemi olmadan: IDE’yi açıyor, “Iyzico entegrasyonu yap” diyor. Model genel bir implementasyon üretiyor. Geliştirici çıktıyı gözden geçiriyor, “iyi görünüyor” diyor, projeye dahil ediyor. Üç gün sonra üretimde 3D Secure callback’i patlıyor — model HMAC doğrulamasını genel bilgiden varsaymıştı, projenin middleware yapısıyla uyumsuzdu. Geliştirici geri dönüp düzeltmeye çalışıyor ama o sırada üzerine iki iterasyon daha inşa edilmiş, hepsini sökmek gerekiyor.
Kapı sistemiyle: IDE’yi açıyor, aynı talimatı veriyor. Meta-kontrol devreye giriyor — “bu görev beş bileşeni etkiliyor, beş alt adıma bölüyorum, onay verin.” Geliştirici onaylıyor. İlk adıma geçiliyor, context gate çalışıyor — “Iyzico hata kodları ve webhook doğrulama detayları bağlamda yok, bu bilgi lazım.” Geliştirici Iyzico dokümanını sağlıyor. Agent çıktı üretiyor, S/N gate çalışıyor — “webhook HMAC implementasyonu %48 güvenle yazıldı, genel bilgiden varsayıldı, insan kontrolü öneriliyor.” Geliştirici o bileşene odaklanıyor, düzeltiyor. Her şey ikinci adıma temiz geçiyor.
Toplam süre farkı? Birinci senaryoda ilk gün “hızlı” ama üçüncü gün her şeyi söktü. İkinci senaryoda ilk gün “biraz yavaş” ama üçüncü gün çoktan beşinci adımda. Ve üçüncü günün çıktısının temeli sağlam.
Otomasyonun Sınırı: İnsan Nerede Vazgeçilmez?
Bu sistemi anlatırken bir izlenim vermek istemiyorum: “kapıları kur, arkana yaslan, yapay zeka her şeyi halleder.” Kapı sistemi insanın işini ortadan kaldırmıyor, insanın dikkatini verimli kullanmasını sağlıyor.
İnsan üç noktada vazgeçilmez kalıyor.
Birincisi, kapı sisteminin kendisinin tasarımı. Hangi eşikler doğru? Hangi kurallar projeye uygun? Hangi bilgi kodlanmalı, hangisi değişken? Bu kararlar insana ait çünkü projenin amacını, ekibin dinamiklerini, iş gereksinimlerini bilen insan.
İkincisi, kapı raporlarının yorumlanması. Kapı “sapma tespit edildi” diyor — ama o sapma kötü bir şey mi yoksa keşfedilmiş daha iyi bir yol mu? Kapı “%48 güven” diyor — ama bağlam göz önünde bulundurulduğunda bu kabul edilebilir bir risk mi? Bu yargılar bağlam, deneyim ve vizyon gerektiriyor — insanın alanı.
Üçüncüsü, epistemik sorumluluk. Yapay zeka bir araçtır ve araçların sorumluluğu yoktur. Kapı sistemi gürültüyü azaltır ama sıfırlamaz. Projeye giren her katkının sorumluluğu, o katkıyı onaylayan insana aittir. Kapılar insanın onaylama kapasitesini güçlendirir — ama onaylama eyleminin kendisi insanda kalır.
Sonuç: Denklemin Kontrol Paneli
İlk yazıda dedim ki: “denklemin kontrol edilebilir tarafı bizim tarafımız.” Bu hâlâ doğru. Ama bu yazıda gösterdiğim şey, o kontrolün artık sadece insanın kafasında değil, bir sistemde yaşayabileceği.
Bilginizi kodlayın — her oturumda sıfırdan başlamayın. Kapıları kurun — her çıktıyı satır satır kontrol etmek zorunda kalmayın. Şeffaflığı zorunlu kılın — kara kutuya güvenmek zorunda kalmayın. Dikkatinizi kapıların yönlendirdiği yere odaklayın — her şeyi kontrol etmeye çalışıp hiçbir şeyi kontrol edememekten kurtulun.
İlk sinyal hâlâ insandır — bu değişmedi. Ama artık o sinyalin etrafında, onu koruyan, güçlendiren ve sürdürülebilir kılan bir yapı var. Bu yapı mükemmel değil. Ama mükemmellik zaten hedef değil — hedef, gürültünün bağlama sızma hızını, sinyalin bağlamı güçlendirme hızının altında tutmak.
Ve bu, bir insanın tek başına dikkat gücüyle yapabileceğinin çok ötesinde.
Bu yazıda anlattığım kapı sistemini, meta-kontrolü ve şeffaflık kurallarını herhangi bir yapay zeka aracına doğrudan besleyebileceğiniz bir gist olarak açık kaynak yayınladım. Claude Code, Cursor, Copilot, Windsurf — hangi aracı kullanırsanız kullanın, oturum başında bu gist’i bağlam olarak verdiğinizde agent kapı sistemini uygulamaya başlıyor. Gist’i kendi projelerinize uyarlayabilir, genişletebilir ve ekibinizle paylaşabilirsiniz: AI Workspace Memory & Quality Gate System
