Yapay Zeka Tasarım Otoritesi
Yazılım geliştirmede bir dönüm noktasındayız. Tartışma genellikle hangi yapay zekanın en iyi kodu yazıp yazmadığı (Claude'a karşı ChatGPT) veya nerede yapay zekanın nerede barınması gerektiği (IDE mi yoksa CLI mi) üzerine odaklanıyor. Ancak bu, yanlış bir tartışma.
Asıl sorun nesil kodun doğrulama uygulanmasıdır.
Yapay Zekayı, niyeti belirttiğimiz ve yapay zekanın uygulamayı gerçekleştirdiği "Vibe Kodlayıcıları" olarak kucaklarsak, muazzam miktarda yeni yazılım akışı yaratırız. Bir yapay zeka ajanı sürüsü, bir kıdemli geliştiricinin bir haftada inceleyebileceğinden daha fazla kodu bir dakikada üretebilir. İnsan darboğaz haline geldi.
Çözüm daha fazla insanlar değil. Çözüm bir Yapay Zeka Tasarım Otoritesi.
Zanaatkardan Fabrika Müdürüne
Geleneksel olarak, "Tasarım Otoritesi" haftada veya ayda bir kez toplanıp bir tasarımı onaylayan veya reddeden küçük bir mimar grubudur. Şu anda içinde bulunduğumuz yüksek hızlı yapay zeka geliştirme model umutsuzca eskimiştir. Çok yavaş ve çok reaktiftir.
Gereksinimler değiştikçe sonsuza kadar yeniden düzenlemek yerine atıp yeniden ürettiğimiz "Kullan-At Kod"a geçiş yaparsak, rolümüz temelden değişir. Artık taş üstüne taş koyan duvarcılar değiliz. Biz, duvarları basan fabrikanın mimarlarıyız.
Peki bu duvarların düz olup olmadığını kim kontrol ediyor?
“Gauntlet”: Otomatik Bir Ateş Testi
Yapay Zeka Tasarım Otoritesi (AI Design Authority) bir kişi değil, bir boru hattıdır. Üretim ortamına geçebilmek için üretilen her kodun içinden geçmek zorunda olduğu bir "Eleme Testi" (Gauntlet). Bu süreç, insan kod incelemesinin yerini almak yerine, hiçbir şeyleile daha iyisiyle.
Üç katmanda çalışır:
1. Yürütme Gücü (Üretim)
Tek bir yapay zekadan çözüm istemiyoruz, üç tane istiyoruz. Gemini 3, GPT-5 ve açık kaynaklı bir modeli (Llama gibi) aynı sorun üzerinde paralel olarak çalıştırıyoruz. Bu, tünel görüşünü önler ve Büyük Dil Modellerinin (LLM'ler) bazen muzdarip olduğu "tembelliği" kırar. Bu yaklaşım aynı zamanda bilimsel olarak araştırılmış yapay zeka halüsinasyonunu önleyebileceğinizi ve hatalar olmadan çok uzun zincirler oluşturabileceğinizi gösterir
2. Sert Filtre (Yasa)
Burada tartışmaya yer yoktur. Kod derlenmelidir. Kod denetleyicileri şikayet etmemelidir. Ve en önemlisi: Kara Kutu Testleri başarılı olmalıdır. Fonksiyonun içeride çalışıp çalışmadığını test etmiyoruz (bu, YZ'nin manipülasyonuna yol açabilir), 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)
Gerçek yenilik budur. Geriye kalan çözümler, uzmanlaşmış bir "Oylama Yapay Zekasına" sunulur. Bu ajan kod yazmaz, ancak okur kod yazar. Mimari ilkelerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) üzerine eğitilmiştir.
Oylar: “A Çözümü daha hızlı, ancak B Çözümü daha güvenli ve mikro hizmet mimarimizi daha iyi takip ediyor.”
Kazanan üretime gider.
Yazılımın Yasama, Yürütme ve Yargı Organları
Bu model, birçok ekipte eksik olan kuvvetler ayrılığını zorunlu kılar.
- Yasama Gücü (Mimar): Mimar, "Anayasa'yı" yazar. Komut istemleri, mimari belgeler (
project-description.md, rules.md en principles.md), katı gereksinimler. Mimar belirler ne inşa ettiğimiz ve neden. - Yürütme Gücü (Kodlama Ajanları): Uygulama yaparlar. Hızlı, ucuz ve insan geliştiricilerin gözetimi altında.
- Yargı Gücü (Tasarım Otoritesi): Yasalara uygunluğu kontrol eden bağımsız bir yapay zeka katmanı.
Sonuç: Mimarların Yeni Rolü
Bizi sözdizimi hatalarının tiranlığından kurtarır ve en iyi olduğumuz şeye odaklanmamızı sağlar: Sistem düşüncesi. Gerçek arayışı. Yapı ve karar verme.
Soru, YZ'nin kodumuzu yazıp yazamayacağı değil. Bu zaten kararlaştırıldı. Kod büyük ölçüde harcanabilir hale geliyor.
Soru şu: Kontrolü bırakmaya cesaretin var mı, uygulama böylece ... üzerindeki kontrolü geri kazanabilirsin? kalite geri kazanmak?
