Yapay Zeka Tasarım Otoritesi
Yazılım geliştirmede bir dönüm noktasındayız. Tartışma genellikle şunun üzerine dönüyor: hangisinin AI'nın en iyi kodu yazması (Claude vs. ChatGPT) veya nerede o AI'nın nerede yaşaması gerektiği (IDE veya CLI). Ancak doğru soru bu değil.
Eğer AI'yı "Vibe Coders" (Hissiyat Kodlayıcıları) olarak benimsersek – yani niyeti biz belirtip uygulamayı AI'ya yaptırırsak – muazzam bir yeni yazılım akışı yaratırız. Bir AI ajanları sürüsü, bir dakika içinde kıdemli bir yazılımcının bir haftada inceleyebileceğinden daha fazla kod üretebilir. İnsan artık darboğaz haline geldi.
Çözüm daha fazla insanlar değil. Çözüm bir AI Tasarım Otoritesi.
Zanaatkarlıktan Fabrika Müdürlüğüne
Geleneksel olarak "Tasarım Otoritesi", bir tasarımı onaylamak veya reddetmek için haftada veya ayda bir toplanan bir grup mimardır. Ancak yüksek hızlı AI geliştirme dünyasında bu model umutsuzca eskimiştir. Çok yavaş ve çok reaktiftir.
Eğer "Kullan-At Kod" (Disposable Code) modeline geçersek – yani sonsuza kadar refactor etmediğimiz, gereksinimler değiştiğinde atıp yeniden ürettiğimiz yazılımlar – rolümüz temelden değişir. Artık tuğla tuğla ören duvarcılar değiliz. Duvarları basan fabrikanın mimarlarıyız.
Peki, o duvarların düz durup durmadığını kim kontrol edecek?
"Gauntlet": Otomatik bir ateşten imtihan
Bir AI Design Authority bir kişi değil, bir boru hattıdır. Üretilen her kod satırının üretime geçebilmek için içinden geçmesi gereken bir "eldiven" (Gauntlet). Bu süreç, insan tarafından yapılan kod incelemesinin yerini almaz, hiçbir şeyle, aksine daha iyi bir şeyle değiştirir daha iyisiyle.
Üç katman halinde çalışır:
1. Yürütme Gücü (Üretim)
Bir çözüm için tek bir yapay zekaya sormuyoruz, üç tanesine soruyoruz. Gemini 3, GPT-5 ve açık kaynaklı bir modeli (Llama gibi) aynı problem üzerinde paralel olarak çalıştırıyoruz. Bu, tünel görüşünü önler ve LLM'lerin bazen yaşadığı "tembelliği" kırar. Bu yaklaşım aynı zamanda bilimsel olarak araştırılmıştır ve yapay zeka halüsinasyonlarını önleyebileceğinizi ve hatalar olmadan çok uzun zincirler oluşturabileceğinizi gösterir
2. Sert Filtre (Yasa)
Burada tartışmaya yer yoktur. Kod derlenmelidir. Linter'lar hata vermemelidir. Ve en önemlisi, Kara Kutu Testleri başarılı olmalıdır. Fonksiyonun dahili olarak çalışıp çalışmadığını test etmiyoruz (yapay zeka bunu manipüle edebilir), sistemin dışarıdan bakıldığında yapması gerekeni yapıp yapmadığını test ediyoruz. Test başarısız mı oldu? Doğruca çöp kutusuna.
3. Yumuşak Filtre (Yapay Zeka Jürisi)
Gerçek inovasyon budur. Kalan çözümler uzmanlaşmış bir "Oylama Yapay Zekasına" sunulur. Bu ajan kod yazmaz, ancak okunuyor kodu denetler. Mimari prensiplerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) konusunda eğitilmiştir.
Şöyle karar veriyor: “A Çözümü daha hızlı, ancak B Çözümü daha güvenli ve mikro hizmet mimarimize daha uygun.”
Kazanan üretime geçer.
Yazılımın Güçler Ayrılığı (Trias Politica)
Bu model, birçok ekipte eksik olan bir güçler ayrılığını zorunlu kılar.
- Yasama Organı (Mimar): Mimar "Anayasa"yı yazar. İstemler (prompt'lar), mimari belgeler (
project-description.md, rules.md, skills.md en principles.md), katı gereksinimler. Mimar belirler: ne neyi inşa ettiğimizi, kimin inşa ettiğini, nasıl ve neden. - Yürütme Organı (Kodlama Ajanları): Uygulamayı onlar gerçekleştirir. Hızlı, düşük maliyetli ve insan geliştiricilerin gözetiminde.
- Yargı Organı (Tasarım Otoritesi): Yasaya uygunluğu denetleyen bağımsız bir yapay zeka katmanı.
Sonuç: Mimarların yeni rolü
Bizi sözdizimi hatalarının tiranlığından kurtarır ve iyi olduğumuz şeye odaklanmamızı sağlar: Sistem düşüncesi. Hakikat arayışı. Yapı ve karar verme.
Soru, yapay zekanın kodumuzu yazıp yazamayacağı değil. O konu çoktan kapandı. Kod, büyük ölçüde tek kullanımlık bir ürün haline geliyor.
Soru şu: Kontrolü kod üzerinden bırakıp, bununla kalite üzerindeki kontrolü geri kazanmaya cesaretin var mı?
bana bildir
