Yapay Zeka Tasarım Otoritesi
Yazılım geliştirmenin bir dönüm noktasındayız. Tartışma genellikle hangi yapay zekanın en iyi kodu yazdığı (Claude'a karşı ChatGPT) veya nerede o yapay zekanın nerede barınması gerektiği (IDE mi yoksa CLI mi) üzerine odaklanıyor. Ancak asıl soru bu değil.
Sorun, üretmek kodun doğrulama uygulamasıdır.
Yapay Zekayı, niyeti belirttiğimiz ve YZ'nin uygulamayı gerçekleştirdiği "Vibe Kodlayıcıları" olarak kucaklarsak, muazzam bir yeni yazılım akışı yaratırız. Bir YZ 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 YZ 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?
“Meydan Okuma”: Otomatik Bir Ateş Testi
Bir YZ Tasarım Otoritesi bir kişi değil, bir boru hattıdır. Üretime geçebilmek için üretilen her kod satırının içinden geçmek zorunda olduğu bir "Engelli Parkuru". Bu süreç, insan kod incelemesinin yerini almaz, hiçbir şey, ancak bir şeyle daha iyisi.
Üç katmanda çalışır:
1. Yürütme Gücü (Üretim)
Tek bir yapay zekadan çö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 yapay zeka halüsinasyonunun ö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, yapay zekayı manipüle edebilir), sistemin dışarıdan 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 yenilik budur. Geriye kalan çözümler özel bir "Oylama Yapay Zekasına" sunulur. Bu ajan kod yazmaz, ancak okur kod. Mimari ilkelerimiz, güvenlik gereksinimlerimiz (OWASP, ISO) ve uyumluluk kurallarımız (AB Yapay Zeka Yasası) üzerinde eğitilmiştir.
Ş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 Kuvvetler Ayrılığı
Bu model, birçok ekipte eksik olan bir kuvvetler ayrılığını zorunlu kılar.
- Yasama Organı (Mimar): Mimar, "Anayasa"yı yazar. Komutlar, mimari belgeler (
project-description.md, rules.md, skills.md en principles.md), katı gereksinimler. Mimar belirler ne ne inşa edeceğimizi, kimin inşa edeceğini, nasıl ve neden. - Yürütme Organı (Kodlama Ajanları): Uygularlar. Hızlı, ucuz ve insan geliştiricilerin himayesinde.
- 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. Gerçek bulma. Yapı ve karar verme.
Soru, yapay zekanın kodumuzu yazıp yazamayacağı değil. Bu konu zaten kapandı. Kod büyük ölçüde tek kullanımlık bir ürün haline geliyor.
Soru şu: Kontrolü elinizden alma cesaretiniz var mı? kod bırakmak, böylece kontrolü kalite geri kazanmak mı?
bana bildir
