Yapay Zeka Tasarım Otoritesi
Yazılım geliştirme açısından 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 bu yapay zekanın nerede barındırılması gerektiği (IDE mi yoksa CLI mi) üzerine odaklanıyor. Ancak bu yanlış bir tartışma.
Gerçek sorun, nesil kodun kendisi değil. Gerçek sorun, doğrulama uygulanmasıdır.
Yapay Zekayı, niyeti belirttiğimiz ve yapay zekanın uygulamayı gerçekleştirdiği "Vibe Kodlayıcıları" olarak benimsediğimizde, muazzam miktarda yeni yazılım akışı yaratıyoruz. 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. Bir dünyada yüksek hızlı yapay zeka geliştirme bu model umutsuzca eskidir. Çok yavaş ve çok reaktiftir.
Gereksinimler değiştikçe sonsuza kadar yeniden düzenlemek yerine atıp yeniden oluşturduğumuz "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?
“Eldiven”: Otomatik Bir Ateş Testi
Bir Yapay Zeka Tasarım Otoritesi bir kişi değil, bir boru hattıdır. Üretime geçmek için üretilen her kuralın içinden geçmek zorunda olduğu bir "Engelli Parkur". Bu süreç, insan kod incelemesinin yerini almaz, bunun yerine hiçbir şey, ama bir şeyle daha iyileri.
Üç katmanda çalışır:
1. Yürütme Gücü (Üretim)
Tek bir YZ'den çözüm istemiyoruz, üç tanesinden istiyoruz. 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 YZ'lerin bazen muzdarip olduğu "tembelliği" kırar. Bu yaklaşım aynı zamanda bilimsel olarak araştırılmış tır ve YZ halüsinasyonunun nasıl önlenebileceğini ve hatalar olmadan çok uzun zincirler oluşturulabileceğini gösterir
2. Sert Filtre (Yasa)
Burada tartışmaya yer yok. Kod derlenmeli. Linterlar şikayet etmemeli. Ve en önemlisi: testler Kara Kutu Testleri başarılı olmalı. Fonksiyonun içeride çalışıp çalışmadığını test etmiyoruz (bu, YZ'yi 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)
Gerçek yenilik budur. Geriye kalan çözümler özel bir "Oylama YZ'sine" sunulur. Bu ajan kod yazmaz, ancak okur kod üzerinde eğitilmiştir; mimari ilkelerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) dikkate alınmıştır.
Şunu belirtir: “Çözüm A daha hızlıdır, ancak Çözüm B daha güvenlidir ve mikro hizmetler mimarimize daha iyi uyar.”
Kazanan üretime geçiyor.
Yazılımın Trias Politica'sı
Bu model, birçok ekipte eksik olan bir kuvvetler ayrılığını zorunlu kılar.
- Yasama Gücü (Mimar): Mimar, “Anayasa”yı yazar. Komutlar, mimari belgeler (
project-description.md, rules.md en principles.md), katı gereklilikler. Mimar belirler ne inşa ederiz ve neden. - Yürütme Gücü (Kodlama Ajanları): Uygularlar. 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ç: Mimarin 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 bulma. Yapı ve karar verme.
Soru, yapay zekanın kodumuzu yazıp yazamayacağı değil. Bu zaten kararlaştırıldı. Kod büyük ölçüde harcanabilir hale geliyor.
Soru şu: Kontrolü elinizden almaya cesaretiniz var mı? uygulama bırakmak, böylece kontrolü kalite geri kazanmak mı?
