AI Product Audit nedir? Bir üründe neyi kontrol ediyorum?

AI ile ürün geliştirme çok hızlandı. Bunun yan etkilerinden biri, bir ürünün yapısının ekip onun mimarisini gerçekten anlamadan büyüyebilmesi. Onlarca route, yüzlerce component, birkaç backend entegrasyonu ve çalışan bir production deploy var; ama 'sistem neden böyle?' sorusunun cevabı zayıf.

Audit'in amacı hata avlamak değil, ürünün gerçek haritasını çıkarmaktır.

1. Önce ürün kapsamını çıkarıyorum

Koddan önce ürünün ne olmaya çalıştığını anlamak gerekiyor. Aynı işi yapan iki özellik var mı? Kullanılmayan ama bakım isteyen modüller var mı? Ürün vaadi ile mevcut UI aynı şeyi mi söylüyor?

1type ProductMap = {2  corePromise: string;3  primaryFlows: string[];4  secondaryFlows: string[];5  suspectedNoise: string[];6};

2. Route ve domain haritası

Sonra uygulamanın yüzeyini sayıyorum: route'lar, ana domain'ler, shared component'ler, state store'ları, API endpoint'leri, tablolar, RPC'ler ve entegrasyonlar. Bu bana karmaşıklığın nerede yoğunlaştığını gösteriyor.

Sayılar tek başına kalite ölçmez; ama 70 route ve 20 veri domain'i olan bir ürünün üç route'lu MVP gibi yönetilemeyeceğini gösterir.

3. Kaynak doğrularını arıyorum

Görev verisinin kaynağı neresi? Auth state kimde? Subscription entitlement hangi sistemde canonical? Aynı karar birden fazla yerde tutuluyorsa audit bunu P0/P1 seviyesinde görünür hale getirebilir.

4. Network ve maliyet davranışı

Uygulama backend ile neden konuşuyor? Aynı route kaç request üretiyor? Polling, realtime ve refetch stratejileri birbirini tekrar ediyor mu? Bu katman performans ve fatura problemlerinin kökünü gösterebilir.

1type NetworkAudit = {2  requestsPerSession: number;3  duplicateFetches: string[];4  pollingLoops: string[];5  cacheGaps: string[];6};

5. Güvenlik ve authorization

RLS, server authorization, secret yönetimi, public endpoint'ler, upload policy'leri ve admin yüzeyi kontrol edilir. UI'da görünmeyen bir butonun gerçek güvenlik olmadığını özellikle doğrulamak gerekir.

6. UX karmaşıklığı

Audit yalnızca backend değildir. Aynı kullanıcı işini üç farklı modal mı çözüyor? Mobilde keyboard formu eziyor mu? Dashboard eşit önemde 20 kart mı gösteriyor? Teknik borç bazen component ağacında değil, ürün kararında oluşur.

7. AI-generated complexity

AI ile geliştirilmiş projelerde özellikle paralel abstraction, kullanılmayan helper, birbirini tekrar eden hook ve agent'ın bir problemi çözmek için kurduğu ikinci sistemlere bakıyorum.

1const suspicious = [2  'duplicate domain service',3  'two auth wrappers',4  'three sync engines',5  'unused abstraction layer',6];

8. Release ve production farkı

Build geçmesi yeterli değil. Dynamic import, cache, service worker, environment farkı, mağaza build'i ve gerçek cihaz davranışı audit kapsamına girebilir. Çünkü bazı problemler yalnızca production topolojisinde görünür.

Çıktı nasıl olmalı?

İyi audit yüzlerce maddelik korku listesi üretmemeli. Önceliklendirilmiş karar listesi üretmeli.

1type AuditFinding = {2  severity: 'P0' | 'P1' | 'P2' | 'P3';3  evidence: string;4  impact: string;5  smallestFix: string;6  rewriteRequired: boolean;7};

• P0: güvenlik, veri kaybı veya kritik production riski.
• P1: ölçek, maliyet veya temel kullanıcı akışını bozan mimari problem.
• P2: sürdürülebilirlik ve performans borcu.
• P3: temizlik ve iyileştirme fırsatı.

Audit'in amacı yeniden yazmak değil

Bir ürünü incelemek kolayca 'baştan yazalım' sonucuna dönüşebilir. Ben bunu son seçenek olarak görüyorum. Çoğu sistemde önce kaynak doğrularını netleştirmek, gereksiz işleri silmek ve kritik akışları tekleştirmek daha yüksek getiri sağlar.

İyi audit daha fazla iş üretmez; hangi işin yapılmaması gerektiğini de ortaya çıkarır.