نصف متریک‌های دیزاین سیستم دیگه به درد نمی‌خورن
فرانتاند
هوش مصنوعیخلاصهٔ کامل‌تر
Romina Kavcic تو این مقاله لیست متریک‌های دیزاین سیستمی که چهار سال پیش جمع کرده بود رو دوباره مرور کرده و می‌گه نصفشون دیگه کار نمی‌کنن. قبلاً adoption (یعنی اینکه چندتا تیم و محصول از سیستم استفاده می‌کنن) تنها عدد مهم بود. ولی حالا یه کاربر جدید داریم: ایجنت‌های هوش مصنوعی که هر بار مستندات سیستم رو می‌خونن و باهاش کد می‌سازن. به نظر نویسنده باید قانون‌هایی بذاریم تا بفهمیم اونا کارشون رو درست انجام می‌دن یا نه.
متریک‌هایی که نگه داشته اینان: تعداد snowflakeها (یعنی کامپوننت‌های یک‌باره و بیرون از سیستم، هم تو Figma هم تو کد)، هشدارهای جدید linter که روندش باید نزولی باشه، نمره‌ی دسترس‌پذیری، زمان جواب دادن به سؤال‌های پشتیبانی، مدتی که طول می‌کشه محصول به نسخه‌ی جدید برسه، و هزینه‌ی تغییرات سراسری مثل ری‌برند یا عوض کردن توکن‌ها. مصاحبه با دیزاینرها و دولوپرها، دو بار در سال، هم به نظرش هنوز ساده و خیلی مؤثره.
متریک‌هایی که به گفته‌ی نویسنده باید کنار گذاشت، اونایی‌ان که فقط بالا می‌رن و چیزی بهت نمی‌گن. تعداد کل کامپوننت‌ها نشونه‌ی موفقیت نیست؛ یه سیستم با ۵۰ تا کامل میشه و یکی دیگه با ۸۰ تا. تعداد دانلود npm نشون نمی‌ده بعدش تیم‌ها با کد چی کار می‌کنن. تعداد زیاد فراخوانی MCP (یعنی پروتکلی که ایجنت‌ها باهاش به ابزارها وصل می‌شن) شاید فقط یعنی ایجنت گیج شده. گزارش موفقیتی که خود ایجنت می‌ده هم قابل اعتماد نیست.
یه سری متریک هم هنوز مفیدن ولی معنیشون عوض شده. مثلاً detach rate (یعنی چند بار یه کامپوننت از نسخه‌ی اصلیش جدا میشه): اگه تو یه سیستم چندبرندی برند اصلی خوب کار کنه ولی بقیه‌ی برندها خیلی بیشتر detach کنن، احتمالاً به سطح‌ها، آیکون‌ها یا کامپوننت‌های پیچیده‌تر کم فکر شده. نویسنده تطابق کامپوننت‌های Figma و کد، تعداد override و مقدارهای hard-code شده، زمان ساخت اولین صفحه برای آدم و ایجنت، و سرعت تحویل در مقایسه با یه baseline رو هم پیشنهاد می‌ده.
به گزارش‌ها هم باید چندتا چیز جدید اضافه کرد: چقدر از محصول واقعاً از کامپوننت‌ها و توکن‌ها استفاده می‌کنه، چند بار ایجنت چیزی می‌سازه که با قانون‌های سیستم جوره، هزینه‌ی هر خروجی قابل انتشار، و لیست کامپوننت‌هایی که کارشون رو درست انجام نمی‌دن. هدف اصلی اینه که بفهمی سیستم خروجی رو بهتر می‌کنه یا نه، و کیفیت خروجی چه آدم پرامپت بده چه ایجنت، باید یکی باشه.
eval یه کار واقعیه که از طریق ابزارها، مدل‌ها و کامپوننت‌هات اجرا میشه و با هدفی که داشتی نمره می‌گیره؛ یه چیزی شبیه user testing ولی برای ایجنت‌ها. نویسنده می‌گه برای انتخابش، مشکلات قبلی رو لیست کن و ببین شکستن کدوم قانون بیشترین ضرر رو به production می‌زنه. بعد یه اسکریپت یا لیست پرامپت بنویس و هر کار رو حداقل ۳ بار اجرا کن. با مدل‌های ارزون‌تر هم امتحان کن و با ۱۰ تا ۱۵ کار شروع کن.
نکات کلیدی:
- تعداد کل کامپوننت، دانلود npm و تعداد فراخوانی MCP به‌تنهایی چیزی درباره‌ی ارزش سیستم نشون نمی‌دن.
- تعداد snowflakeها، هشدارهای linter و نمره‌ی دسترس‌پذیری هنوز متریک‌های مفیدی‌ان.
- گزارش موفقیت خود ایجنت قابل اعتماد نیست و باید با هدف اصلی کار مقایسه بشه.
- برای شروع eval، ۱۰ تا ۱۵ کار واقعی کافیه و هر کار باید حداقل ۳ بار اجرا بشه.
- پایین اومدن هزینه و بالا رفتن pass rate ساده‌ترین راه نشون دادن ارزش سیستم به مدیرهاست.
