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 AI'nın nerede yaşaması gerektiği (IDE veya CLI). Ancak doğru soru bu değil.
AI'yı "Vibe Coders" (Hissiyat Kodlayıcıları) olarak benimsediğimizde – yani niyeti biz belirtip uygulamayı AI'ya bıraktığımızda – muazzam bir yeni yazılım akışı yaratıyoruz. Bir AI ajanları sürüsü, bir dakikada 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.
Zanaatkardan Fabrika Müdürü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.
"Atılabilir Kod"a (Disposable Code) geçtiğimizde – yani sonsuza dek yeniden düzenlemediğimiz, ancak gereksinimler değiştiğinde atıp yeniden oluşturduğumuz yazılımlar – rolümüz temelden değişir. Artık taş üstüne taş koyan 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 Tasarım Otoritesi bir kişi değil, bir iş akışıdır. Üretilen her kod satırının üretime geçebilmek için içinden geçmesi gereken bir "eldiven" (sınav süreci). Bu süreç, insan tarafından yapılan kod incelemesinin yerini almaz, hiçbir şey, aksine daha iyi bir şeyle değiştirir daha iyi.
Üç katmanlı bir yapıda çalışır:
1. Yürütme Gücü (Üretim)
Bir çözüm için tek bir yapay zekaya güvenmiyoruz, üç 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ü engeller 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 kanıtlar
2. Sıkı 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ğrudan çöpe.
3. Yumuşak Filtre (Yapay Zeka Jürisi)
Gerçek inovasyon burada yatar. Kalan çözümler uzmanlaşmış bir "Oylama Yapay Zekasına" sunulur. Bu ajan kod yazmaz, ancak okuyor kodu denetler. Mimari prensiplerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) konusunda eğitilmiştir.
Şöyle oy kullanıyor: “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 (promptlar), 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 yapar. Hızlı, ucuz 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ırakmaya cesaretin var mı, böylece kalite üzerindeki kontrolü geri kazanabilir misin?
bana bildir
