تصور کنید به جای هفته‌ها تست و بحث‌های بی‌پایان در جلسات، تنها ۹۰ دقیقه تعیین کند که آیا یک ابزار گران‌قیمت هوش مصنوعی وارد چرخه تولید شما شود یا خیر. این رویکردِ «بمان یا برو»، جایگزین داشبوردهای رنگارنگ و نظرات سلیقه‌ای برنامه‌نویسان شده است.
بسیاری از شرکت‌ها برای ارزیابی دستیارهای کدنویسی به داده‌های تله‌متری (Telemetry) و دوره‌های آزمایشی دو هفته‌ای تکیه می‌کنند. اما یک شرکت محصول‌محور با ابعاد متوسط، این روند را به یک «اسپایک» (Spike) ۹۰ دقیقه‌ای تغییر داده است. در این متد، ابزار باید یک مسئله‌ی مشخص و قابل اندازه‌گیری را در بازه زمانی تعیین‌شده حل کند، وگرنه فوراً کنار گذاشته می‌شود.
ارزیابی ابزارهای هوش مصنوعی معمولاً به بحث‌های پراکنده در راهروهای شرکت تبدیل می‌شود، چون هر بررسی‌کننده تسک متفاوتی را انتخاب می‌کند و تعریف «موفقیت» برای هر کس متفاوت است. برای حل این مشکل، این تیم متدی را به کار گرفت که ارزیابی را شبیه به یک آزمایش علمی با زمان توقف سخت مدیریت می‌کند. این رویکرد تضمین می‌کند که تصمیم نهایی پیش از ناهار گرفته شود، نه پس از هفته‌ها تحلیل داده‌های نامشخص.
زمینه و محدودیت‌ها
این تیم دریافت که دوره‌های آزمایشی سنتی داده‌های زیادی تولید می‌کنند اما هیچ حکم قطعی نمی‌دهند. چون هر بررسی‌کننده از تسک‌های متفاوتی استفاده می‌کرد، هیچ اجماعی بر سر موفقیت ابزار وجود نداشت. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر داده‌های کلی بدون بستر عملیاتی، اغلب منجر به تصمیمات غلط می‌شود. اسپایک با جایگزینی استدلال‌های کلی با یک حکم تک‌صفحه‌ای، این مشکل را حل می‌کند.
به نقل از گزارشی که در ۲۸ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، این تیم یک فرضیه سخت تعریف کرد: یک عامل (Agent) — شبیه به کارآموزی که دستورات را می‌گیرد و اجرا می‌کند — باید بتواند یک باگ ثبت‌شده در مخزن کد را بازتولید کرده و وصله‌ای (Patch) ارائه دهد که تمام تست‌های موجود را در ۹۰ دقیقه پاس کند. این تمرکز بر نتایج ملموس، پاسخی است به تضاد میان سرعت خروجی و کیفیت تحلیل در ابزارهای هوش مصنوعی که می‌تواند منجر به تضعیف قضاوت مهندسی شود. آن‌ها تعمداً از پرسش‌های کلی مثل «آیا ابزار هوشمند به نظر می‌رسد؟» دوری کردند، چون چنین معیارهایی با داده قابل حل نیستند. یک فرضیه دقیق و تیز، شواهدی تولید می‌کند که هر بررسی‌کننده‌ای می‌تواند در عرض پنج دقیقه آن‌ها را بازبینی و تایید کند.
برای کاهش هزینه‌های آزمایش، تیم از MonkeyCode استفاده کرد؛ یک پروژه متن‌باز که سرور رایگان و سهم ۱۰ میلیون توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — ارائه می‌دهد. این ساختار باعث شد اصطکاک مربوط به اجاره GPU یا مدیریت بودجه توکن در مرحله ارزیابی حذف شود. (افشا: این مقاله بخشی از فعالیت‌های ترویجی MonkeyCode است).
گردش‌کار فنی
تیم برای جلوگیری از آلوده کردن خط اصلی توسعه، از یک شاخه (Branch) موقت استفاده کرد. فرآیند طبق مراحل زیر پیش رفت:
- ایزوله‌سازی: ایجاد یک محیط کاری مجزا با دستور
git worktree add ../spike-bug-101 -b spike/bug-101تا تغییرات روی کد اصلی اثر نگذارد. - مستندسازی: ثبت یک فایل
SPIKE.mdدر مخزن برای تثبیت فرضیه و «شرایط حذف». این فایل صراحتاً موارد زیر را لیست می‌کرد: فرضیه (بازتولید باگ ۱۰۱ و پاس کردن مجموعه تست‌ها)، بازه زمانی (۹۰ دقیقه) و شرایط حذف (تغییر در فایل‌های غیرمرتبط، نادیده گرفتن تست‌ها یا ویرایش دستی کد پس از اتمام). - اجرا: توسعه‌دهنده گزارش باگ، مراحل بازتولید و دستور تست را به عامل داد و یک تایمر واحد را فعال کرد. در این مرحله، تنها وظیفه برنامه‌نویس ثبت شواهد بود، نه هدایت یا راهنمایی عامل برای رسیدن به جواب.
- جمع‌آوری شواهد: خروجی نهایی یک فایل شواهد کوچک بود. آن‌ها از دستوراتی مثل
time git diff > spike.patchبرای ثبت زمان و تغییرات،git diff --statبرای مشاهده آمار تغییرات وpytest -q 2>&1 | tee spike-test.logبرای ثبت خروجی تست‌ها استفاده کردند.
حکم دوتایی (Binary Verdict)
قانون پذیرش ابزار مطلق بود. اگر وصله ارسالی تست‌های شکست‌خورده را پاس می‌کرد، هیچ فایل غیرمرتبطی را تغییر نمی‌داد و در جلسه بازبینی کاملاً قابل توضیح بود، ابزار پذیرفته می‌شد. اما اگر عامل از بازه ۹۰ دقیقه‌ای فراتر می‌رفت، یکی از تست‌ها را نادیده می‌گرفت یا کدی غیرقابل‌فهم تولید می‌کرد، فارغ از اینکه سایر خروجی‌ها چقدر خیره‌کننده بودند، متد حذف می‌شد.
این روش یک بحث احساسی و گران‌قیمت را به یک رکورد تکرارپذیر تبدیل می‌کند. پس از توقف تایمر، تیم یک یادداشت تصمیم دو پاراگرافی برای مدیریت تهیه می‌کرد که شامل فرضیه، نتیجه مشاهده‌شده و حکم نهایی بود. در این یادداشت همچنین شرایط خاصی ذکر می‌شد که تحت آن‌ها تیم ممکن است در آینده دوباره به سراغ آن ابزار برود.
چرا اسپایک از بنچمارک بهتر است؟
این آزمایش محدود، تله‌ی تکیه بر محک (Benchmark) مدل‌ها را دور می‌زند. یک بنچمارک عددی را گزارش می‌کند، اما آن عدد نمی‌تواند به یک تیم بگوید که آیا ابزار با فرآیند بازبینی (Review Process) خاص آن‌ها سازگار است یا خیر. در واقع، بسیاری از تیم‌ها متوجه شده‌اند که رانش خاموش مدل‌های AI می‌تواند نرخ تشخیص باگ را کاهش دهد، در حالی که بنچمارک‌های کلی این افت کیفیت را نشان نمی‌دهند.
علاوه بر این، ممکن است یک چارچوب ارزیابی (Harness) نمره ۱۰۰٪ بگیرد در حالی که مدلِ درون آن تنها ۳۰٪ موفق باشد؛ این یعنی اندازه‌گیری در واقع «داربست» یا زیرساخت را سنجیده است، نه خودِ دستیار را. یک اسپایک ۹۰ دقیقه‌ای تنها معیاری را می‌سنجد که واقعاً اهمیت دارد: نتیجه در مخزن کد واقعی، با استفاده از تست‌های خود پروژه و در بودجه زمانی مشخص تیم.
محدودیت‌های واقعی
این رویکرد محدودیت‌های خود را دارد. یک اسپایک تنها یک برش از گردش‌کار را پوشش می‌دهد و ثابت نمی‌کند که ابزار می‌تواند کدهای قدیمی (Legacy)، طراحی معماری یا کارهای نگهداری طولانی‌مدت را مدیریت کند. شواهد به‌دست‌آمده وابسته به محیط هستند؛ ابزاری که در یک Monorepo مرتب موفق می‌شود، ممکن است در یک ساختار پیچیده از Microservice شکست بخورد. همچنین ۹۰ دقیقه برای کارهای اکتشافی که نیاز به بررسی عمیق دارند، بسیار کوتاه است.
برخی تیم‌ها باید از این متد دوری کنند:
- خریداران مقایسه‌ای: توسعه‌دهندگانی که بین چندین دستیار تردید دارند به یک چارچوب مقایسه‌ای جامع نیاز دارند، چون تکیه بر تک‌اسپایک‌ها ریسک نمونه‌برداری کم را به ارث می‌برد.
- تیم‌های تکامل‌یافته: کسانی که خط لوله‌های ارزیابی (Evaluation Pipelines) مستقر دارند، باید به همان مسیر ادامه دهند.
- ارزیابان غیرکدنویس: هر کسی که کیفیت کامنت‌های بازبینی یا بازخوردهای طراحی را می‌سنجد، به یک آزمایش کاملاً متفاوت نیاز دارد.
اسپایک یک فیلتر ارزان است تا قبل از به‌کارگیری ماشین‌های سنگین‌تر اجرا شود، نه جایگزینی برای آن‌ها. بدترین نتیجه یک «حذف»، تنها ۹۰ دقیقه شواهد مستند است.
گام بعدی شما
- برای ابزار بعدی که می‌خواهید تست کنید، یک باگ واقعی و سخت از ماه گذشته انتخاب کنید.
- یک فایل
SPIKE.mdبنویسید و شرایط حذف (Kill Conditions) را پیش از شروع تایمر دقیق کنید. - به جای هدایت مدل، نقش «ثبت‌کننده شواهد» را بازی کنید تا قدرت واقعی عامل را بسنجید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو