فرض کنید قرارداد سیستم ما اینه که شمارهٔ ورودی 09121234567 رو به شکل استاندارد 989121234567+ تبدیل کنه؛ یعنی شماره رو نرمال کنه. یکی از تستهای همین رفتار، شکست خورده و از Agent خواستیم مشکل رو درست کنه. نتیجهای که تحویل داده اینه::
// قبل
Assert.Equal("+989121234567", result.NormalizedPhone);
// بعد
Assert.NotNull(result.NormalizedPhone);بعد از اعمال تغییر توسط Agent، تست سبز شده، ولی دیگه همون چیز قبلی رو بررسی نمیکنه. قبلاً درستیِ خروجی مهم بود؛ الان تست پاس میشه و فقط کافیه یه چیزی برگرده.
این یه مثال فرضی بود، ازش هم نمیشه نتیجه گرفت که Agentها همیشه تست رو خراب میکنن یا همیشه کمهزینهترین راه رو انتخاب میکنن. ولی یه ضعف واقعی در طراحی فرایند رو نشون میده: اجراکننده تونسته معیار پذیرش کار خودش رو هم تغییر بده.
حالا سمت دیگهٔ ماجرا رو ببینید. برنامهنویس، Ticket رو از Jira کپی میکنه، مستندات رو جدا میفرسته، دستور Build رو اجرا میکنه، خطا رو توی چت برمیگردونه، و آخرش هم خودش PR رو میسازه.
Agent کد نوشته، ولی انسان تمام مدت داشته سیستمها رو به هم وصل میکرده. عنوان مناسبی که به این حالت میدیم Human-as-API است.
بین این دو وضعیت، مسئلهٔ اصلی این مطلب قرار داره: چجوری انتقال دستی اطلاعات رو کم کنیم، بدون اینکه اختیار تغییر سیستم و اختیار تأیید درستیِ اون تغییر، بیحساب در یک جا جمع بشن؟
و البته قبل از همهٔ اینها، یه سؤال اقتصادی هم داریم: انجامدادن این کار برای تیم ما چقدر میارزه؟
Agent-First رو چطور تعریف کنیم؟
اول دامنهٔ بحث رو روشن کنیم. این مطلب دربارهٔ Agentها در توسعه و نگهداری نرمافزاره؛ جایی که Repository، Build، Test، Review و استقرار داریم. بعضی اصولش ممکنه جای دیگه هم مفید باشن، ولی نتیجههای بهرهوری و شیوههای ارزیابی رو نمیشه بیبررسی به طراحی، پژوهش یا عملیات غیرکدی تعمیم داد.
خود اصطلاح Agent-First Development هم تعریف واحد و جاافتادهای حداقل هنوز نداره. پس بهجای اینکه وانمود کنم دارم تعریف رسمیاش رو توضیح میدم، میگم در این مطلب با چه تعریفی ازش استفاده میکنم.
من به یک جریان کار مشخص میگم Agent-First که در طراحی معمولش، Agent بتونه یک واحد کار رو از دریافت مسئله، تا تحویل خروجی قابل بررسی، جلو ببره؛ Context لازم رو پیدا کنه، ابزارها رو اجرا کنه، بازخورد بگیره و نتیجه رو ثبت کنه؛ بدون اینکه انسان برای هر انتقال اطلاعات یا شروع هر مرحله واسطه بشه.
این تعریف رو میشه در عمل بررسی کرد. برای یک نوع Ticket مشخص، ببینید کجاها حضور انسان لازمه: برای یک تصمیم واقعی، یا برای کپیکردن خروجی یک ابزار به ابزار بعدی؟
البته این مرز کاملاً صفر و یک نیست. ممکنه نگهداری مستندات یک تیم، Agent-First باشه و تغییرات Billing همون تیم، کاملاً تحت هدایت توسعهدهنده انجام بشه. بهتره دربارهٔ جریان کار حرف بزنیم، نه اینکه به کل شرکت یک برچسب بزنیم که Agent-First هست یا نیست.
Agentic بودن هم توی این متن به قابلیت Agent اشاره داره: هدف رو میگیره، برای رسیدن بهش برنامه میریزه، ابزار انتخاب میکنه و با بازخورد ادامه میده. Agent-First بودن به نحوهٔ جاگرفتن این قابلیت در فرایند اشاره میکنه.
هیچکدوم از این دو حالت، شاخصی برای کیفیت نیستن. یک جریان کار میتونه Agent-First باشه و بد طراحی شده باشه؛ همونطور که ممکنه CI/CD داشته باشید و استقرارتون همچنان پر از خطا باشه.
خب، این تغییر فرایند چه منفعتی داره؟ اینجا باید از تعریف فاصله بگیریم، و سراغ اندازهگیری بریم. اینکه Agent میتونه چند مرحله رو مستقل انجام بده، هنوز ثابت نمیکنه که مجموع کار سریعتر، ارزونتر یا بهتر شده.
شواهد دربارهٔ بهرهوری چی میگن؟
مطالعهٔ اول METR در سال ۲۰۲۵، روی توسعهدهندههای باتجربهٔ متنباز، افزایش ۱۹ درصدی زمان انجام کار با ابزارهای AI رو گزارش میکنه؛ و این درحالیه که شرکتکنندهها خودشون احساس میکردن سریعتر شدن!
مطالعهٔ بعدی، برآوردهایی به سمت تسریع داشت، ولی فاصلههای اطمینانش صفر رو هم در بر میگرفت؛ یعنی دادهها با این احتمال که زمان انجام کار اصلاً تغییر نکرده باشه هم سازگار بودن. علاوه بر این، مطالعه با مشکلات جدی در انتخاب شرکتکننده، انتخاب Task و ثبت زمان روبهرو بود. خود METR هم نتیجه گرفت که این طراحی، برآورد قابل اتکایی از اندازهٔ اثر فعلی نمیده و باید تغییر کنه.(گزارش METR)
درس این دو مطالعه برای من اینه: احساس سرعت رو، با سرعت اندازهگیریشده، یکی نگیریم، و نتیجهٔ یک گروه و یک دورهٔ ابزار رو هم به همهٔ تیمها هم تعمیم ندیم.
اینها به معنی غیرممکن بودن اندازهگیری نیست. به معنی سختترشدن طراحی یک مقایسهٔ منصفانه است.
DORA هم از رابطهٔ بین پذیرش بیشتر AI، با افزایش توان Delivery، و همزمان، افزایش بیثباتی میگه. در یه تحلیل تکمیلی هم، جابهجاشدن بخشی از زمان تولید، به بررسی و تأیید، بهعنوان یکی از توضیحهای ممکن مطرح میشه. این توضیح معقوله، ولی نباید اون رو تنها علت اثباتشده معرفی کنیم. (تحلیل DORA)
پس ممکنه کد سریعتر تولید بشه، ولی خروجیِ قابل استفاده به همون نسبت زیاد نشه. برای فهمیدن علت، باید کل مسیر رو ببینیم.
یک نکته هم دربارهٔ منابع: مستندات فروشندههای سرویسهای AI، برای فهمیدن اینکه ابزارشون چجوری کار میکنه مفیده. ولی برای اثبات اینکه استفاده از اون ابزار در تیم ما بازدهی مثبت داره، کافی نیست. در مقابل، فروشندهی سرویس AI بودن هم بهخودیخود یک ادعا رو باطل نمیکنه. باید روش، دامنه، و شواهد ادعاها رو بررسی کرد.
از کجا بفهمیم کار درست انجام شده؟
حالا برگردیم به تست اول؛ چون قبل از سنجش سرعت، باید بدونیم چی رو موفقیت حساب میکنیم.
تعداد تست، تعداد Assertion و Coverage اطلاعات مفیدی میدن، ولی هیچکدوم بهتنهایی نمیگن رفتارِ درست، حفظ و دنبال شده. در مثال اول، یک Assertion داشتیم و هنوز هم یک Assertion داریم. حتی ممکنه Coverage دقیقاً همون قبلی باشه. حتی تغییر همزمانِ کد و تست هم ذاتاً مشکوک نیست. خیلی از تغییرات سالم دقیقاً همین شکلیاند. از طرف دیگه، تغییر یک تست بهتنهایی هم میتونه معیار پذیرش رو بیاثر کنه.
پس مسئله رو نمیشه با ممنوعکردن کلیِ تغییر تست یا شمردن Assertionها حل کرد.
برای جریانهای کاری مهم، لازم داریم بخشی از ارزیابی مستقل بمونه. مثلاً تستهای پذیرش خودکار یا تستهای قرارداد، در یک مسیر کنترلشده و روی همون نسخهای اجرا بشن که قراره پذیرفته بشه. Agent نباید بتونه معیارهای این ارزیابی رو بهتنهایی تغییر بده؛ تغییرشون هم باید فرایند بازبینی مشخصی داشته باشه.
توجه داشته باشیم که فقط محافظت از فایلی که حاوی تست است، کافی نیست. اگه Agent بتونه تنظیمات اجرای تست، فهرست تستهای انتخابشده یا گزارش نتیجه رو عوض کنه، هنوز امکان دورزدن ارزیابی وجود داره. مرز اعتماد باید اجرای ارزیابی و ثبت نتیجه رو هم پوشش بده.
Mutation Testing هم میتونه کمک کنه: ابزار، تغییرات عمدی و کوچیکی در کد ایجاد میکنه و بررسی میکنه که آیا تستها متوجهشون میشن و شکست میخورن یا نه. این کار بخشی از ضعف تستها رو آشکار میکنه، ولی جای قرارداد درست و بازبینی رو نمیگیره. هیچکدوم از این ابزارها برگهٔ تضمینِ درستیِ نرمافزار نیستن.
و گاهی خود تست اشتباهه. اگه یه Assertion، جزئیاتی رو تحمیل کرده که بخشی از قرارداد نیست، اصلاحش ممکنه کاملاً درست باشه. چیزی که باید حفظ کنیم، رفتار معتبر سیستمه؛ نه هر تستی که از قبل وجود داشته.
این ما رو به یک تفکیک مهم میرسونه: دستور با محدودیت فرق داره.
وقتی توی Ticket یا AGENTS.md مینویسیم Acceptance Testها نباید تغییر کنن، داریم انتظارمون رو روشن میکنیم. این کار مفیده و میتونه احتمال خطا رو کم کنه. برای هر محدودیت مهم، بهتره سه سؤال جدا بپرسیم:
- Agent باید چه کاری انجام بده؟
- ابزار و دسترسیها چه کاری رو واقعاً ممکن میکنن؟
- چه کنترلی جلوی پذیرفتهشدن خروجی نامعتبر رو میگیره؟
مثلاً ممنوعیت تغییر Permission در یک فایل متنی، جای محدودیت Permission در سیستم مقصد رو نمیگیره. بررسیای که خود Agent گزارش میکنه هم همیشه همارز اجرای مستقل همون بررسی نیست. مدل و ابزار بهتر اهمیت دارن؛ میتونن خطا رو کمتر کنن. اما هرجا پیامد یک خطا جدیه، بهتره حفظ مرز رو فقط به رعایت دستور توسط مدل وابسته نکنیم.
Agent برای اجرای کار به چی نیاز داره؟
بعد از معیار پذیرش، نوبت محیطیه که کار داخلش انجام میشه.
Agent برای اصلاح کد باید بتونه پروژه رو اجرا کنه و بازخورد بگیره. اگه Build فقط روی لپتاپ یک نفر کار میکنه، بخشی از کار به پیداکردن پیشفرضهای پنهان تبدیل میشه. محیط قابل ساخت، Dependencyهای مشخص، دادهٔ تست مناسب و جدایی از Production، همینجا ارزش پیدا میکنن. محدودیت زمان، منابع و هزینه هم باید از شروع وجود داشته باشه؛ یک پایلوت کوچک هم میتونه وارد تکرار بینتیجه بشه.
البته اینها مختص Agent نیستن. تست قابل اعتماد و محیط تکرارپذیر قبل از AI هم ارزش داشتن. تفاوت احتمالی در اینه که اجرای مستقل و تکرارشونده، وابستگی به تنظیمات دستی رو پرهزینهتر میکنه.
از این حرف هم نباید یک پروژهٔ بیپایان برای آمادهسازی کل شرکت درآورد. لازم نیست همهچیز کامل بشه تا یک آزمایش محدود انجام بدیم. برای همون جریان کاری که انتخاب کردهایم، باید حداقلِ لازمِ اجرا، ارزیابی و کنترل اثر فراهم باشه.
محیط که آماده شد، هنوز باید معلوم باشه کار چیه.
Ticket مبهم، برای انسان هم مسئلهسازه. ولی راهحلش این نیست که قبل از هر کاری یک سند طولانی بنویسیم. برای مثال شمارهٔ موبایل، یک Task قابل اجرا میتونه این چیزها رو روشن کنه:
- یک ورودی مشخص و خروجی مورد انتظارش.
- رفتار ورودی نامعتبر.
- بخشهایی که تغییرشون در محدودهٔ کاره.
- قراردادهایی که باید حفظ بشن.
- بررسیهایی که برای پذیرش لازماند.
- ابهامهایی که Agent باید دربارهشون سؤال بپرسه.
همهٔ مسئلهها از اول اینقدر روشن نیستن. گاهی خودِ کار، پیداکردن علت خرابی یا بررسی چند راهحله. در اون حالت، خروجی مرحلهٔ اول میتونه گزارش تشخیص و گزینهها باشه؛ بعد دربارهٔ پیادهسازی تصمیم بگیریم.
یعنی لازم نیست ابهام رو با نوشتنِ زودهنگامِ یک جواب قطعی پنهان کنیم. مکتوبسازی هم همیشه سود خالص نیست. مستندات قدیمی، تصمیم موقتِ ثبتشده بهعنوان قانون، یا Specی که کسی بهروز نمیکنه، میتونن کار رو بدتر کنن. بهتره وضعیت تصمیم روشن باشه: قطعی، موقت، یا هنوز در حال بررسی؛ و معلوم باشه چه کسی مسئول اصلاحشه.
AGENTS.md میتونه محل دستورهای اجرایی و قواعد غیرمعمول پروژه باشه. ولی تعداد خطوطش معیار کیفیت نیست. پژوهشهای مرتبط هم نشون میدن اضافهکردن Context لزوماً موفقیت رو بیشتر نمیکنه و میتونه هزینه رو بالا ببره. اثر محتوا رو باید روی کارهای واقعی سنجید. (پژوهش Evaluating AGENTS.md)
نکته اینجاست که باید چیزی رو نوشت که Agent برای تصمیم درست لازمش داره و بهراحتی از خود پروژه پیدا نمیکنه؛ بعد مسئولیت نگهداریش رو هم بپذیرید.
حالا میرسیم به اتصال ابزارها؛ همون جایی که انسان معمولاً نقش کابل اتصال رو بازی میکنه!
هدف اتصال اینه که Agent بتونه اطلاعات لازم رو پیدا کنه و اقدامات مجاز رو انجام بده. MCP یکی از پروتکلهای اتصال Agent به ابزارها و منابع اطلاعاتیه. ولی صرف داشتن API یا استفاده از MCP، کیفیت این تعامل رو تضمین نمیکنه. مثلاً ابزار زیر اختیار گستردهای میده:
execute_sql(query)برای یک کار محدود، مثل تغییر اشتراک، ممکنه این رابط مناسبتر باشه:
get_subscription(customer_id)
preview_subscription_change(customer_id, plan)
apply_subscription_change(change_id)اینجا مشاهده، بررسی و مرور تغییرات، و اعمال تغییرات، از هم جدا شدن. ولی اینم مهمه که فقط «اسم توابع»، امنیت نمییاره. مرحلهٔ انجام تغییرات، باید مجوز رو بررسی کنه، ببینه که به یک پیشنمایش مشخص مربوط باشه و اگر وضعیت از زمان پیشنمایش عوض شده، اون رو تشخیص بده.
پیام خطا هم باید کمک کنه ایجنت بفهمه آیا باید ورودی رو اصلاح کنه، منتظر بمونه، سؤال بپرسه یا متوقف بشه. خطای مبهم و تلاش نامحدود، ترکیب پرهزینهایه.
برای کارهای طولانی هم وضعیت کار باید خارج از حافظهٔ موقت گفتوگو ثبت بشه: چه اقدامی انجام شده، چه چیزی منتظر تأییده و چه چیزی نباید دوباره اجرا بشه. داشتن Task ID مفیده، اما بهتنهایی جلوی اجرای تکراریِ یک اقدام اثرگذار رو نمیگیره.
هرچی این اتصالها بیشتر میشن، تعریف اختیار مهمتر میشه.
اجرای یک Unit Test روی کد ناشناخته، با اجرای همون تست توی یک محیط بدون Secret و با دسترسی شبکهٔ محدود، ریسک یکسانی نداره. ساختن فایل Migration هم با اجرای اون روی Production یکی نیست. پس سطح خطر رو فقط از اسم عملیات تعیین نکنیم. داده، مجوز، محیط اجرا، برگشتپذیری و دامنهٔ اثر هم مهماند.
اصل عملی اینه که Agent برای کار مشخصش، دسترسی لازم رو داشته باشه؛ و اقدامات اثرگذار از مسیر کنترلشده عبور کنن. اگر تأیید انسانی لازمه، باید روشن باشه انسان دقیقاً چه تغییری رو تأیید میکنه. تأیید یک توضیح مبهم مثل «اصلاح دیتابیس»، کنترل معناداری نیست. پیشنمایش تغییر، نسخهٔ تغییر و نتیجهٔ بررسیها باید همراه تصمیم باشن.
Prompt Injection هم یکی از دلایلیه که این مرزها اهمیت دارن. محتوای خواندهشده از مخزن یا ابزار، ممکنه شامل دستورات نامعتبر باشه. لازم نیست برای دفاع، اول ثابت کنیم این مسئله ذاتاً حلناشدنیه؛ کافیه تا بپذیریم اجرای اقدامات حساس، نباید فقط به درست تشخیصدادن مدل وابسته بمونه.
اینجا معمولاً میگیم انسان در حلقه میمونه. ولی حضور انسان بهتنهایی معیار کیفیت نیست.
اگه فرد Reviewer وقت یا Context کافی نداشته باشه، دکمهٔ تأیید فقط ظاهر کنترل رو حفظ میکنه. زیادشدن خروجی هم ممکنه همین مشکل رو تشدید کنه. از اون طرف، لازم نیست تمام بررسیها دستی بمونن. بخشی از کنترل معماری، قراردادها و رفتار رو میشه ماشینی کرد. مسئولیت انسانی با اجرای دستیِ تکتک بررسیها یکی نیست.
Agent هم بهتره تا خروجی قابل بررسی تحویل بده: Diff، نتیجهٔ تست، محدودیتهای بررسی و فرضهای مهم. این شواهد باید به نسخهٔ مشخصی از کار مربوط باشن؛ گزارش موفقیت یک نسخه، برای نسخهای که بعداً تغییر کرده کافی نیست. هرجا امکانش هست، نتیجهٔ ابزارها رو مستقلاً ثبت کنیم. توضیح Agent دربارهٔ اینکه چه اتفاقی افتاده مفیده، ولی جای خودِ سابقهٔ اجرا رو نمیگیره.
چطور بفهمیم ادامهدادن میارزه؟
همهٔ این کنترلها هزینه دارن. حالا میتونیم دقیقتر دربارهٔ Verification Tax حرف بزنیم.
منظورم از این اصطلاح در اینجا، هزینهٔ اضافیِ بررسی، اصلاح و پذیرفتن خروجی ایجنت، در مقایسه با روش جایگزینه. روی «اضافی» تأکید میکنم، چون کد انسانی هم Review و Test میخواد. نمیشه کل زمان بازبینیِ مسیر AI رو هزینهٔ جدید حساب کرد و مسیر انسانی رو بدون هزینه فرض گرفت.
دو نوع زمان هم باید جدا ثبت بشن: زمان فعال انسان، و زمان تقویمیِ انتظار. ممکنه تأیید ده دقیقه کار انسانی بخواد، ولی خروجی یک روز توی صف بررسی بمونه. اولی روی هزینه اثر میذاره و دومی روی زمان تحویل.
برای محاسبهٔ اقتصادی، فقط صورتحساب مصرف مدل کافی نیست. زمان تعریف کار، بازبینی، اصلاح، اجرای زیرساخت، نگهداری اتصالها و تلاشهای ناموفق هم باید وارد بشن. مثلاً باید هزینهٔ هر خروجی پذیرفتهشده رو هم از کل هزینهٔ تلاشها حساب کنید؛ شامل کارهایی که شکست خوردن یا متوقف شدن. حذف شکستها، ظاهر میانگین رو بهتر میکنه.
پس از کجا شروع کنیم که گرفتار پروژهٔ آمادهسازیِ بیانتها نشیم؟
یک گروه محدود از کارها رو انتخاب کنید؛ مثلاً رفع یک نوع خطای مشخص یا بهروزرسانی مستندات. کارهایی که خروجیشون قابل ارزیابیه و اثرشون کنترلپذیره.
قبل از شروع، بنویسید دنبال چه بهبودی هستید: کاهش زمان فعال انسان، کوتاهشدن انتظار، افزایش ظرفیت، یا بهترشدن کیفیت. ممکنه همهٔ اینها همزمان بهتر نشن.
بعد یک مقایسهٔ قابل قبول بسازید. اگر همزمان تست و محیط اجرا رو بهتر کردهاید، مقایسهٔ صرفِ قبل و بعد، سهم ایجنت رو مشخص نمیکنه. تا حد امکان، روش بدون ایجنت و روش با ایجنت رو روی زیرساخت مشابه و کارهای قابل مقایسه بررسی کنید.
طی یک پایلوت کوچک لازم نیست ادعای پژوهش عمومی داشته باشیم. ولی باید انتخاب Taskها، تفاوت دشواری و موارد حذفشده رو ثبت کنیم؛ و فقط موفقیتهای قشنگ رو نگه نداریم.
برای مدت، بودجه و شرط توقف هم از قبل توافق کنید. مثلاً دو تا چهار هفته میتونه یک پنجرهٔ زمانی اولیه برای بعضی تیمها باشه؛ عدد علمی یا نسخهٔ عمومی نیست. تعداد کار، تنوعشون و دیر ظاهرشدن بعضی خطاها روی کفایت این بازه اثر دارن.
تمدید آزمایش هم باید دلیل داشته باشه: مثلاً یک گلوگاه مشخص پیدا شده و رفع اون در بودجهٔ محدود ممکنه. صرف اینکه هنوز نتیجه خوب نشده، دلیل ادامه نیست.
فرض کنید در همین کارهای مربوط به شمارهٔ موبایل، زمان نوشتن کد کمتر شده، ولی بازبین برای فهمیدن فرضهای Agent و اصلاح خروجی، وقت بیشتری میذاره. هنوز نمیشه گفت این جریان کار بهتر شده. اگه علت مشخصی پیدا کردهایم، مثلاً ابهام در قرارداد ورودی، میتونیم اون رو اصلاح کنیم و با بودجه و بازهٔ زمانی ازپیشتعیینشده دوباره بسنجیم. اگه بهبود مورد انتظار حاصل نشد، محدودکردن یا متوقفکردن این کاربرد هم باید روی میز باشه.
اینجا ممکنه برای توضیح افت اولیه به منحنی J اشاره کنیم؛ الگویی که در اون عملکرد اول افت میکنه و بعد از سطح اولیه بالاتر میره. اما هر افتی، شروع یک منحنی J نیست.
هزینهٔ یادگیری و تغییر فرایند ممکنه باعث افت اولیه بشه. اما از وجود افت، نمیشه نتیجه گرفت که رشد بعدی حتماً در راهه. اگه ادعا اینه که تیم هنوز در مرحلهٔ یادگیریه، باید نشونهای از پیشرفت ببینیم: کاهش کمکهای دستی، کمترشدن اصلاحات تکراری، یا پایینآمدن هزینهٔ خروجی پذیرفتهشده. افزایش نرخ شکست تغییرات هم صرفاً با نامگذاری بهعنوان هزینهٔ گذار، قابل توجیه نیست. باید علت و شدت اون بررسی بشه.
یک توضیح خوب باید اجازه بده به نتیجهٔ نامطلوب هم برسیم: این جریان کار، با این ابزار و این هزینه، فعلاً نمیارزه.
برای رسیدن به این تصمیم، چند سنجه رو کنار هم لازم داریم.
زمان رسیدن به اولین خروجی کافی نیست. زمان تا پذیرش، وقت فعال انسان، انتظار بازبینی، اصلاحات بعدی و نقصهای کشفشده پس از تحویل هم مهماند. موفقیت در اولین اجرای تست میتونه علامت کمکی باشه، ولی با انتخاب کار آسون یا اجرای بررسیهای کمتر هم بهتر میشه. تعداد خط کد و مصرف Token هم بهتنهایی نمایندهٔ ارزش نیستن.
سنجههای تحویل DORA (اینجا توضیح دادم قبلاً) میتونن تصویر مکمل بدن: فراوانی استقرار، زمان تغییر تا استقرار، نرخ شکست، زمان بازیابی استقرار ناموفق و نرخ بازکاری استقرار. اینها رو هم باید در زمینهٔ سرویس و نوع تغییر تفسیر کرد. (راهنمای رسمی DORA)
کمترشدن زمان تحویل، همراه با بیشترشدن خطا، نیازمند بررسی اندازه و پیامد هر دو تغییره. یک خطای سریعاً قابل بازیابی، با ازدسترفتن داده وزن یکسانی نداره. و اگر زمان بازبین بالا رفته، اول ببینید تغییرها بزرگتر یا دشوارتر نشدهاند. اگه معلوم نباشه زمان یا هزینه رو بهازای چه مقدار و چه نوع کاری میسنجیم، عدد حاصل میتونه همونقدر گمراهکننده باشه که احساس شخصیِ سرعت.
بعد از این آزمایش، لازم نیست تا یک مدل بلوغ مشخص رو دنبال کنیم.
ممکنه برای یک تیم، Agentی که فقط تشخیص میده و پیشنهاد میسازه بهترین انتخاب باشه. برای یک نوع کار دیگه، ساخت خودکار PR مناسب باشه. بعضی تغییرات کمخطر هم ممکنه پس از بررسیهای مشخص، خودکار پذیرفته بشن. اینها انتخابهای طراحیاند. استقلال بیشتر، بهخودیخود موفقیت بیشتر نیست. داشتن چند Agent هم همینطوره. اگر تقسیم کار، هزینهٔ هماهنگی و بررسی رو بیشتر از منفعتش بالا ببره، تعداد بیشتر فقط پیچیدگی بیشتری ساخته.
و آخرش برگردیم به سرمایهگذاری روی زیرساخت.
تست قابل اعتماد، محیط تکرارپذیر و مستندات قابل نگهداری ممکنه بدون Agent هم توجیه داشته باشن. این مزیت مهمیه، چون بخشی از سرمایهگذاری مستقل از نتیجهٔ آزمایش باقی میمونه.
ولی لازم نیست هر جزء بهتنهایی سودآور باشه. یک اتصال مشخص، ممکنه فقط در ترکیب با ایجنت ارزش بسازه. اون ترکیب رو باید با هزینهٔ کاملش سنجید. خودِ زیرساخت هم رایگان و بینهایت مفید نیست. ساخت و نگهداریش هزینه داره و منابع رو از کارهای دیگه میگیره. سؤال اینه که برای مسئلهٔ مشخص ما، چقدرش لازمه و چه چیزی نشون میده بیشترساختن هنوز میارزه.
اون دو خط تست در ابتدای مطلب، ضعف یک معیار پذیرش رو نشون میدادن. اصلاحشون به ما یک Agent-First موفق نمیده؛ فقط یکی از راههای اشتباهفهمیدن موفقیت رو میبنده.
برای تصمیم نهایی، هنوز باید بتونیم بگیم: چه کاری واگذار شده، با چه اختیاری، چجوری بررسی شده، مجموعاً چه هزینهای داشته و نسبت به روش قبلی چه ارزشی ساخته.
اگه جواب اینها روشن شد و نتیجه خوب بود، گسترشدادن معنا داره. اگه نتیجه خوب نبود، محدودکردن یا متوقفکردن هم یک تصمیم مهندسی معتبره. قرار نیست هر آزمایشی به پذیرش بیشتر ختم بشه.