Yapay Zeka Tasarım Otoritesi
Yazılım geliştirmedede bir dönüm noktasındayız. Tartışma genellikle şunlar etrafında dönüyor: hangisi AI'ın en iyi kodu yazıp yazmadığı (Claude ve ChatGPT) veya bu AI'ın nerede yaşaması gerektiği (IDE veya CLI). ancak doğru soru bu değil.
Yapay zekayı “Vibe Coders” olarak benimsersek –niyeti belirtip yapay zekanın uygulamayı yapmasına izin vererek– devasa bir yeni yazılım akışı yaratırız. Bir yapay zeka ajanları sürüsü, bir kıdemli geliştiricinin bir haftada inceleyebileceğinden daha fazla kodu bir dakikada üretebilir. İnsan, artık darboğaz haline geldi.
Çözüm değildir. daha fazla insan değildir. Çözüm, 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 kez toplanan bir grup mimardır. Dünyasında yüksek hızlı yapay zeka geliştirme (high-velocity AI development) bu model umutsuzca eskimiştir. Çok yavaş ve çok reaktiftir.
“Kullan-At Kod” (Disposable Code) anlayışına geçersek –yani sonsuza kadar yeniden düzenlemediğimiz (refactor), gereksinimler değiştiğinde çöpe atıp yeniden ürettiğimiz yazılımlar– rolümüz kökten değişir. Artık tuğla üzerine tuğla koyan duvarcılar değiliz. Duvarları basan fabrikanın mimarlarıyız.
Ancak o duvarların düz durup durmadığını kim kontrol ediyor?
"Gauntlet": Otomatikleştirilmiş Bir Ateş Testi
Bir Yapay Zeka Tasarım Otoritesi (AI Design Authority) bir kişi değil, bir veri akış hattıdır (pipeline). Üretime geçebilmek için üretilen her kod satırının içinden geçerek savaşması gereken bir "Gauntlet"dir (Engelli Parkur). Bu süreç insan kod incelemesinin yerini almaz, hiçbiriyle, bunun yerine çok daha daha iyisiyle.
Bu sistem üç katmanda çalışır:
1. Yürütme Erki (Üretim)
Bir sorunun çözümü için tek bir yapay zekaya başvurmak yerine üç tanesine başvuruyoruz. Gemini 3, GPT-5 ve açık kaynaklı bir modelin (Llama gibi) aynı sorun üzerinde paralel olarak çalışmasını sağlıyoruz. Bu, tünel görüşünü engeller ve LLM'lerin bazen maruz kaldığı "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 hata yapmadan çok uzun zincirler kurabileceğinizi kanıtlamaktadır
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. Kodun dahili olarak çalışıp çalışmadığını test etmiyoruz (yapay zeka bunu manipüle edebilir), sistemin dışarıdan yapması gerekeni yapıp yapmadığını test ediyoruz. Test başarısız mı oldu? Doğrudan çöp kutusuna.
3. Yumuşak Filtre (Yapay Zeka Jürisi)
Asıl yenilik budur. Geri kalan çözümler uzmanlaşmış bir "Oylama Yapay Zekası"na (Voting AI) sunulur. Bu ajan kod yazmaz, aksine okur kod. Mimari ilkelerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) üzerinde eğitilmiştir.
Şöyle oy veriyor: "A Çözümü daha hızlı, ancak B Çözümü daha güvenli ve mikro servis mimarimizi daha iyi takip ediyor."
Kazanan üretime geçer.
Yazılımın Kuvvetler Ayrılığı İlkesi
Bu model, birçok ekipte eksik olan bir kuvvetler ayrılığını zorunlu kılar.
- Yasama Organı (Mimar): Mimar "Anayasa"yı yazar. Prompt'lar, mimari belgeler (
project-description.md, rules.md, skills.md en principles.md), katı kurallar. Mimar karar verir ne ne inşa ediyoruz, bunu kim inşa ediyor, nasıl ve neden. - Yürütme Organı (Kodlama Ajanları): Uygulamayı yaparlar. Hızlı, ucuz ve insan geliştiricilerin gözetimi altında.
- Yargı Erki (Tasarım Otoritesi - Design Authority): Yasalara uygunluğu denetleyen bağımsız bir yapay zeka katmanı.
Sonuç: Mimarın Yeni Rolü
Bizi sözdizimi hatalarının tirancılığından kurtarıyor ve iyi olduğumuz şeylere odaklanmamızı sağlıyor: Sistem düşüncesi. Gerçeği arama. Yapı ve karar verme.
Soru, yapay zekanın kodumuzu yazıp yazamayacağı değildir. Bu konu zaten kapanmıştır. Kod büyük ölçüde tek kullanımlık bir ürün haline geliyor.
Soru şudur: Kontrolü kod bırakmaya cesaret edebilir misiniz, böylece kalite üzerindeki kontrolü geri kazanabilirsiniz?
bana bildir
