اگر فقط تعداد token، LOC یا «حس می‌کنیم سریع‌تر شد» را بسنجیم، ممکن است تغییرات بیشتری تولید کنیم اما release قابل‌قبول کمتری داشته باشیم. Eval خوب رفتار واقعی تیم را با taskهای نماینده، آزمون پنهان و چند اجرای مستقل می‌سنجد و عدم‌قطعیت را پنهان نمی‌کند.
## اهداف یادگیری
پس از درس می‌توانی private eval نماینده بسازی؛ model، scaffold و budget را freeze کنی؛ hidden implementation-agnostic test و چند run طراحی کنی؛ time to accepted/released change، review، defect، cost و outcome کاربر را اندازه بگیری؛ و ادعاهای DORA و METR را با Scope و uncertainty بیان کنی.
## جایگاه در چرخه
Eval در `Learn → Plan` بازخورد می‌دهد، اما جای review و production safety نیست. benchmark مصنوعی سؤال «می‌تواند؟» را می‌پرسد؛ outcome delivery سؤال «آیا تیم تغییر درست را با هزینه و ریسک قابل‌قبول تحویل داد؟» را.
## طراحی private eval
نمونه باید از backlog واقعی و نماینده بیاید: bug timezone، idempotency، contract change، refactor کم‌خطر، و کار مستندسازی؛ taskهای انتخاب‌شده‌ای که فقط با یک ترفند خاص حل می‌شوند، اعتبار را کم می‌کنند. repository snapshot، issue، ابزار، model/version، scaffold، permission، seed، timeout، token/spend budget و rubric را freeze و hash کن. اگر این‌ها تغییر کنند، نتیجهٔ قبل و بعد قابل‌مقایسه نیست.
آزمون hidden باید implementation-agnostic باشد: به جای انتظار نام تابع یا شکل diff، behavior، invariant، compatibility، privacy و regression را بررسی کند. testهای visible برای راهنمایی خوب‌اند اما agent می‌تواند آن‌ها را special-case کند. سه تا پنج run مستقل برای هر task حداقل شروعی است؛ میانگین تنها کافی نیست. success rate، median/p90 زمان و هزینه، و بازه یا bootstrap uncertainty را کنار n و failure taxonomy گزارش کن. اگر sample کم است، «شواهد مقدماتی» بگو، نه «اثبات».
## معیارهایی که ارزش را نزدیک‌تر می‌کنند
- **Time to accepted change:** از شروع task تا پذیرش reviewer با DoD.
- **Time to released change:** تا rollout واقعی و نه فقط branch سبز.
- **Review burden:** زمان، رفت‌وبرگشت، اندازهٔ diff و تعداد تغییرات درخواستی.
- **Defect:** bug پیش از merge، پس از release، rollback و severity.
- **Cost:** spend مدل/ابزار، compute، CI و زمان مهندس؛ زمان بررسی را حذف نکن.
- **User outcome:** موفقیت workflow، latency، error، support و retention
مربوط به همان تغییر؛ LOC و token فقط telemetry هستند.
گروه مقایسه و baseline را ثابت و گزارش کن. selection effect، learning effect، task mix، novelty، کیفیت harness و تفاوت مهندس‌ها confounder هستند. اگر agent زمان تولید را کم اما review/defect را زیاد کرد، نتیجهٔ delivery لزوماً بهبود نیست.
## DORA، METR و زبان محتاطانه
DORA metrics برای delivery مانند deployment frequency، lead time، change failure rate و failed deployment recovery مفیدند، اما رابطهٔ مشاهده‌شده میان AI adoption و outcome **همبستگی است، نه رابطهٔ علّی اثبات‌شده**. سازمان‌ها با انتخاب ابزار، فرهنگ، اندازه و baseline متفاوت مقایسه می‌شوند؛ از یک نمودار DORA نسخهٔ جهانی یا هدف فردی نساز.
مطالعهٔ early-2025 METR روی گروهی از توسعه‌دهندگان باتجربه و taskهای مشخص، اثر کندشدن حدود ۱۹٪ را گزارش کرد؛ update بعدی و شرایط متفاوت نشان می‌دهد نتیجه به دوره، تجربه، ابزار و task حساس است. METR universal نیست و نباید پیش‌بینی هر تیم یا هر model تلقی شود. به منبع مستقیم، sample، design و uncertainty اشاره کن و با eval خصوصی خودت تعمیم را آزمایش کن.
## مثال ضعیف و اصلاح‌شده
بد: «Agent تعداد commit را دو برابر کرد، پس productivity دو برابر شد.» این metric با review و release قطع شده است. خوب: ۳۰ task نماینده با snapshot ثابت، دو شرایط با permission یکسان، پنج run، hidden tests و گزارش median/p90 زمان پذیرش، defect، review دقیقه، هزینه و user success مقایسه می‌شوند؛ نتیجه «در این setup و با uncertainty» نوشته می‌شود.
## سناریوی booking-platform
برای reschedule، baseline انسان/agent را بر taskهای success، race، DST و privacy بسنج. test پنهان response UTC، یک success/یک conflict، tenant isolation، idempotent replay و backward compatibility را بدون الزام به نام فایل می‌سنجد. release clock از commit تا cohort rollout ثبت می‌شود. اگر agent در happy path سریع‌تر اما در race و review بدتر است، adoption را محدود به کارهای کم‌خطر کن و harness/test را اصلاح کن، نه اینکه failure را حذف کنی.
## آزمایشگاه گام‌به‌گام
۱) ده task representative و معیار حذف/نگهداشت بنویس. ۲) snapshot، model، scaffold، budget، tools و permission را freeze و hash کن. ۳) visible acceptance و hidden behavior tests بساز. ۴) هر task را حداقل سه بار اجرا کن. ۵) accepted و released time، review، defect، cost و user metric را ثبت کن. ۶) median/p90، failure categories و uncertainty را گزارش کن. ۷) تهدیدهای learning، selection و task mix را فهرست کن.
خروجی مورد انتظار eval card، raw run log، aggregate، caveat و تصمیم adoption است. **Recovery:** اگر test به implementation وابسته است، آن را به behavior بازنویسی و runهای قبلی را invalid علامت بزن. اگر budget متفاوت شد، cohort جدید بساز. اگر یک run flaky است، حذفش نکن؛ علت و sensitivity analysis را ثبت کن. اگر defect بحرانی رخ داد، rollout متوقف و rollback runbook اجرا شود.
یک اجرای امن و قابل‌تکرار می‌تواند فقط روی snapshot محلی انجام شود:
set -euo pipefail
mkdir -p .tmp/eval-run-01
git rev-parse HEAD > .tmp/eval-run-01/commit.txt
pnpm exec vitest run tests/eval/hidden-reschedule.test.ts \
--reporter=json > .tmp/eval-run-01/results.jsonاین فرمان به‌صراحت **local/ephemeral** است و نام مسیر test نمونه‌ای است؛ اگر وجود ندارد، آن را اجرا نکن و `BLOCKED` ثبت کن. **Pseudo-command (اجرا نشود):** `eval aggregate --runs ./artifacts/runs --metrics accepted,released,review,defect,cost,user --ci 95%` فقط قرارداد تحلیل را نشان می‌دهد. خروجی قابل‌بررسی باید commit، setup hash، تعداد run، pass/fail هر task، median/p90، هزینه، missing data و بازهٔ uncertainty را داشته باشد. اگر یک task به‌علت محیط fail شد، آن را موفق یا ناموفق محتوایی حساب نکن؛ failure محیطی را جداگانه طبقه‌بندی کن.
در design، metric را پیش از دیدن نتیجه قفل کن. همچنین یک معیار guardrail مثل rollback یا privacy failure بگذار که با میانگین بهتر قابل‌جبران نباشد. این کار از reward کردن سرعتی جلوگیری می‌کند که defect شدید یا بار review بیشتری ساخته است.
## خطاهای رایج
- نتیجه‌گیری علّی از همبستگی DORA.
- universal کردن یک مطالعهٔ METR.
- تغییر هم‌زمان model، scaffold و budget.
- hidden testی که نام implementation را الزام می‌کند.
- یک run و میانگین بدون توزیع.
- سنجش LOC/token به‌جای accepted/released و user outcome.
## Verification
- [ ] taskها representative و private/hidden testها implementation-agnostic هستند.
- [ ] model، scaffold، budget، permission و snapshot freeze شده‌اند.
- [ ] چند run، n، uncertainty و failure taxonomy گزارش شده است.
- [ ] accepted/released time، review، defect، cost و user outcomes وجود دارد.
- [ ] DORA correlation و محدودیت METR صریحاً بیان شده‌اند.
## تمرین و Rubric
تیمی ادعا می‌کند «AI سرعت را ۳۰٪ زیاد کرد» چون LOC بالا رفت. طرح eval را اصلاح کن. Rubric: baseline و گروه مقایسه؛ task نماینده و hidden behavioral tests؛ freeze و چند run؛ time to accepted/released، review، defect، cost و user outcome؛ uncertainty و confounder؛ و زبان غیرعلّی دربارهٔ DORA/METR.
## جمع‌بندی
Eval معتبر، ابزار را در شرایط ثابت و روی outcome قابل‌مشاهده می‌سنجد. چند run، آزمون پنهان، معیار delivery و caveat از عدد درخشان اما بی‌زمینه مهم‌ترند؛ DORA و METR برای سؤال‌سازی مفیدند، نه وعدهٔ جهانی.
## منابع مستقیم
- [DORA 2025 State of AI-assisted Software Development](https://dora.dev/research/2025/dora-report/) — گزارش میدانی؛ correlation علت نیست.
- [DORA metrics](https://dora.dev/guides/dora-metrics/) — تعریف metricها؛ برای مقایسه context لازم است.
- [METR early-2025 study](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — یک RCT با Scope مشخص.
- [METR 2026 update](https://metr.org/blog/2026-02-24-uplift-update/) — update و caveat؛ universal نیست.
- [SPACE framework](https://doi.org/10.1145/3453928) — چندبعدی‌بودن productivity؛ metric واحد کافی نیست.
به زبان ساده
Eval باید task نماینده، setup ثابت، hidden behavioral test و چند run داشته باشد و زمان تا accepted/released change را بسنجد. LOC و token telemetry هستند، نه خودِ بهره‌وری یا ارزش کاربر.
مثال واقعی
METR در مطالعهٔ اولیهٔ ۲۰۲۵ خود روی توسعه‌دهندگان و Issueهای مشخص، کندشدن میانگین گزارش کرد؛ این نتیجه به جمعیت، ابزار و طراحی همان مطالعه محدود است و baseline تیم ما نیست.