‏دیزاین سیستم هم به eval نیاز داره

نویسنده می‌گه دیزاین سیستم‌ها سال‌هاست دارن از دل مهندسی نرم‌افزار وام می‌گیرن: نسخه‌گذاری، نام‌گذاری معنایی، قرارداد صریح و چرخهٔ منسوخ‌سازی. به گفتهٔ او چیز بعدی از یه جای دیگهٔ استک میاد. وقتی یه ایجنت روی سیستم تو کد تولید می‌کنه، داری مدلی رو که کنترلش دست تو نیست روی قانون‌هایی که خودت نوشتی اجرا می‌کنی و فقط امیدواری خروجی رعایتشون کنه — دقیقاً همون مشکلی که تیم‌های LLM چند ساله باهاش سر و کار دارن.

eval یه تست برای خروجیه که نمی‌تونی پیش‌بینی‌ش کنی: یه مجموعه ورودی رو ثابت نگه می‌داری، از مدل ردشون می‌کنی و نتیجه رو با ادعاهایی دربارهٔ اینکه جواب خوب چی باید داشته باشه می‌سنجی. چون همون ورودی ممکنه دفعهٔ بعد خروجی دیگه‌ای بده، هر کیس رو چند بار اجرا می‌کنن تا ببینن کدوم نتیجه می‌لرزه. ابزارهایی مثل promptfoo نوشتن و اجرای این تست‌ها توی CI رو ارزون کردن.

ورودی‌هاش رو هم از قبل داری: Code Connect کامپوننت‌های فیگما رو به کد واقعی وصل می‌کنه و از طریق MCP دستورهای هر کامپوننت رو هم با خودش می‌بره، AGENTS.md قراردادهای کل ریپو رو نگه می‌داره و اسکیل‌ها رویه‌های گام‌به‌گام رو. اینا با هم پرامپت تو هستن، ولی هیچ‌کدوم بهت نمی‌گن ایجنت گوش داده یا نه. نویسنده به بنچمارکی اشاره می‌کنه که توش بهترین مدل کمتر از یک‌سوم دستورها رو کامل رعایت کرده و هرچی دستورها طولانی‌تر و پرقیدتر شدن، این عدد پایین‌تر اومده.

یه eval دیزاین سیستم فهرستی از کارهاییه که انتظار داری ایجنت از پسشون بربیاد — مثلاً ساختن یه مرحلهٔ آنبوردینگ یا گرفتن تأیید قبل از حذف حساب — و برای هرکدوم دو جور ادعا می‌نویسی. دستهٔ اول مکانیکیه: پراپ‌ها رو با API واقعی کامپوننت می‌سنجه، هر رنگ و فاصله رو به توکن برمی‌گردونه و مطمئن می‌شه سراغ کامپوننت کتابخونه رفته نه مارک‌آپ دست‌ساز. دستهٔ دوم داوریه: انتخاب کامپوننت درست برای اون نیت، و دیدن حالت‌های خالی و خطا نه فقط مسیر خوش‌بینانه.

tests:
  - vars:
      prompt: "Add a confirmation before someone deletes their account."
    assert:
      - type: javascript
        value: file://assertions/validate-against-system.js
      - type: llm-rubric
        value: "Reaches for the confirmation dialog over a generic modal"

اون چک javascript همونیه که سیستم تو رو می‌شناسه و خودت باید بنویسیش؛ contains و regex آماده فقط سطح رو می‌خارونن و یه پراپ ساختگی یا رنگ هگز خام از دستشون در می‌ره. برای بخش داوری از یه مدل به‌عنوان داور با روبریک استفاده می‌شه که روی چک‌های باریک خوب جواب می‌ده و هرچی قضاوت ذهنی‌تر بشه لرزون‌تر. پرامپت‌ها هم باید در سطح نیت و کم‌جزئیات باشن؛ اگه خودت اسم کامپوننت رو بیاری، فقط ثابت کردی ایجنت دستور رو اجرا می‌کنه — Astryx متا به همین دلیل کامپوننت‌های مورد انتظار رو مخفی نگه می‌داره.

دلیل اینکه این یه مجموعه تسته نه یه چک تکی، اینه که زمین زیر پات تکون می‌خوره: مدل پشت ایجنت آپدیت می‌شه، یا یکی سه خط از AGENTS.md کم می‌کنه و یه رفتار بی‌صدا می‌شکنه. مثال نویسنده: یه PR اسم یه پراپ دیالوگ رو عوض می‌کنه، سوئیت اجرا می‌شه و شش تا از دوازده پرامپت هنوز اسم قدیمی رو برمی‌گردونن چون مپینگ Code Connect آپدیت نشده — و PR تا اصلاح، مرج نمی‌شه. کاری که eval می‌کنه اینه که خطاهای مکانیکی رو از روی میز جمع می‌کنه تا ریویوکننده وقتش رو صرف قضاوت‌های واقعی کنه.

نکات کلیدی:

• eval یعنی تست برای خروجی غیرقطعی: ورودی ثابت، اجرای چندباره، سنجش با ادعاهای مشخص
• Code Connect و AGENTS.md و اسکیل‌ها فقط پرامپتن؛ هیچ‌کدوم رعایت‌شدن قانون رو تأیید نمی‌کنن
• دو دسته ادعا: مکانیکی (پراپ، توکن، کامپوننت، دسترس‌پذیری) و داوری (انتخاب الگو، حالت خطا)
• پرامپت‌ها باید کم‌جزئیات و در سطح نیت باشن، وگرنه فقط فرمان‌بری ایجنت رو می‌سنجی
• جای اجرا شدنش کنار بقیهٔ گیت‌هاست، توی CI و روی هر تغییر