وقتی Design System تبدیل به Bottleneck می‌شه، AI چه چیزی رو بهتر میکنه؟

یکی از مشکلاتی که با رشد Design System به‌وجود میاد، زیاد شدن صف درخواست‌هاست. هرچه تیم‌های بیشتری از سیستم استفاده کنن، درخواست برای Component جدید، Variant تازه، تغییر Token، رفع Bug یا اضافه شدن یک Pattern هم بیشتر می‌شه.

اگر همه این درخواست‌ها مستقیم به تیم Design System برسن، خیلی زود تیم مرکزی تبدیل به Bottleneck می‌شه. تیمی که قرار بوده سرعت توسعه محصول رو بیشتر کنه، حالا خودش به نقطه‌ای تبدیل می‌شه که تیم‌های محصول برای ادامه کار باید منتظرش بمونن.

تا قبل از AI، راه‌حل‌ها بیشتر مشخص بودن: ظرفیت تیم رو افزایش بدیم، درخواست‌ها رو دستی اولویت‌بندی کنیم، Contribution Model تعریف کنیم یا بخشی از Ownership رو بین تیم‌های محصول توزیع کنیم.

این راهکارها هنوز هم مهم هستن، اما AI یک سؤال جدید وارد ماجرا کرده:

آیا واقعاً همه درخواست‌ها باید از ابتدا به یک انسان برسن؟

فرض کنید ۳۰ درخواست وارد Backlog شده

یکی درباره اضافه شدن Variant جدید به Table هست، چند تیم Bug مشابهی در DatePicker گزارش کردن، یک تیم Token جدیدی می‌خواد و چند Request هم در واقع نسخه‌های مختلف یک نیاز مشترک هستن.

در مدل سنتی، یک نفر باید این درخواست‌ها رو بخونه، Context هرکدوم رو پیدا کنه، Duplicateها رو تشخیص بده، Componentهای مرتبط رو بررسی کنه و بعد تصمیم بگیره تیم باید از کجا شروع کنه.

اما بخشی از این کار الزاماً به قضاوت یک Designer یا Engineer نیاز نداره.

اینجا Agent می‌تونه قبل از رسیدن درخواست‌ها به تیم وارد فرآیند بشه.

درخواست وارد سیستم می‌شه، Agent اون رو دسته‌بندی می‌کنه، موارد مشابه رو پیدا می‌کنه، اطلاعات مرتبط رو از Documentation و Codebase جمع می‌کنه، میزان اثرگذاری تغییر رو بررسی می‌کنه و در نهایت مشخص می‌کنه Request باید در چه مسیری قرار بگیره.

در واقع می‌تونیم یک Pipeline متفاوت برای مدیریت درخواست‌های Design System تصور کنیم:

Request → Triage → Enrichment → Prioritization → Execution → Review

نکته مهم اینه که نقش AI در تمام این مراحل یکسان نیست.

در مرحله اول، Agent صف رو مرتب می‌کنه

بخش زیادی از Requestهایی که وارد تیم Design System می‌شن، قبل از هر تصمیمی نیاز به Triage دارن.

این درخواست Bug هست یا Feature؟ آیا مشابه اون قبلاً ثبت شده؟ مربوط به کدوم Componentه؟ آیا فقط یک تیم این نیاز رو داره یا چند تیم مسئله مشابهی دارن؟

یک Agent می‌تونه این اطلاعات اولیه رو جمع‌آوری کنه و به‌جای یک Backlog خام، درخواست‌ها رو به شکل ساختاریافته در اختیار تیم قرار بده.

اما مرحله بعد مهم‌تره.

در مرحله دوم، Agent به Requestها Context اضافه می‌کنه

فرض کنیم یک تیم گزارش داده که تغییر خاصی در Input نیاز داره. برای تصمیم‌گیری درباره این درخواست، فقط خوندن متن Issue کافی نیست.

