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 yaşaması gerektiği (IDE veya CLI). Ancak bu doğru soru değil.

AI'yi “Vibe Coders” olarak benimsersek – niyeti belirleyip AI'nin yürütmesini sağladığımızda – yeni yazılımların devasa bir akışını yaratırız. 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 haline geldi.

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

Zanaatkârdan Fabrika Direktörüne

Geleneksel olarak “Tasarım Otoritesi”, haftada ya da ayda bir araya gelen bir grup mimardır ve bir tasarımı onaylamak ya da reddetmek için toplanır. ... bir dünyada yüksek hızlı AI geliştirme bu model çaresizce eski. Çok yavaş ve çok tepkisel.

“Disposable Code” – gereksinimler değiştiğinde sonsuzca yeniden düzenlemek yerine atıp yeniden ürettiğimiz yazılım – modeline 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 doğru durduğunu kim denetler?

"Gauntlet": Otomatik bir ateş denemesi

Bir AI Tasarım Otoritesi bir kişi değil, bir boru hattıdır. Her üretilen kod satırının üretime geçebilmek 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 AI'dan çözüm istemiyoruz, üç tanesini istiyoruz. Gemini 3, GPT-5 ve bir açık kaynak modelini (örneğin Llama) aynı problem üzerinde paralel çalıştırıyoruz. Bu, tünel görüşünü önler ve LLM'lerin bazen yaşadığı "tembellik"i kırar. Bu yaklaşım aynı zamanda bilimsel olarak incelenmiştir ve AI halüsinasyonlarını önleyebileceğinizi ve çok uzun zincirleri hatasız bir şekilde inşa edebileceğinizi gösterir

2. Sert Filtre (Yasa)
Burada tartışma mümkün değildir. Kod derlenmelidir. Linter'lar şikayet etmemelidir. Ve kritik: Kara Kutu Testleri başarılmalıdır. 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 olursa? Direkt çöp kutusuna.

3. Yumuşak Filtre (AI Jürisi)
Bu gerçek yeniliktir. Kalan çözümler özel bir "Oy Veren AI"ye sunulur. Bu ajan kod yazmaz, ancak okur kod. O, mimari prensiplerimiz, güvenlik gereksinimleri (OWASP, ISO) ve uyumluluk kuralları (AB AI Yasası) üzerine eğitilmiştir.
O oy veriyor: Çözüm A daha hızlı, ancak Çözüm B daha güvenli ve mikroservis mimarimizle daha iyi uyum sağlıyor.

Kazanan üretime geçiyor.

Yazılımın Politik Üçlüsü

Bu model, birçok ekipte eksik olan güçler ayrımını zorunlu kılıyor.

• Yasama Yetkisi (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): Yasa ile uyumu test eden bağımsız bir AI katmanı.

Sonuç: Mimarın yeni rolü

Bizi sözdizimi hatalarının tiranlığından kurtarıyor ve iyi olduğumuz şeylere odaklanmamızı sağlıyor: 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 serbest bırakıp, böylece kontrolü kalite geri kazanmak?

bana haber ver