Yapay Zekâ Tasarım Otoritesi
Yazılım geliştirmede bir dönüm noktasındayız. Tartışma çoğu zaman şu konular etrafında dönüyor: hangi En iyi kodu yapay zekânın yazıp yazmadığı (Claude mu, ChatGPT mi) ya da nerede yapay zekânın nerede bulunması gerektiği (IDE mi, CLI mı). Ancak doğru soru bu değil.
Yapay zekâyı, niyetimizi belirttiğimiz ve uygulamayı yapay zekânın üstlendiği “Vibe Coding” yaklaşımıyla benimsediğimizde, muazzam miktarda yeni yazılım üretiriz. Bir yapay zekâ ajanları sürüsü, bir kıdemli geliştiricinin bir haftada inceleyebileceğinden daha fazla kodu tek bir dakikada üretebilir. İnsan artık darboğaz hâline geldi.
Çözüm, artık insanlar değildir. Çözüm bir AI Tasarım Otoritesi.
Zanaatkârdan Fabrika Müdürüne
Geleneksel olarak “Tasarım Otoritesi”, bir tasarımı onaylamak veya reddetmek üzere haftada ya da ayda bir toplanan bir grup mimardan oluşur. Şu dünyada yüksek hızlı yapay zekâ geliştirme bu model umutsuzca eskimiştir. Fazlasıyla yavaş ve tepkiseldir.
“Tek Kullanımlık Kod” yaklaşımına geçtiğimizde — yani gereksinimler değiştiğinde yazılımı durmadan yeniden düzenlemek yerine çöpe atıp yeniden ürettiğimizde — rolümüz temelden değişir. Artık taşları tek tek dizen duvar ustaları değiliz. Duvarları basan fabrikanın mimarlarıyız.
Ama bu duvarların doğru durup durmadığını kim denetliyor?
“Gauntlet”: Otomatikleştirilmiş Ateş Sınavı
Bir Yapay Zekâ Tasarım Otoritesi bir kişi değil, bir işlem hattıdır. Üretilen her kod satırının üretime geçebilmek için mücadele ederek aşması gereken bir “Gauntlet”tir. Bu süreç, insan tarafından yapılan kod incelemesinin yerini almaz; hiçbir şeyle, bunun yerine bir şeyle daha iyisiyle.
Üç katmanda çalışır:
1. Yürütme Gücü (Üretim)
Tek bir yapay zekâdan çözüm istemiyoruz; üçünden istiyoruz. Gemini 3, GPT-5 ve açık kaynaklı bir modelin (Llama gibi) aynı sorun üzerinde paralel çalışmasını sağlıyoruz. Bu, bakış açısının daralmasını önlüyor ve LLM’lerin zaman zaman yaşadığı “tembelliği” kırıyor. Bu yaklaşım aynı zamanda bilimsel olarak incelenmiştir ve yapay zekâ halüsinasyonlarının önlenebileceğini, hatasız şekilde çok uzun zincirler oluşturulabileceğini gösteriyor
2. Sert Filtre (Yasa)
Burada tartışmaya yer yok. Kod derlenmeli. Linter’lar herhangi bir uyarı vermemeli. En önemlisi: Kara Kutu Testleri başarılı olmalı. İşlevin içeride çalışıp çalışmadığını test etmiyoruz (yapay zekâ 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 Zekâ Jürisi)
Asıl yenilik burada. Geriye kalan çözümler, uzmanlaşmış bir “Oylama Yapay Zekâsına” sunuluyor. Bu ajan kod yazmıyor, ancak okur kod. Mimari ilkelerimiz, güvenlik gereksinimleri (OWASP, ISO) ve uyumluluk kuralları (AB Yapay Zekâ Yasası) konusunda eğitilmiştir.
Şöyle değerlendirir: “A çözümü daha hızlı, ancak B çözümü daha güvenli ve mikro hizmet mimarimize daha iyi uyum sağlıyor.”
Kazanan üretime alınır.
Yazılımın Kuvvetler Ayrılığı
Bu model, birçok ekipte eksik olan güçler ayrılığını zorunlu kılar.
- Yasama Erki (Mimar): Mimar “Anayasa”yı yazar. İstemler, mimari belgeler (
project-description.md, rules.md, skills.md en principles.md), katı gereksinimler. Mimar belirler neyi neyi inşa ettiğimizi, kimin inşa ettiğini, nasıl ve neden. - Yürütme Erki (Kodlama Aracıları): Bunlar uygulamayı gerçekleştirir. Hızlı, ucuz ve insan geliştiricilerin himayesinde.
- Yargı Erki (Tasarım Otoritesi): Yasalara uygunluğu denetleyen bağımsız bir yapay zekâ katmanı.
Sonuç: Mimarın Yeni Rolü
Bizi sözdizimi hatalarının tiranlığından kurtarır ve iyi olduğumuz alanlara odaklanmamızı sağlar: Sistem düşüncesi. Gerçeği ortaya çıkarma. Yapı ve karar alma.
Soru, yapay zekânın kodumuzu yazıp yazamayacağı değil. Bu konu artık kapanmıştır. Kod, büyük ölçüde kullanılıp atılan bir ürüne dönüşecek.
Soru şu: Kontrolü kod bırakmaya ve böylece kalite üzerindeki kontrolü yeniden kazanmaya cesaretin var mı?
bana haber ver
