Auditor'un %35 Tasarruf Metodolojisi: Üç Analiz Katmanı

Geliştirme ekiplerinin çoğu, pratikte task'ların büyük kısmını en güçlü modele (genellikle Opus) yönlendirir. Bu bir strateji değil, varsayılan seçimden kaynaklanır. Oysa küçük kod değişiklikleri, syntax düzeltmeleri veya belirli refactor tipleri çoğu zaman Sonnet veya Haiku ile aynı çıktıyı üretir.

Ölçüm yöntemi

Auditor geçmiş 200-500 task'lık pencereden örnek seçer ve her task'ı küçük modellerle shadow modunda yeniden çalıştırır. Çıktılar otomatik kalite skoruna (diff doğruluğu, syntax validity, test-geçme oranı) tabi tutulur. Eşit kalite eşiğini geçen task tipleri için 'downgrade önerilir' etiketi üretilir.

Sınırlar

Shadow evaluation tüm task tipleri için anlamlı değil — mimari kararlar, büyük sistem refactor'ları veya çok-adımlı agent akışları hâlâ en güçlü modelden yararlanır. Auditor bu task tiplerinde 'Opus kal' önerisi verir, downgrade zorlamaz.

Şişkin system prompt'lar, her çağrıda tekrarlanan style guide'lar ve gereğinden büyük context pencereleri ölçülebilir maliyet üretir. Bu maliyet çıktının kalitesine büyük oranda katkı sağlamaz — ama ay sonunda faturanın %10-15'ini oluşturur.

Ölçüm yöntemi

Auditor benzer task tiplerinde prompt'un hangi segmentlerinin çıktıyı değiştirdiğini diff analiziyle ölçer. Segment-bazlı ablation çalıştırır: prompt'un belirli bölümlerini kaldırır ve çıktının kalite skorundaki değişimi kaydeder. Skora etki etmeyen segmentler 'gereksiz' olarak işaretlenir.

Ayrı bir analiz Anthropic prompt cache kullanımını takip eder: cache hit oranı < %30 olan büyük prompt segmentleri 'cache'lemeye aday' olarak işaretlenir. Doğru kullanımda cache'lenen input token'ın maliyeti 1/10.

En az konuşulan ama pratikte en büyük etkiye sahip katman. Bir developer yanlış döngüye girer, bir test agent'ı sonsuz iterasyon yapar, bir task normal baseline'ının 5-10 katı token yer. Ay sonunda beklenmeyen faturanın en yaygın kaynağı budur.

Ölçüm yöntemi

Auditor her task tipi için maliyet dağılımı (ortalama + standart sapma) kurar. Task tiplerini otomatik kümeler: 'small-refactor', 'auth-flow', 'schema-migration' gibi. Her aktif task için akan token harcaması baseline'a kıyasla kontrol edilir. 2-3σ üstü sapma tespit edildiğinde Slack bildirimi gönderilir — developer hâlâ pencereyi açıktayken.

Neden 'ortalama' değil?

Bu katmanın etkisi normal dağılmaz — bazı aylar hiç anomali olmaz, bazı aylarda tek bir olay aylık %20-30 fazladan harcama engeller. %5-10 aralığı 6 aylık pencerede ortalama — tekil olay bazında etki çok daha büyüktür.

Gerçek aralık ve dürüst sınırlar

Beta sürecindeki kullanıcılarda gözlemlenen tasarruf aralığı %20-50. Alt band zaten disiplinli kullanım yapan takımlarda (küçük modeli zaten kullanan, cache kullanımı olan, kodun kritik bölümlerini review'dan geçiren). Üst band Opus'u varsayılan yapan, prompt cache kullanmayan, anomali takibi olmayan takımlarda.

%35 rakamı bu aralığın ortalamasıdır — her takım için garanti değil, olasılık dağılımının merkezidir. Auditor kurulumundan sonraki ilk 30 gün içinde takımın beklenen band'ı görünür hale gelir; gerçek tasarruf rakamı bu ölçümden türer.

Dürüst çerçeveleme: %35 bir vaat değil, metodolojik bir tahmin. Production kullanımında beta sayısı büyüdükçe 'ortalama X, gözlenen Y' şeklinde daha net rakamlar yayınlayacağız.