یک Agent می‌تواند در Benchmark امتیاز بالا بگیرد، در Demo یک تابع را سریع بنویسد، و در همان روز یک Pull Request غیرقابلMerge تولید کند. این‌ها سه سؤال متفاوت‌اند: «آیا رفتار مشخص را حل می‌کند؟»، «آیا یک انسان در وظیفهٔ محدود سریع‌تر تمام می‌کند؟» و «آیا این تغییر برای محصول ارزش دارد؟» مهندس خوب پاسخ‌ها را مخلوط نمی‌کند.
## اهداف یادگیری
پس از این درس می‌توانی سطح Evidence را برچسب بزنی؛ ادعای بهره‌وری را با جمعیت، دوره، معیار و محدودیت بخوانی؛ تفاوت Benchmark، Mergeability و ارزش Production را توضیح دهی؛ و برای کارهای پرریسک، سطح اختیار و Verification متناسب انتخاب کنی.
## جای درس در چرخهٔ سرتاسری
در چرخهٔ دوره، این درس پل میان `Observe` و `Verify` است. Observation یعنی دیدن یک خروجی؛ Verification یعنی آزمودن اینکه آن خروجی برای ادعای موردنظر کافی است. بعدتر برای Spec، TDD، Security و Review Evidence دقیق‌تری می‌سازیم. فعلاً یاد می‌گیریم چرا عدد جذاب یا گزارش موفقیت نباید جای سؤال درست را بگیرد.
## چهار ادعا که شبیه هم نیستند
**قابلیت** می‌پرسد آیا سامانه در یک ورودی و محیط تعریف‌شده به رفتار درست می‌رسد. یک تست پذیرفته‌شده یا Benchmark می‌تواند برای آن سیگنال باشد. **بهره‌وری** زمان، تلاش، کیفیت و همکاری انسان در یک جریان کار را می‌سنجد. **Mergeability** می‌پرسد آیا تغییر با قرارداد، Style، تست، امنیت، Migration، بازبینی و مالکیت مخزن سازگار است. **ارزش Production** اثر واقعی بر کاربر و کسب‌وکار را می‌پرسد: آیا لغو اشتباه کم شد، SLO حفظ شد، هزینهٔ پشتیبانی پایین آمد یا اعتماد مشتری آسیب ندید؟
یک Patch ممکن است قابلیت محلی داشته باشد اما Mergeable نباشد، یا Merge شود اما اثر محصولی نداشته باشد. برای مثال، Agent تست واحدی برای formatter می‌گذراند؛ اما در booking-platform مسیر هم‌زمانی، tenant و timezone پوشش داده نشده است. حتی Patch قابلMerge هم اگر Reminder را به همهٔ مشتریان در ساعت نادرست بفرستد، ارزش Production منفی دارد. بنابراین «چند خط کد تولید شد» و «چند Tool Call انجام شد» معیار ارزش نیستند.
## Evidence را با برچسب بخوان
استانداردهایی مانند NIST AI RMF برای مدیریت ریسک، زبان کنترل و چرخهٔ حاکمیتی می‌دهند؛ آن‌ها پیش‌بینی نمی‌کنند Agent مشخصی در مخزن ما بهتر است. پژوهش کنترل‌شده می‌تواند اثر را در جمعیت و وظیفهٔ خودش اندازه بگیرد. مستند رسمی، قابلیت و رفتار محصول در تاریخ مشخص را بیان می‌کند. گزارش فروشنده و تجربهٔ تیم، برای ساخت فرضیه مفیدند اما تعمیم علّی یا جهانی نیستند.
DORA 2025، در نسخهٔ تصحیح‌شدهٔ گزارش `v2025.2`، AI را تقویت‌کنندهٔ قوت و ضعف سیستم سازمانی توصیف می‌کند. جمعیت آن نزدیک به ۵٬۰۰۰ متخصص فناوری در سراسر جهان بود و شواهد گردآوری‌شده برای گزارش ۲۰۲۵ شامل بیش از ۱۰۰ ساعت دادهٔ کیفی و پاسخ‌های survey است. در این جمعیت، ۹۰٪ استفاده از AI در کار را گزارش کردند؛ بیش از ۸۰٪ گفتند AI بهره‌وری‌شان را افزایش داده است؛ ۵۹٪ اثر مثبت بر کیفیت کد را گزارش کردند. اعتماد نیز یک‌دست نیست: ۲۴٪ «زیاد/بسیار زیاد» و ۳۰٪ «کم/هیچ» اعتماد به کیفیت خروجی AI گزارش کردند (از جمله ۷٪ «هیچ»).
این‌ها association و perception پاسخ‌دهندگانِ همان گزارش و دوره‌اند، نه اندازه‌گیری کنترل‌شدهٔ زمان و نه اثبات علّی برای همهٔ تیم‌ها. خودِ سؤال‌های رسمی DORA نیز بعضی Outcomeها را با بازهٔ «سه ماه گذشته» می‌پرسند. پس «تیم‌ها احساس می‌کنند کمک گرفته‌اند» یا «کیفیت را بهتر دیده‌اند» مجوز این نتیجه نیست که ابزار در پروژهٔ ما سریع‌تر یا ایمن‌تر است؛ برای آن باید تعریف کار، baseline، زمان تا Merge، Defect و Evidence محلی را جدا اندازه بگیریم.
در جهت دیگر، یک آزمایش کنترل‌شدهٔ GitHub در ۲۰۲۲، ۹۵ توسعه‌دهندهٔ حرفه‌ای را به دو گروه تصادفی تقسیم کرد تا یک HTTP server جاوااسکریپت بنویسند. معیار، زمان تکمیل و عبور از suite تصحیح بود: گروه Copilot به‌طور متوسط ۵۵٪ سریع‌تر بود (۱ ساعت و ۱۱ دقیقه در برابر ۲ ساعت و ۴۱ دقیقه) و نرخ تکمیل ۷۸٪ در برابر ۷۰٪ داشت. این یک نشانهٔ مثبت برای همان جمعیت، همان دوره، یک وظیفهٔ محدود و همان ابزار است؛ گزارش فروشنده است، کار کوتاه و تازه‌ساخت دارد و زمان Review، نگهداشت، ادغام یا ارزش Production را اندازه نگرفته است.
METR در دادهٔ فوریه تا ژوئن ۲۰۲۵، RCT دیگری با ۱۶ مشارکت‌کنندهٔ باتجربهٔ متن‌باز، ۲۴۶ Issue واقعی از مخزن‌های خودشان و کارهای میانگین دو ساعته اجرا کرد. معیار، زمان پیاده‌سازی گزارش‌شده در تخصیص تصادفیِ AI مجاز/غیرمجاز بود؛ حالت AI مجاز ۱۹٪ بیشتر زمان برد (بازهٔ اطمینان گزارش‌شده: ۲٪ تا ۳۹٪ کندتر). این نتیجه خلاف حس مشارکت‌کنندگان بود، اما فقط همان جمعیتِ آشنا با همان مخزن‌ها، همان ابزارهای ابتدای ۲۰۲۵ و همان طرح مطالعه را پوشش می‌دهد؛ نه همهٔ تیم‌ها و نه ابزارهای بعدی.
به‌روزرسانی METR در فوریهٔ ۲۰۲۶ خودِ احتیاط را جدی‌تر می‌کند. جمعیت دادهٔ جدید ۵۷ توسعه‌دهنده در ۱۴۳ مخزن و بیش از ۸۰۰ کار از مطالعه‌ای بود که از اوت ۲۰۲۵ شروع شد؛ برای زیرمجموعهٔ شرکت‌کنندگان قدیمی، برآورد خام ۱۸٪ speedup و برای تازه‌جذب‌شده‌ها ۴٪ speedup بود، اما بازه‌ها شامل صفر بودند. مهم‌تر، انتخاب‌نشدنِ کاربرانی که نمی‌خواستند بدون AI کار کنند، تغییر نرخ پرداخت و دشواری ثبت زمان هنگام Agentهای موازی، معیار زمان را نامطمئن کرده است. خود METR می‌گوید اندازهٔ اثر، Evidence بسیار ضعیفی است. نتیجهٔ درست نه «AI همیشه کند است» و نه «AI اکنون حتماً سریع‌تر است»؛ نتیجه این است که ابزار، جمعیت، روش استفاده، تعریف کار و روش اندازه‌گیری باید ثبت شوند.
## Benchmark چه می‌گوید و چه نمی‌گوید؟
SWE-bench Verified یک subset انسانی‌بررسی‌شدهٔ ۵۰۰ مسئله از SWE-bench است که وضوح شرح مسئله، test patch و حل‌پذیری آن را بررسی کرده است. معیار اصلی، عبور Patch از تست‌های ارزیابی در محیط Dataset است. این معیار برای مقایسهٔ Agentها روی یک وظیفهٔ مشترک مفید است؛ اما مسئله‌های ثابت، Oracle مبتنی بر تست و محیط بازتولیدپذیر با صف واقعی تیم، تصمیم محصول و Production یکسان نیستند.
حتی معیار تست نیز کامل نیست. پژوهش UTBoost در سال ۲۰۲۵ parser و annotationهای SWE-bench را بازبینی کرد: در جمعیت ۵۰۰ مسئلهٔ Verified، ۲۷۱ مورد (۵۴٫۲٪) annotation تصحیح شد و ۷۹ Patch تولیدشدهٔ Agent که پیش‌تر Pass شمرده شده بود، با parser اصلاح‌شده نادرست تشخیص داده شد. این یک Audit از pipeline و نمونه‌های ارزیابی آن پژوهش است، نه اثبات بی‌ارزشی کل Benchmark یا همهٔ Patchها. درس عملی روشن است: امتیاز Benchmark را قابلیت مشروط بدان، نه گواه Mergeability یا امنیت؛ testهای مستقل، review و سناریوی واقعی هنوز لازم‌اند.
مثال ضعیف و علت شکست
لید تیم می‌گوید: «مدل ما در SWE-bench نمرهٔ خوبی دارد، پس migration timezone را کامل به Agent بدهید؛ اگر CI سبز شد deploy کنید.» این استدلال population، دوره، metric و فاصلهٔ Benchmark تا Production را حذف می‌کند. Migration به دادهٔ واقعی، Rollback، timezoneهای تاریخی، پنجرهٔ انتشار و پاسخ‌گویی انسانی وابسته است؛ CI ممکن است هیچ‌کدام را اندازه نگیرد.
مثال اصلاح‌شده
لید می‌گوید: «از Agent برای ساخت inventory از زمان‌های ذخیره‌شده و draft تست‌های تبدیل در محیط ایزوله استفاده کنید. تصمیم policy، Migration واقعی، Backup، canary و approval انتشار انسانی‌اند. خروجی را با fixtureهای DST، tenantهای جدا، Dry run و Rollback test ارزیابی می‌کنیم.» این طراحی از قابلیت محدود بهره می‌برد، ولی Evidence لازم برای ارزش و ایمنی را حذف نمی‌کند.
## ماتریس تصمیم: کجا ایجنت، کجا توقف؟
| نوع کار | اختیار پیشنهادی | Evidence و Gate | ناحیهٔ بدون ایجنت |
|---|---|---|---|
| Auth و مجوز | کشف Read-only یا Patch کوچک در sandbox | threat model، تست منفی نقش/tenant، review امنیت | تصمیم policy، اعطای مجوز واقعی، تغییر Secret |
| Migration | تحلیل و تولید draft | backup، Dry run، حجم/زمان، Rollback و approval | اجرای روی Production یا حذف داده |
| Documentation | Agent محدود | لینک منبع، مثال قابل‌اجرا و review مالک | اختراع رفتار محصول یا اعلام قابلیتِ تأییدنشده |
| Refactor تکراری | Agent یا حلقهٔ محدود | تست معتبر، Diff کوچک، lint/typecheck | تغییر هم‌زمان قراردادهای عمومی بدون تصمیم |
| Incident response | مشاهده و خلاصه‌سازی Read-only | timeline، metric/log مستقل و فرمان برگشت | deploy، حذف داده یا تغییر traffic بدون فرمانده Incident |
«ناحیهٔ بدون ایجنت» یعنی اختیار خودکار در آن عمل داده نمی‌شود، نه اینکه Agent هیچ کمکی نمی‌کند. در Incident، Agent می‌تواند Log را دسته‌بندی کند؛ تصمیم کاهش traffic، اطلاع‌رسانی و Rollback با انسانِ پاسخ‌گو می‌ماند. NIST AI RMF نیز مدیریت ریسک را در طراحی، استفاده و نظارت می‌خواهد؛ چارچوب، جای Threat model محصول یا کنترل فنی آماده نیست.
## به زبان ساده
Benchmark مثل آزمون رانندگی در پیست مشخص است؛ عبور از آن نشان می‌دهد راننده کاری را تحت قوانین پیست انجام داده، نه اینکه برای هر خیابان، باران، مسافر و تعمیر خودرو آماده است. Mergeability یعنی خودرو با قوانین شرکت حمل‌ونقل و بازبینی مکانیک هم می‌خواند. ارزش Production یعنی مسافر واقعاً سالم و به‌موقع رسیده است.
## مثال واقعی: کارت امتیاز Release برای رزرو
برای Patch جلوگیری از Double booking، تیم چهار ستون Evidence ثبت می‌کند: قابلیت با تست رقابتی و قید داده؛ بهره‌وری با زمان تا Review و تعداد رفت‌وبرگشت در همین تیم؛ Mergeability با CI، Diff، security review و تصمیم Migration؛ و ارزش Production با نرخ conflict، خطای 409 درست و شکایت مشتری پس از canary. هیچ ستون با نمرهٔ Benchmark پر نمی‌شود. اگر داده کافی نیست، نتیجه «هنوز نمی‌دانیم» است، نه ادعای موفقیت.
## آزمایشگاه: یک ادعای بهره‌وری را بازنویسی کن
**ورودی:** «Copilot تیم ما را ۵۰٪ سریع‌تر کرد؛ پس آن را برای همهٔ کارها فعال می‌کنیم.» **گام‌ها:** ۱. Population، period، metric و caveatهای غایب را مشخص کن. ۲. ادعا را به فرضیهٔ قابل‌آزمون تبدیل کن. ۳. برای دو برش کم‌ریسک در booking-platform معیار قبل/بعد تعیین کن. ۴. یک ناحیهٔ بدون ایجنت و دلیلش را بنویس.
**خروجی مورد انتظار:** مثلاً «در چهار هفته، برای refactorهای تکراریِ دارای تست، زمان median از شروع تا Merge، نرخ بازگشت CI، ساعت Review و Defect پس از انتشار را با baseline سه هفتهٔ پیشین می‌سنجیم؛ نمونه کوچک و تغییر هم‌زمان فرایند، علت را نامطمئن می‌کند.» Migration و مجوز Production خارج از rollout خودکار می‌مانند.
**Recovery:** اگر baseline یا Definition of Done ندارید، ابتدا آن‌ها را ثبت کن؛ درصدسازی از تعداد PR یا LOC پاسخ نیست. اگر اثر منفی یا نامعلوم شد، rollout را متوقف و task type، Context، ابزار و Oracle را بازبینی کن.
## خطاهای رایج و نشانه‌ها
- آمیختن perception با زمان اندازه‌گیری‌شده: پرسش‌نامه را «اثبات سرعت» خوانده‌ایم.
- تعمیم Benchmark: عدد Dataset را معادل کیفیت Production نوشته‌ایم.
- حذف جمعیت و دوره: مشخص نیست ابزار و کاربران چه کسانی و چه زمانی بوده‌اند.
- انتخاب یک معیار: سرعت می‌سنجیم ولی Review، Defect و Rollback را نادیده می‌گیریم.
- ناحیهٔ بدون ایجنتِ مبهم: Agent می‌تواند deploy یا Secret را تغییر دهد چون «کمک» تعریف نشده است.
## چک‌لیست راستی‌آزمایی
- [ ] هر عدد، جمعیت، دوره، metric، منبع مستقیم و caveat دارد.
- [ ] سطح Evidence را از ادعای آن جدا نوشته‌ام.
- [ ] قابلیت، بهره‌وری، Mergeability و ارزش Production را یکی نگرفته‌ام.
- [ ] Benchmark را با Oracle مستقل و review مخزن کامل کرده‌ام.
- [ ] برای کارهای پرریسک approval، rollback و مالک انسانی تعیین شده است.
- [ ] هیچ‌جا AI را ذاتاً یا همواره سریع‌تر و ایمن‌تر فرض نکرده‌ام.
## تمرین مستقل
برای پنج Backlog item زیر، سطح اختیار و Verification plan انتخاب کن: تغییر Copy صفحه، Refactor نام‌گذاری DTO، افزودن OAuth provider، Migration timezone رزروها، و خلاصه‌سازی Incident.
**Rubric پاسخ:** Copy و Refactor می‌توانند اختیار محدود با تست/Diff داشته باشند؛ OAuth به threat model، تست منفی و review نیاز دارد؛ Migration به Dry run، backup، Rollback و approval؛ Incident به read-only evidence و فرمانده انسانی. پاسخ خوب برای هر مورد Scope، Oracle، توقف و دلیل ریسک دارد، نه یک حکم واحد برای همه.
## جمع‌بندی
شواهد خوب به سؤال درست و دامنهٔ خودش جواب می‌دهد. Benchmark قابلیت مشروط می‌سنجد؛ آزمایش بهره‌وری یک جمعیت و کار محدود را؛ گزارش میدانی ادراک و زمینه را؛ و Production نیازمند Evidence محلی، review و مسئولیت انسانی است. در فصل‌های بعد این Evidence را به Spec، تست، Context و دروازه‌های تحویل وصل می‌کنیم.
## منابع مستقیم
- [DORA 2025 State of AI-assisted Software Development](https://dora.dev/research/2025/dora-report/)، [نسخهٔ تصحیح‌شده و Errata](https://dora.dev/research/2025/errata/) و [اعلام رسمی Google Cloud](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report) — نزدیک به ۵٬۰۰۰ پاسخ‌دهنده و metricهای ادراکی؛ association است، نه علت قطعی یا تضمین تیمی.
- [GitHub controlled productivity study](https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/) — پژوهش فروشنده با ۹۵ توسعه‌دهنده و یک وظیفهٔ HTTP server در ۲۰۲۲؛ تعمیم محدود.
- [METR early-2025 RCT](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — ۱۶ توسعه‌دهنده و ۲۴۶ Issue؛ نتیجهٔ تاریخی و زمینه‌مند.
- [METR 2026 experiment update](https://metr.org/blog/2026-02-24-uplift-update/) — توضیح مستقیم selection bias و محدودیت اندازه‌گیری دادهٔ جدید.
- [SWE-bench Verified](https://www.swebench.com/verified.html) و [UTBoost audit](https://aclanthology.org/2025.acl-long.189/) — Dataset و audit مستقیم pipeline؛ معیار آزمون، Evidence Production نیست.
- [NIST AI RMF 1.0](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10) — چارچوب مدیریت ریسک، نه کنترل آماده یا تضمین ایمنی.
به زبان ساده
عبور از Benchmark فقط نشان می‌دهد رفتار تعریف‌شده در محیط همان آزمون رخ داده است؛ Mergeability و ارزش Production سؤال‌های دیگری‌اند. برای تصمیم محلی باید جمعیت، دوره، معیار و محدودیت شواهد را کنار عدد بنویسیم.
مثال واقعی
مطالعهٔ کنترل‌شدهٔ GitHub در سال ۲۰۲۲ روی ۹۵ توسعه‌دهنده و یک وظیفهٔ محدود HTTP server سرعت بیشتری برای گروه Copilot گزارش کرد، اما زمان review و ارزش Production را اندازه نگرفت.