طراحی سیستمهایی که خودشان را میسازند
بیشتر توسعهدهندگان نرمافزار، تکلیدها و مهندسان DevOps کارشان را بهعنوان سازنده شروع میکنند.
آنها سیستم، اپلیکیشن، کامپوننت، تم، الگو، ماژول و پایپلاین میسازند. چیدمانها را بهینه میکنند، موارد مرزی را رفع میکنند، سازگاری را حفظ میکنند و سیستمها را کامیت به کامیت جلو میبرند. کاری دقیق، عملی و عمیقاً فنی.
اما در جایی، چیزی تغییر میکند.
بهترینها ساختن را کنار نمیگذارند، اما شروع میکنند به سیستمی فکر کردن.
از سازنده تا متفکر سیستمی
تغییر نگاه: از خروجی به قواعد
سازنده بر خروجی تمرکز دارد: کامپوننتها، قالبها، صفحهها، قابلیتها، کتابخانهها و اپلیکیشنها.
متفکر سیستمی به قواعد توجه میکند: محدودیتها، تعاملها و حلقههای بازخورد.
بهجای اینکه بپرسد «این کامپوننت چه شکلی است؟»، متفکران سیستمی سؤالهای دیگری میپرسند: چه قواعدی بر این کامپوننت حاکم است؟ چه چیزی اجازه دارد با آن تعامل کند؟ در برابر تغییر چگونه رفتار میکند؟ قصد و نیت اولیه چطور در گذر زمان زنده میماند؟
این تغییر نگاه، بهطور طبیعی ما را به سمت سیستمهای عاملی (agentic) میبرد.
وقتی طراحی دیگر ایستا نیست
سیستمهای طراحی امروزی از همین حالا منطق را در خود دارند: توکنها محدودیتها را تعیین میکنند، کامپوننتها ساختار را و الگوها رفتار را.
با این حال، بیشتر سیستمها هنوز به هماهنگی سنگین انسانی وابستهاند.
عاملهای هوش مصنوعی مدلی متفاوت معرفی میکنند؛ مدلی که در آن سیستمها میتوانند قواعد خودشان را اجرا کنند، تصمیمها را پیوسته اعتبارسنجی کنند، به بافت و شرایط واکنش نشان دهند و درون خودشان هماهنگ شوند.
اینجاست که طراحی از مستندات فراتر میرود و به منطقی اجرایی تبدیل میشود.
مسیر پیش رو
تمرکز اکنون بر پیادهسازی این ایدهها در سیستمهای واقعی و کارکردی است؛ نه بهعنوان آزمایش، بلکه بهعنوان پایه و بنیان.
۱. یکپارچگی عمیقتر عاملهای هوش مصنوعی با ابزارهای طراحی (Figma)
به سوی سیستمهای طراحی عاملی
ابزارهای طراحی نباید بومهایی منفعل باشند.
هدف این است که عاملهای هوش مصنوعی را با Figma یکپارچه کنیم؛ عاملهایی که توکنهای طراحی و محدودیتهای کامپوننت را بفهمند، تصمیمها را بهصورت لحظهای اعتبارسنجی کنند، قصد طراحی را به قواعد در سطح سیستم ترجمه کنند و نقش همکار را داشته باشند، نه صرفاً خروجیگیر.
این یعنی طراحی به بالادست میرود، جایی که قصد و نیت حفظ میشود و بعدها حدس زده نمیشود.

۲. مدیریت مقیاسپذیر عاملهای هوش مصنوعی
هدف: ۱۵۰ عامل، یکی برای هر کامپوننت
بهجای یک هوش مصنوعی همهمنظوره، تیمها به سمت عاملهای متخصصِ بسیار حرکت میکنند.
هر کامپوننت عامل خودش را دارد، با مسئولیتهای تعریفشده، مرزهای روشن و آگاهی از کامپوننتهای مرتبط.
این دقیقاً بازتاب شیوهی مقیاسپذیر شدن سیستمهای سالم است: از راه تخصص، هماهنگی و قراردادهای روشن.
۳. عاملهایی با مهارت، ابزار و افزونههای واقعی
عاملها باید بتوانند عمل کنند.
یعنی باید آنها را به مهارتها (استدلال دربارهی دسترسپذیری، اعتبارسنجی طراحی، آگاهی از عملکرد)، ابزارها (لینترها، اجراکنندههای تست، APIهای طراحی) و افزونهها (Storybook، Drupal، پایپلاینهای CI، یکپارچگی با Figma) مجهز کرد.
عاملِ بیابزار فقط نظری است. عاملِ مجهز به ابزار، بخشی از خودِ سیستم میشود.
۴. تست پذیرش کارکردیِ خودکار و هوشمندتر
مبتنی بر هوش مصنوعی و آگاه از قصد
تست سنتی خروجی را بررسی میکند. تست عاملمحور رفتار را میفهمد.
تمرکز بر عاملهای هوش مصنوعی است که دربارهی مسیرهای کاربر استدلال میکنند، تستهای کارکردی که بهجای صرفاً سلکتورها، قصد را درک میکنند، سیستمهایی که تستها را همراه با کامپوننتها تکامل میدهند، و کاهش تستهای شکننده در کنار افزایش اطمینان معنایی.
تست به لایهی دیگری از هوشمندی سیستم تبدیل میشود.
TDD و BDD در عصر هوش مصنوعی: چرا عاملهای هوش مصنوعی ۱۰۰٪ توسعهی تستمحورتر میطلبند
چرا این مهم است
تیمها در حال ساختن سیستمهاییاند که از سازندگانشان بیشتر عمر میکنند، پیوسته خود را تطبیق میدهند و تصمیمهای طراحیِ بلندمدت را به آینده منتقل میکنند.
در چنین دنیایی، کنترل دستی مقیاسپذیر نیست. اما قواعد خوب تعریفشده هستند.
طراحان، توسعهدهندگان و عاملهای هوش مصنوعی باید درون یک چارچوب منطقی واحد کار کنند؛ یک سیستم مشترک از محدودیتها و قصد و نیت.

گذار از سازنده به متفکر سیستمی به معنای کنار گذاشتن پیادهسازی نیست. موضوع این است که سیستمها را چیزی فراتر از مجموعهای از قطعات ببینیم.
گام بعدی، طراحی قواعدی است که به سیستمها اجازه میدهد استدلال کنند، خود را تطبیق دهند و تکامل پیدا کنند.
توسعهدهندگان نرمافزار، تکلیدها و مهندسان DevOps که این گذار را انجام میدهند فقط نمیسازند؛ آنها شرایطی را میسازند که سیستمها خودشان را بسازند.