باید بدونیم چند محصول از این Component استفاده می‌کنن، چه Tokenهایی به اون متصل هستن، آیا تغییر روی Variantهای دیگه اثر می‌ذاره، آیا Issue مشابهی قبلاً وجود داشته و آیا تغییر پیشنهادی ممکنه Breaking Change ایجاد کنه.

اگر Agent به Codebase، Documentation، Component metadata، Testها و Usage data دسترسی داشته باشه، می‌تونه بخش زیادی از این Context رو قبل از Review جمع کنه.

در نتیجه، تیم به‌جای اینکه بررسی هر Request رو از صفر شروع کنه، با مسئله‌ای روبه‌رو می‌شه که بخش زیادی از اطلاعات لازم برای تصمیم‌گیری اون از قبل آماده شده.

در مرحله بعد، همه درخواست‌ها یک اولویت ندارن

فرض کنید یک درخواست مربوط به تغییر جزئی Padding در یک Use Case خاصه و درخواست دیگه مربوط به یک مشکل Accessibility در Componentیه که در چند محصول استفاده می‌شه.

صرفاً به این دلیل که درخواست اول زودتر ثبت شده، نباید الزاماً زودتر بررسی بشه.

Agent می‌تونه Signalهایی مثل تعداد Consumerها، میزان Usage، شدت مشکل، وجود Workaround، ریسک Breaking Change و اثر روی Accessibility رو کنار هم قرار بده و براساس قواعدی که تیم تعریف کرده، اولویت اولیه پیشنهاد بده.

اینجا AI قرار نیست تصمیم نهایی رو بگیره. نقش اون اینه که کمک کنه تیم بفهمه کجا ارزش داره زودتر تصمیم بگیره.

اما آیا Agent باید هر چیزی رو که فهمید، اجرا کنه؟

اینجا بخش مهم ماجرا شروع می‌شه.

اگر یک Agent بتونه یک مشکل رو تحلیل کنه، الزاماً به این معنی نیست که باید اجازه داشته باشه اون رو تغییر بده.

فرض کنید Documentation یک Component با Implementation اون هماهنگ نیست. اصلاح چنین موردی کم‌ریسک، قابل بازگشت و تا حد زیادی Rule-based هست. Agent می‌تونه تغییر رو آماده کنه، Testها رو اجرا کنه و حتی اون رو برای Review بفرسته.

اما حالا فرض کنید سه تیم درخواست Variant جدیدی برای Table دارن.

در ظاهر، این هم یک Request دیگه است. اما تصمیم درباره اون نیاز به قضاوت داره. آیا واقعاً یک Pattern مشترک شکل گرفته؟ آیا Variant جدید API کامپوننت رو پیچیده می‌کنه؟ آیا بهتره این نیاز در Product Layer باقی بمونه؟ و آیا اضافه شدن اون در بلندمدت هزینه نگهداری سیستم رو افزایش می‌ده؟

اینجا مسئله دیگه Execution نیست؛ Judgment هست.

بنابراین یکی از مهم‌ترین بخش‌های استفاده از Agent در Design System، تعریف این نیست که «AI چه کارهایی می‌تونه انجام بده؟» بلکه تعریف اینه که:

AI چه زمانی باید متوقف بشه و تصمیم رو به انسان برگردونه؟

مرز اختیار Agent باید طراحی بشه

یک مدل ساده می‌تونه این باشه که تغییرهای کم‌ریسک، قابل بازگشت و مبتنی بر Rule مشخص اجازه داشته باشن مراحل بیشتری رو به‌صورت خودکار طی کنن.

اما هرچه یک تغییر مبهم‌تر، پرریسک‌تر یا گسترده‌تر می‌شه، نیاز به Human Review هم بیشتر می‌شه.

اصلاح Documentation ممکنه تقریباً کاملاً خودکار انجام بشه. رفع یک Bug مشخص می‌تونه توسط Agent آماده و توسط انسان Review بشه. اما تغییر یک Semantic Token اصلی، اضافه کردن API جدید یا تصمیم درباره ورود یک Component به Core Design System احتمالاً باید خیلی زود به تیم Escalate بشه.

