تصور کنید مدیر مهندسی هستید که می‌خواهد بداند آیا داشتن یک کتابخانه جامع از قطعات رابط کاربری، واقعاً خروجی عامل‌های کدنویسی را بهبود می‌بخشد یا صرفاً یک سند طولانی است که مدل‌ها آن را نادیده می‌گیرند. نتایج یک آزمایش دقیق نشان می‌دهد که سیستم‌های طراحی، عامل‌ها را باهوش‌تر نمی‌کنند، اما به‌طور بنیادی تغییر می‌دهند که در نهایت چه کسی مالک کد تولیدشده است.
بسیاری از تیم‌های توسعه در حال حاضر با سیستم‌های طراحی مانند مجموعه‌ای از دستورالعمل‌ها برخورد می‌کنند؛ فایلی در Figma اینجا، یا صفحه‌ای در Confluence آنجا. آن‌ها تصور می‌کنند ارائه این منابع به یک عامل (Agent) — شبیه دستیاری که دستورات شما را اجرا می‌کند — منجر به تولید کدی سازگارتر، ارزان‌تر و دقیق‌تر می‌شود. اما طبق گزارش این پژوهش، شکاف میان «نوشتن دستورالعمل» و «ارائه آن به شکل یک بسته نرم‌افزاری»، جایی است که تأثیر واقعی رخ می‌دهد.
ساختار آزمایشی
برای بررسی این موضوع، پژوهشگر سیستمی به نام design-system-blueprint ساخت؛ سیستمی که به‌جای یک دموی ساده، به عنوان یک محصول واقعی طراحی شده است. این سیستم بر پایه اصل «توکن‌ها به عنوان داده» و «قطعات به عنوان یک API عمومی نسخه‌بندی‌شده» بنا شده است. برای اطمینان از استانداردهای صنعتی، تمام خروجی‌های این سیستم در npm منتشر شده و در محیط CI (یکپارچه‌سازی مداوم) تأیید شده‌اند تا هرگونه تغییر به صورت خودکار تست شود.
معماری توکن‌ها
این سیستم برای حذف ابهام، یک سلسله‌مراتب سه‌لایه سخت‌گیرانه برای توکن‌ها اجرا می‌کند:
- لایه ۱ (گزینه‌ها - Options): شامل پالت‌های رنگی خام، مقیاس‌های اندازه و مفاهیم اولیه (Primitives).
- لایه ۲ (تصمیمات - Decisions): لایه معنایی که با پیشوند
--ds-decisions-*مشخص می‌شود. این تنها لایه‌ای است که یک اپلیکیشن اجازه دسترسی به آن را دارد. - لایه ۳ (داخلی - Internal): توکن‌های خصوصی مربوط به هر قطعه که می‌توانند بدون نیاز به تغییر نسخه اصلی (Major Version Bump)، تغییر کنند.
این مرز صرفاً یک قرارداد در ویکی یا مستندات نیست، بلکه توسط نقطه ورود CSS که منتشر شده است، به‌طور فیزیکی اجرا می‌شود و تنها لایه ۲ را در معرض دید قرار می‌دهد. منبع حقیقت (Source of Truth) در اینجا یک فایل tokens.json است. مجموعه‌های متغیر در فایل Figma مستقیماً از این JSON تولید می‌شوند. اگر خروجی Figma از منبع اصلی عقب بیفتد، تست‌ها با شکست مواجه می‌شوند. این رویکرد یک مشکل رایج در صنعت را حل می‌کند؛ در یک ممیزی قبلی روی سیستمی مشابه، مشخص شد که فایل طراحی بیش از صد متغیر با منبع کد فاصله داشت، زیرا هیچ مکانیزمی برای بررسی این شکاف وجود نداشت.
کتابخانه قطعات و قراردادهای عامل
این سیستم شامل ۱۴ قطعه مستقل Angular است: آکاردئون (accordion)، آواتار (avatar)، مسیر راهنما (breadcrumbs)، دکمه (button)، چک‌باکس (checkbox)، منوی کشویی (dropdown)، فوتر (footer)، هدر (header)، ورودی (input)، لیست (list)، مودال (modal)، رادیو (radio)، جدول (table) و تگ (tag). این قطعات با استفاده از ng-packagr بسته‌بندی شده و در Storybook مستند شده‌اند. تست‌های جامع شامل قراردادهای توکن، تست‌های واحد (Unit)، تعاملی (Interaction)، دسترسی‌پذیری (Accessibility) و رگرسیون بصری (Visual Regression) برای آن‌ها تعریف شده است.
نکته کلیدی این است که پژوهشگر «قراردادهایی نوشت که برای عامل‌ها بود، نه انسان‌ها»:
- اعلام نوع (Type Declarations): این‌ها داخل بسته tarball ارسال می‌شوند تا عامل‌ها بتوانند سطح واقعی ویژگی‌ها (Props) را بخوانند، بدون اینکه نیاز باشد کل کد منبع را اسکرپ یا تحلیل کنند.
- فایل AGENTS.md: این فایل در ریشه مخزن قرار دارد و مخصوص هر عاملی است که مستقیماً روی خودِ سیستم طراحی کار می‌کند.
- فایل llms.client.txt: یک فایل ۳ کیلوبایتی که داخل بسته npm ارسال می‌شود و برای عامل‌هایی است که از سیستم استفاده می‌کنند. این فایل انتخابگرهای (Selectors) موجود را مشخص می‌کند، تأکید می‌کند که «تطابق رفتاری» بر «تطابق استایلی» اولویت دارد و به عامل دستور می‌دهد که اگر هیچ توکن معنایی با قصد کاربر سازگار نبود، به‌جای انتخاب نزدیک‌ترین رنگ، گزارش «عدم پوشش» (no-coverage) بدهد.
- MCP Token Resolver: ابزاری با نام
@jablonowski/dsb-tokens-mcpکه به عامل اجازه می‌دهد از طریق پروتکل زمینهٔ مدل (Model Context Protocol) — شبیه یک مترجم که قصد کاربر را به کد فنی تبدیل می‌کند — یک هدف (مثلاً «پس‌زمینه برای اقدام اصلی») را به توکن تصمیم‌گیری درست تبدیل کند.
متدولوژی تست
این آزمایش در ۳۰ تکرار امتیازدهی‌شده اجرا شد (پنج اجرا برای هر یک از پنج بازوی آزمایشی روی مدل اصلی، به‌اضافه بررسی‌های صحت روی مدل دوم). برای حفظ دقت علمی، پژوهشگر از یک پرامپت کاملاً یکسان (Byte-identical) برای ساخت یک داشبورد کوچک Angular (شامل صفحه ورود، داشبورد و جدول کاربران) در یک جلسه تازه برای عامل و در یک دایرکتوری خالی استفاده کرد. فریم‌های Figma از طریق یک ضبط (Recording) ارائه شدند تا اطمینان حاصل شود که عامل در هر بار اجرا، دقیقاً همان بایت‌های یکسانی را می‌بیند.
پنج حالت (Arm) مورد بررسی عبارت بودند از:
- حالت A: فقط مشخصات فنی (Specification) و فریم‌های Figma.
- حالت A': مشخصات فنی به‌اضافه یک راهنمای متنی (پالت، مقیاس و CSS قطعات که به صورت متن یا Prose نوشته شده‌اند).
- حالت B: نصب کامل بسته‌های npm شامل READMEها و اعلام نوع (Type Declarations).
- حالت C: بسته‌های npm به‌اضافه راهنمای اختصاصی
llms.client.txtبرای مدل‌های زبانی. - حالت D: تمام موارد بالا به‌اضافه ابزار زنده MCP Token Resolver.
یافته‌ها: انتشار در برابر مستندسازی
بر اساس نتایج، ارائه سیستم به عنوان یک بسته قابل نصب، یک «تابع پله‌ای» (Step Function) در کیفیت ایجاد کرد. بدون بسته، عامل در ۱۲ یا ۱۳ مورد از ۱۳ جایگاهی که یک قطعه کتابخانه جایگاه طبیعی داشت، کدها را به‌صورت دستی نوشت. علاوه بر این، اپلیکیشن به‌طور بی‌صدا حدود ۹۰ ویژگی CSS سفارشی به دست آورد که حالا تیم توسعه باید آن‌ها را نگهداری کند. با نصب بسته، هر دو عدد (کدهای دستی و CSSهای سفارشی) به صفر رسید.
به‌طور شگفت‌انگیز، راهنمای متنی (حالت A') — که دقیقاً مشابه روش اکثر سازمان‌ها (فایل Figma و صفحه Confluence) است — تقریباً هیچ سود قابل اندازه‌گیری نداشت. هیچ هم‌پوشانی بین شرایط وجود نداشت؛ یعنی «نوشتن دستورالعمل» با «ارائه بسته نرم‌افزاری» کاملاً متفاوت بود.
پارادوکس دسترسی‌پذیری
یکی از تکان‌دهنده‌ترین نتایج این بود که بیشترین ارزش سیستم طراحی، نه در سازگاری بصری، بلکه در دسترسی‌پذیری (Accessibility) بود. عامل‌ها می‌توانستند رنگ‌ها را از Figma بخوانند و پالت را درست پیاده کنند، اما مکرراً در هر دو مدل مورد آزمایش، خطاهای جدی در تضاد رنگی (Contrast) ایجاد کردند. فایل طراحی مقادیر را می‌داد، اما منطقِ اینکه کدام مقدار روی کدام سطح قرار گیرد را منتقل نمی‌کرد. این نتیجه نشان می‌دهد که یک سیستم طراحی حاوی تصمیماتی است که در هیچ فایل متنی ساده‌ای برای خواندن توسط عامل وجود ندارد.
هزینه زمینه
برخلاف باور رایج که کتابخانه‌ها با جلوگیری از «اختراع دوباره چرخ»، هزینه تولید را کم می‌کنند، اتفاق عکس افتاد. استفاده از کتابخانه هزینه اجرا را افزایش داد؛ زیرا عامل مجبور بود API را بخواند و هر چیزی که خوانده شود در پنجرهٔ زمینه (Context Window) — شبیه میز کاری که فضای محدودی برای کاغذها دارد — باقی می‌ماند و در هر نوبت (Turn) دوباره هزینه می‌شود. این افزایش هزینه‌های عملیاتی با گزارش‌هایی که نشان می‌دهد عامل‌های کدنویس باعث افزایش هزینه توکن و بدهی فنی می‌شوند هم‌سو است. پژوهشگر اشاره می‌کند که هرگونه سود حاصل از این رویکرد باید در بخش‌های بازبینی (Review)، اصلاحات (Rework) و نگهداری (Maintenance) باشد؛ معیارهایی که هنوز اندازه‌گیری نشده‌اند.
شکست‌های نامرئی
این مطالعه یک ترس رایج در صنعت را رد کرد: عامل‌ها معمولاً APIهای خیالی برای قطعات نمی‌سازند (توهم نمی‌زنند). در ۳۰ اجرا، عامل هرگز قطعه‌ای را اختراع نکرد که گمان می‌کرد وجود دارد اما نبود. در عوض، او صرفاً نسخه سفارشی خودش را از آن قطعه نوشت. این شکست بسیار خطرناک‌تر است چون در اسکرین‌شات دیده نمی‌شود و در Diff کدها شبیه به یک خطا به نظر نمی‌رسد، اما هزینه مالکیت کد (Cost of Ownership) را به‌شدت بالا می‌برد.
ناامیدی از MCP
پیشرفته‌ترین لایه، یعنی ابزار MCP Token Resolver، هیچ بهبود قابل اندازه‌گیری نسبت به فایل متنی ساده (llms.client.txt) ایجاد نکرد. با وجود اینکه این بخش مهندسی‌شده‌ترین قسمت سیستم بود، عامل هنگام استفاده از یک ابزار برای حل توکن‌ها، بهتر از خواندن آن‌ها از یک سند عمل نکرد. این مقایسه از پیش به عنوان تعیین‌کننده‌ترین بخش آزمایش ثبت شده بود و عدم بهبود آن با همان اهمیتی که موفقیت‌ها گزارش شدند، منتشر شد.
گام بعدی شما
- به‌جای صرف زمان برای نوشتن مستندات طولانی‌تر برای AI، روی ارائه بسته‌های نرم‌افزاری با Typeهای سخت‌گیرانه و نسخه‌بندی‌شده تمرکز کنید.
- برای کاهش خطاهای بصری و دسترسی‌پذیری، منطقِ ترکیب رنگ‌ها را در قالب توکن‌های معنایی (Semantic Tokens) تعریف کنید، نه فقط پالت رنگی.
- در ارزیابی خروجی عامل‌ها، به‌جای تکیه بر ظاهر (Screenshot)، کدها را برای شناسایی «نسخه‌های سفارشیِ مخفی» بررسی کنید تا از افزایش هزینه نگهداری جلوگیری شود.
هدف این نیست که AI را «باهوش‌تر» کنیم، بلکه هدف این است که آن را محدود کنیم تا نتواند از قرارداد مهندسی تعیین‌شده منحرف شود. این تغییر رویکرد در واقع نشان‌دهنده این است که ارزش برنامه‌نویسان در عصر AI از نوشتن کد به سمت معماری سیستم و عیب‌یابی منتقل شده است. پژوهشگر در حال ادامه این مطالعه است تا میزان «انحراف کد» (Code Drift) و هزینه واقعی هر صفحه پذیرفته‌شده را اندازه‌گیری کند و ببیند آیا صرفه‌جویی در نگهداری بلندمدت، هزینه‌های اولیه بالاتر در تولید را جبران می‌کند یا خیر.
گفتگو