تصور کنید برنامه‌نویسی هستید که باید یک ماژول قدیمی و پیچیده را بازنویسی کند، یک باگ سخت و آزاردهنده را برای یک عضو تازه‌وارد تیم توضیح دهد، یا سازگاری API را در میان چهل فایل مختلف حفظ کند؛ آیا یک جدول رتبه‌بندی (Leaderboard) واقعاً می‌تواند پیش‌بینی کند کدام ابزار AI در این لحظه در مواجهه با این چالش‌های خاص موفق خواهد بود؟ حقیقت این است که محک‌های استاندارد، توانایی مدل را در حل مسائل دست‌چین‌شده می‌سنجند، اما واقعیتِ جریان کاری شخصی یک توسعه‌دهنده — که تنها محک صادقانه برای یک دستیار کدنویسی است — را نادیده می‌گیرند.
این تغییر رویکرد در زمانی رخ می‌دهد که صنعت به‌شدت به محک‌های استاتیک وابسته شده است؛ ابزارهایی که اغلب به‌جای سنجش کاربرد واقعی مدل، خودِ ساختارِ محک را اندازه می‌گیرند. مدلی که صدر جدول‌های کدنویسی را می‌گیرد، در واقع مسائلی را حل کرده که یک نویسندهٔ محک انتخاب کرده، با کدی که همان نویسنده نوشته و بر اساس معیارهایی که او ابداع کرده است. برای یک برنامه‌نویس معمولی، امتیاز بالا در یک لیست عمومی به‌ندرت به معنای کاهش زحمات روزانه است. تفاوت این وضعیت شبیه تفاوت بین داوطلبی است که در یک آزمون استاندارد نمره کامل می‌گیرد با کسی که واقعاً می‌تواند یک قابلیت جدید را در کدبیس خاص و پیچیده شرکت شما پیاده کند و آن را به تولید برساند.
زمینه و محدودیت‌ها
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، شفافیت در عملکرد ابزارها کلید اعتماد است. برای عبور از «حس‌های کلی» (Vibes) و رسیدن به داده‌های دقیق، آزمایش جدیدی با استفاده از MonkeyCode — یک دستیار کدنویسی با وزن‌های باز (Open Weights) — انجام شده است. باز بودن این پروژه برای این آزمایش حیاتی است، زیرا به کاربر اجازه می‌دهد به‌جای اعتماد به ادعاهای تبلیغاتی صفحهٔ اول وب‌سایت، دقیقاً ببیند ابزار در پشت صحنه چه می‌کند.
در این متدولوژی، برای حذف سوگیری‌های مالی از یک سرور رایگان و سهمیهٔ توکن مشخص استفاده شده است. وقتی توسعه‌دهنده‌ای برای اشتراک ابزاری پول می‌پردازد، ناخودآگاه کیف پول او به جای ابزار استدلال می‌کند؛ او به‌طور ناخودآگاه پیروزی‌های ابزار را برجسته و شکست‌ها را فراموش می‌کند تا هزینهٔ پرداختی را در ذهن خود توجیه کند. اما استفاده از یک سرور رایگان، این لنگر روانی را به‌طور کامل حذف می‌کند.
علاوه بر این، وجود یک سهمیهٔ توکن — هرچقدر هم که سخاوتمندانه باشد — برنامه‌نویس را مجبور می‌کند با هر پرامپت مانند یک ردیف از بودجهٔ مالی برخورد کند. این محدودیت نه یک نقص یا محدودیتی است که باید بابت آن عذرخواهی کرد، بلکه دقیقاً همان شرطی است که اندازه‌گیری را صادقانه و دقیق می‌کند.
سازوکار مصاحبه
فرآیند ارزیابی بر پایه یک اسکریپت bash است که هر نقطهٔ پایانی (Endpoint) را که از پروتکل chat-completions پشتیبانی کند، به یک گزارش مصاحبه شخصی تبدیل می‌کند. اگر یک Endpoint با این پروتکل صحبت کند، اسکریپت بدون تغییر کار می‌کند؛ در غیر این صورت، تنها تغییر مورد نیاز یک فراخوانی ساده با curl است. این سیستم سه معیار اصلی را برای هر درخواست در یک فایل CSV ثبت می‌کند:
- تأخیر (Latency): زمان پاسخ‌دهی مدل بر حسب میلی‌ثانیه.
- مصرف توکن: تعداد دقیق توکن‌های ورودی (Prompt) و خروجی (Completion).
- خروجی خط اول: ۱۲۰ کاراکتر اول پاسخ برای بازرسی و ممیزی سریع.
MonkeyCode در حال حاضر سهمیهٔ رایگان ۱۰ میلیون توکنی را برای این منظور فراهم کرده است. اگرچه این عدد سخاوتمندانه به نظر می‌رسد، اما هدف اصلی خودِ توکن‌ها نیستند، بلکه قضاوتی است که این محدودیت در ذهن کاربر ایجاد می‌کند. این اسکریپت عمداً «ساده» یا «احمق» طراحی شده است زیرا پاسخی را قضاوت نمی‌کند؛ این وظیفه صرفاً بر عهدهٔ توسعه‌دهنده است تا کاربر نتواند بعدها در مورد نتایج به خودش دروغ بگوید.
این ابزار برای اجرا تنها به curl و jq نیاز دارد. با نگه داشتن فایل‌های پرامپت در همان مخزن (Repository) نتایج، هر ردیف در فایل CSV مستقیماً به کلمات و دستورات دقیقی اشاره می‌کند که منجر به تولید آن خروجی خاص شده است.
چارچوب ارزیابی
هستهٔ این آزمایش نه در داده‌های خام، بلکه در قضاوت انسانی است که بر روی آن‌ها اعمال می‌شود. پس از هر اجرا، توسعه‌دهنده به سه پرسش دوگزینه‌ای (بله/خیر) روی کاغذ پاسخ می‌دهد:
۱. آیا این خروجی بدون هیچ تغییری وارد کدبیس شد؟
۲. آیا می‌توانستم آن را بدون خواندن مجدد متنِ گفتگو، برای همکارم توضیح دهم؟
۳. آیا اگر خودم آن را می‌نوشتم سریع‌تر بود؟
اگر پاسخ دو مورد از این پرسش‌ها «خیر» باشد، آن وظیفه فارغ از توانایی‌های تئوریک مدل، از جریان کاری AI حذف می‌شود. این پرسش‌ها برای تفکیک وظایفی طراحی شده‌اند که در آن‌ها AI باعث تقویت و شتاب‌دهی به برنامه‌نویس می‌شود، از وظایفی که در آن AI صرفاً یک واسطهٔ اضافی و کند ایجاد می‌کند.
در این میان، نسبت بین توکن‌های ورودی و خروجی در فایل CSV حیاتی‌ترین معیار است؛ زیرا این نسبت فاش می‌کند که آیا برنامه‌نویس واقعاً تفکر و تحلیل را به مدل تفویض کرده است یا صرفاً از AI برای تکمیل خودکار متن (Autocomplete) استفاده می‌کند.
تحلیل و محدودیت‌ها
این رویکرد، ارزیابی را از «سنجش سقف توانایی مدل» به «سنجش همکاری انسان و AI» تبدیل می‌کند. پس از یک هفته، فایل CSV داستانی را می‌گوید که هیچ محکی قادر به بیان آن نیست: شناسایی پرامپت‌هایی که به‌دلیل عدم درک مدل مدام بازنویسی می‌شوند و وظایفی که توکن‌ها را می‌سوزانند بدون اینکه کد کاربردی و قابل استفاده تولید کنند.
با این حال، این روش محدودیت‌های صادقانه‌ای دارد:
- پایداری توکن‌ها: سهمیهٔ ۱۰ میلیون توکنی یک وضعیت لحظه‌ای است و نه یک وعده همیشگی؛ کاربران باید برای اطلاع از محدودیت‌های فعلی به مخزن پروژه مراجعه کنند.
- زیرساخت: یک سرور رایگان هرگز نباید به‌عنوان زیرساخت تولید (Production) در نظر گرفته شود.
- حجم نمونه: لیست کارهای (Backlog) یک برنامه‌نویس برای ارزیابی ابزاری برای کل یک تیم کافی نیست.
- کیفیت ورودی: اگر پرامپت‌ها با همان دقتی که کدنویسی می‌شود نوشته نشوند، این روش بی‌فایده است؛ زیرا پرامپت‌های بی‌کیفیت، اندازه‌گیری‌های بی‌کیفیت تولید می‌کنند.
برای یک توسعه‌دهنده، «بهترین» مدل دیگر آن چیزی نیست که در صدر یک لیست است، بلکه مدلی است که اثر واسطه‌ای را در پروژهٔ خاص او به حداقل برساند. این متدولوژی قدرت را از نویسندهٔ محک به متخصص اجرایی منتقل می‌کند.
گام بعدی شما
- اسکریپت مذکور را دریافت کرده و آن را به یک سرور رایگان MonkeyCode متصل کنید.
- یکی از وظایف واقعی موجود در لیست کارهای امروزتان (Backlog) را با این روش اجرا کنید.
- نتایج CSV را با سه پرسش ارزیابی انسانی تطبیق دهید تا بفهمید آیا AI در این تسک خاص، سرعت شما را زیاد کرده یا فقط یک واسطهٔ کند است.
اما داستان سخت‌افزاری این تحول و هزینهٔ استنتاج در مقیاس بالا حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو