Tasarım-Kod Kaymasını Yakalamak İçin AI Kullanmak Neden Riskli
AI ile üretilen arayüz kodundaki tasarım kayması artıyor; ancak bunu yakalamak için başka bir AI modeli kullanmak deterministik olmayan, maliyetli ve açıklanamaz sonuçlar doğuruyor.
Cursor, Copilot, v0 veya Claude Code ile üretilen arayüz bileşenleri ilk bakışta doğru görünse de zamanla tasarım token'larından, erişilebilirlik kurallarından ve hata durumlarından sessizce uzaklaşıyor. Faros AI'nin 2026 mühendislik raporuna göre kod değişim hacmi AI öncesi döneme kıyasla %861 artmış, PR'ların %31,3'ü ise hiç insan incelemesinden geçmeden birleştiriliyor. Bu boşluğu doldurmak için birçok ekip, bir AI modelinin ürettiği kodu başka bir AI modeline denetletme yoluna gidiyor.
Bu yaklaşımın üç yapısal sorunu var: LLM tabanlı denetim deterministik değil (aynı diff'e her seferinde aynı yanıt gelmiyor), token maliyeti kod üretimiyle birlikte katlanarak büyüyor ve bir kara kutunun başka bir kara kutuyu denetlemesi, bulguların neden işaretlendiğini açıklanabilir kılmıyor. Bu üç özellik, bir kontrolü merge'i durdurmak için güvenilir kılan niteliklerin tam tersi.
Alternatif olarak önerilen mimari, aynı girdiye her zaman aynı çıktıyı veren versiyonlanmış, deterministik bir kural motoru. Bu motor tasarım kaynağı ile kodu karşılaştırarak kaymayı bir fark (diff) olarak sunuyor ve dokuz farklı boyutta çalışıyor: tasarım tutarlılığı, erişilebilirlik, kullanıcı deneyimi, güvenilirlik, sürdürülebilirlik, mimari, test edilebilirlik, güvenlik/gizlilik ve AI kod yönetişimi. Bulgular sadece işaretlenmiyor, önerilen düzeltmelerle birlikte geliyor; bastırılan uyarılar ise git üzerinde görünür, gerekçeli bir karar olarak kayda geçiyor. Sistem hangi AI aracının kodu ürettiğine bakılmaksızın çalışıyor; VS Code içinde, Figma ile çift yönlü senkronizasyonla ve GitHub Action olarak PR'larda devreye giriyor. Şu an özel beta aşamasında ve kayıtsız bir playground üzerinden canlı test edilebiliyor.