AI Tasarım Otoritesi

Yazılım geliştirmede bir dönüm noktasındayız. Tartışma genellikle şunlar hakkında hangi AI en iyi kodu yazar (Claude vs. ChatGPT) ya da nerede hangi AI'nin kullanılacağı (IDE mi yoksa CLI mi). Ancak bu doğru soru değil.

Sorun şu değil üretme kodun. Asıl doğrulama onun.

AI'yi “Vibe Coders” olarak benimsediğimizde – niyeti belirleyip AI'nin yürütmesini sağladığımızda – yeni bir yazılım akışı oluştururuz. Bir sürü AI ajanı bir dakikada bir kıdemli geliştiricinin bir haftada gözden geçirebileceğinden daha fazla kod üretebilir. İnsan artık darboğaz oldu.

Çözüm şu değil daha insanlar. Çözüm bir AI Tasarım Otoritesi.

Zanaatkârdan Fabrika Direktörüne

Geleneksel olarak “Design Authority”, haftada ya da ayda bir araya gelen bir grup mimar olup bir tasarımı onaylamak ya da reddetmek için toplanır. Bir dünyada yüksek hızlı AI geliştirme Bu model umutsuzca eski. Çok yavaş ve çok tepkisel.

“Disposable Code” – gereksinimler değiştiğinde sonsuzca yeniden düzenlemediğimiz, atıp yeniden ürettiğimiz yazılım – üzerine geçersek rolümüz temelden değişir. Artık taş üstüne taş koyan duvarcılar değiliz. Duvarları yazdıran fabrikanın mimarlarıyız.

Ama bu duvarların dik durup durmadığını kim kontrol eder?

Gauntlet: Otomatik bir ateş testi

Bir AI Design Authority kişi değildir, bir boru hattıdır. Her satır üretilen kodun üretime ulaşmak için mücadele etmesi gereken bir “Gauntlet”. Bu süreç insan kod incelemesini ... ile değiştirmez hiçbir şey, ama bir şeyle daha iyi.

Üç katmanda çalışır:

1. Yürütme Gücü (Üretim)
Bir çözüm için tek bir AI istemiyoruz, üç tanesini istiyoruz. Gemini 3, GPT-5 ve açık kaynak bir modeli (örneğin Llama) aynı soruna paralel olarak çalıştırıyoruz. Bu, tünel görüşünü önler ve LLM'lerin bazen sahip olduğu “tembellik”i kırar. Bu yaklaşım aynı zamanda bilimsel olarak araştırılmış ve AI halüsinasyonlarını önleyebileceğinizi ve hatasız çok uzun zincirler inşa edebileceğinizi gösterir

2. Sert Filtre (Yasa)
Burada tartışma mümkün değildir. Kod derlenmelidir. Linter'lar şikayet edemez. Ve kritik: Kara Kutu Testleri başarılmalı. Fonksiyonun içte çalışıp çalışmadığını test etmiyoruz (bu AI'ı manipüle edebilir), sistemin dışarıdan yapması gerekeni yapıp yapmadığını test ediyoruz. Test başarısız mı? Hemen çöp kutusuna.

3. Yumuşak Filtre (AI Jürisi)
Bu gerçek yenilik. Kalan çözümler, uzman bir “Oylama AI”sına sunulur. Bu ajan kod yazmaz, ancak okur kod. O, mimari prensiplerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarına (AB AI Yasası) göre eğitilmiştir.
O oy verir: “Çözüm A daha hızlı, ancak Çözüm B daha güvenli ve mikroservis mimarimizi daha iyi takip ediyor.”

Kazanan üretime geçer.

Yazılımın Üçlü Politikası

Bu model, birçok takımda eksik olan güçler ayrımını zorunlu kılar.

• Yasama Gücü (Mimar): Mimar, “Anayasa”yı yazar. Promptlar, mimari belgeler (project-description.md, rules.md, skills.md en principles.md), katı gereksinimler. Mimar belirler ne biz inşa ederiz, kim inşa eder, nasıl ve neden.
• Yürütme Yetkisi (Kodlama Ajanları): Onlar uygular. Hızlı, ucuz ve insan geliştiricilerin himayesi altında.
• Yargı Yetkisi (Tasarım Otoritesi): Yasaya uygunluğu test eden bağımsız bir AI katmanı.

Sonuç: Mimarın yeni rolü

Bizi sözdizimi hatalarının tiranlığından kurtarır ve iyi olduğumuz şeylere odaklanmamızı sağlar: Sistem düşüncesi. Gerçek bulma. Yapı ve karar verme.

Soru, AI'nın kodumuzu yazıp yazamayacağı değil. Bu konu zaten kapandı. Kod büyük ölçüde tek kullanımlık bir ürün haline geliyor.
Soru şu: Kontrolü bırakmaya cesaretin var mı kod bırakmak, böylece kontrolü kalite geri kazanmak?

bana haber ver