پس هدف این نیست که انسان رو از فرآیند حذف کنیم؛ هدف اینه که قضاوت انسانی رو برای جاهایی نگه داریم که واقعاً به اون نیاز داریم.

البته یک شرط مهم وجود داره

Agent فقط زمانی می‌تونه چنین نقشی داشته باشه که خود Design System اطلاعات کافی در اختیارش قرار بده.

اگر Namingها نامنظم باشن، Documentation ناقص باشه، Ownership کامپوننت‌ها مشخص نباشه، Dependencyها قابل ردیابی نباشن و قواعد Contribution فقط در ذهن اعضای تیم وجود داشته باشن، Agent هم نمی‌تونه تشخیص بده چه تغییری امنه و چه تغییری نیست.

به همین دلیل، AI یک مشکل قدیمی Design System رو حتی واضح‌تر می‌کنه:

دانشی که فقط در ذهن اعضای تیم وجود داره، قابل Scale شدن نیست.

قواعدی مثل اینکه چه چیزی Breaking Change محسوب می‌شه، چه زمانی Token جدید مجازه، کدوم Componentها Critical هستن، چه Testهایی باید اجرا بشن و چه تغییرهایی Human Review لازم دارن، باید به شکلی قابل استفاده برای سیستم تعریف بشن.

در این شرایط، Documentation و Governance دیگه فقط راهنمای Designer و Developer نیستن؛ تبدیل به بخشی از Context موردنیاز Agent هم می‌شن.

در نهایت Bottleneck حذف نمی‌شه؛ از Execution به Judgment منتقل می‌شه

فرض کنیم Agentها بتونن صدها Request رو دسته‌بندی کنن، Duplicateها رو پیدا کنن، Impact تغییرها رو تحلیل کنن و حتی برای بعضی از اون‌ها Pull Request آماده کنن.

حالا تیم Design System می‌تونه حجم بسیار بیشتری از درخواست‌ها رو مدیریت کنه.

اما هنوز سؤال‌های سخت باقی می‌مونن.

آیا این Pattern باید استاندارد بشه؟ آیا این تغییر با جهت کلی سیستم سازگاره؟ آیا ارزش انعطافی که ایجاد می‌کنه بیشتر از Complexity اضافه‌شده است؟ آیا این Component اصلاً باید وارد Core بشه؟

سرعت AI می‌تونه Execution رو افزایش بده، اما همین سرعت باعث می‌شه کیفیت تصمیم‌گیری اهمیت بیشتری پیدا کنه.

شاید به همین دلیل نقش تیم Design System هم کم‌کم تغییر کنه. ارزش این تیم کمتر در مدیریت Queue، پیدا کردن Duplicateها و انجام تغییرهای کوچک خواهد بود و بیشتر در تعریف Ruleها، طراحی مرز اختیار Agentها و گرفتن تصمیم‌هایی خواهد بود که نمی‌شه اون‌ها رو صرفاً از روی Codebase استخراج کرد.

جمع‌بندی

در Design Systemهای بزرگ، مشکل فقط زیاد بودن Requestها نیست؛ مشکل اینه که امروز تقریباً همه اون‌ها برای دریافت Context، بررسی و تصمیم‌گیری وارد یک مسیر انسانی می‌شن.

AI می‌تونه بخشی از این مسیر رو تغییر بده. درخواست‌ها می‌تونن قبل از رسیدن به تیم مرکزی دسته‌بندی بشن، Context بگیرن، اولویت‌بندی بشن و در موارد کم‌ریسک حتی برای اجرا آماده بشن.

اما مهم‌ترین مسئله در چنین سیستمی، Automation بیشتر نیست.

مسئله اصلی، طراحی مرز بین تصمیم Agent و تصمیم انسانه.

شاید Design System آینده سیستمی نباشه که AI همه‌چیز رو در اون انجام می‌ده؛ بلکه سیستمی باشه که دقیقاً می‌دونه چه چیزی رو می‌تونه به AI بسپره و چه چیزی هنوز ارزش قضاوت انسانی رو داره.