Ne işe yarar
Sprint sözleşmesi generator ve evaluator arasında implementation başlamadan kurulan kontrattır. Anthropic’in “Designing harnesses for long-running agentic apps” yazısı bu deseni açıkça tarifler: generator ne inşa edeceğini ve başarının nasıl doğrulanacağını önerir; evaluator anlayışı sınar; iki taraf uzlaşana kadar müzakere eder; implementation ancak ondan sonra başlar. Sonuç: generator’ın ürettiğini evaluator’ın hemen reddetmesi ihtimali düşer. Evaluator rubriği ise aynı çıktıya farklı değerlendiricilerin neredeyse aynı notu vermesini sağlar. Anthropic’in “Demystifying Evaluations for AI Agents” çalışması iyi bir görevin tanımını şöyle koyar — iki alan uzmanı bağımsız olarak aynı geç/kal kararına varabilmelidir. Rubrik tam olarak bu izolasyonu sağlar: her boyut ayrı puanlanır, her bant ölçülebilir bir eşiğe bağlanır, değerlendirme varyansı düşer.Şablon — Sprint Sözleşmesi
Şablon — Evaluator Rubriği
Her hücre ölçülebilir bir eşik taşır; “iyi” ya da “yeterli” gibi öznel sözcükler yer almaz. Anthropic’in “Demystifying Evaluations” rehberi bu izolasyona özellikle vurgu yapar: her boyut ayrı puanlanmalı, tek bir nihai puana çökertilmemelidir. Bir boyut D alırsa sprint genel olarak başarısız sayılır — sert eşik (hard threshold) deseni.
Konvansiyon
Sprint sözleşmesi kod yazımından önce yazılır; sonradan retroaktif eklenen sözleşme ön-anlaşma değil, mazerettir. Rubrik tüm değerlendiriciler için aynıdır — ister insan ister LLM yargı olsun, aynı tablo kullanılır. İkisi de repoda yaşar; sprint sözleşmesisprints/NN-konu.md altında, rubrik evals/rubric.md altında. Oturum kapanırken sözleşme ve rubrik birlikte commit edilir; ileride “neden bu yolu seçtik” sorusu kanıt tabanlı cevaplanabilsin diye.
Özelleştirme
A/B/C/D dört bant bir varsayılan, kanun değil. Bazı ekipler beşli skala kullanır (1-5); bazıları pass/fail ile yetinir. Anthropic’in tarif ettiği frontend rubriği dört boyutlu olabilir, full-stack rubriği beş; alan değişince boyutlar da değişir. Tipik özelleştirme eksenleri:- Skala genişliği — pass/fail (en katı), A/B/C/D (varsayılan), 1-5 (ince ayrıntı).
- Boyut seçimi — frontend için “tasarım kalitesi” ve “özgünlük”; backend için “veri tutarlılığı” ve “geri-uyum”; ML için “metrik” ve “fairness”.
- Ağırlıklandırma — tasarım ve özgünlüğe daha fazla ağırlık vermek modeli estetik risk almaya iter; Anthropic’in açık gözlemi.
- Sert eşik — herhangi bir boyut D alırsa sprint başarısız; ekibe göre eşik C de olabilir.
Otomasyona bağlama
Rubriğin önemli kısmı deterministik olarak puanlanabilir. Code-based grader’lar LLM yargısından her zaman daha ucuz ve daha tutarlıdır. Tipik bağlamalar:- Test geçiş oranı → Kod doğruluğu bandı. CI çıktısı oran üretir; oran A/B/C/D eşiğine eşlenir.
- Lint, dependency-graph ihlal sayısı → Mimari uyum bandı. ESLint, Ruff, depcheck, madge gibi araçlar sayı üretir; sayı banda çevrilir.
- Coverage raporu → Test kapsamı bandı. Cobertura, lcov, pytest-cov çıktısı doğrudan banda eşlenir.
- Docstring kapsamı, broken-link sayısı → Doküman bandı. interrogate, pydocstyle, markdown-link-check raporları.
- Trace span sayısı, OTel semconv uyumluluğu → Gözlemlenebilirlik bandı. Trace store’a kısa bir sorgu.