نتلیفای: یک میلیارد اپلیکیشن جدید تا سال ۲۰۲۹ با کمک هوش مصنوعی عامل‌محور

اگر امروز یک مهندس نرم‌افزار هستید، ارزش شما دیگر با تعداد خطوط کدی که می‌نویسید سنجیده نمی‌شود، بلکه با توانایی شما در طراحی سیستم‌هایی که عامل‌های هوش مصنوعی در آن ساکن هستند تعریف می‌شود. این ادعای مرکزی دانا لاسون، مدیر فنی Netlify است که هفته‌ی گذشته در کنفرانس AI Native DevCon در لندن مطرح کرد.

برای چندین دهه، شغل مهندسی یعنی ساختن حصارهایی برای اینکه انسان‌ها محیط عملیاتی (Production) را خراب نکنند. لاسون که از دهه ۹۰ میلادی در این صنعت فعال است، اشاره می‌کند که ما اکنون در حال برداشتن این حصارها هستیم تا عصر جدیدی از خلق و ابداع را تشویق کنیم. صنعت در حال ورود به دوران «تجربه عامل» (Agent Experience یا AX) است؛ جایی که قصد و نیت ما — که با زبان محاوره بیان می‌شود — به زبان برنامه‌نویسی بعدی تبدیل می‌شود. طبق پیش‌بینی لاسون، این چرخش باعث می‌شود تا سال ۲۰۲۹ یک میلیارد اپلیکیشن جدید توسط «توسعه‌دهندگان شهروند» ساخته شود؛ افرادی که ممکن است حتی ندانند git چیست.

این گذار، دورانی از عدم قطعیت شغلی بالا را ایجاد می‌کند. در حالی که اخبار تعدیل نیرو در شرکت‌های فناوری dominating است، بسیاری از مهندسان می‌پرسند در دنیایی که در آن به‌ندرت کد دستی می‌نویسند، جایگاهشان کجاست. با این حال، لاسون معتقد است کدنویسی همیشه کمتر از یک‌چهارم شغل واقعی یک مهندس بوده و معمولاً استراتژیک‌ترین بخش آن نبوده است.

تعریف تجربه عامل (AX)

به باور لاسون، مهندس مدرن اکنون «چوپان محیط عملیاتی» است. وظیفه او این است که مطمئن شود هر چه وارد سیستم می‌شود و هر چه از آن خارج می‌شود، به‌درستی درک شده است. در یک تجربه عامل موفق، عامل‌ها باید فعالیت‌هایی رویداد-محور باشند؛ جایی که سیگنال‌ها به‌جای اینکه توسط توسعه‌دهنده کشیده شوند (Pull)، به سمت او فرستاده شوند (Push).

موفقیت در عصر AX به درک جامع از سیستم‌های پیچیده، بافت کسب‌وکار و مسیر رسیدن به تولید وابسته است. لاسون استدلال می‌کند AX یعنی تمرین تفکر درباره بافت سیستم جدید و نیت کاربر در چرخه تحویل نرم‌افزار. این یعنی طراحی محیطی که در آن انسان‌ها و عامل‌ها به‌طور یکپارچه همکاری کنند، و به‌طور صریح تأکید می‌کند که AX فقط به معنای «عامل-پسند کردن» فراخوان‌های API نیست.

برای پشتیبانی از این دیدگاه، Netlify — که در سال ۲۰۱۴ به عنوان پلتفرمی برای توسعه‌دهندگان فرانت-اند وب‌سایت‌ها و اپلیکیشن‌ها شروع به کار کرد — مجبور شد پلتفرم خود را بازسازی کند. این پلتفرم اکنون باید نه‌تنها با توسعه‌دهندگان حرفه‌ای، بلکه با عامل‌های هوش مصنوعی و این سازندگان جدید غیرفنی ارتباط برقرار کند.

لاسون دریافت که بهینه‌سازی برای عامل‌ها در واقع تجربه توسعه‌دهندگان انسانی را هم بهبود می‌بخشد. چون AX ترکیبی از تجربه توسعه‌دهنده (DX) و تجربه کاربر (UX) است، حل چالش‌های هر دو به کاربران کمک کرد تا مرزهای نهادی و دانش دامنه — مانند نیاز به مدارک علوم کامپیوتر که مدت‌ها دروازه‌بان این صنعت بود — را رد کنند. با حذف پیش‌فرض‌های انسانی، شفاف‌سازی پیام‌های خطای عامل و ساختارمند کردن خروجی‌های بیلد (Build) برای ماشین‌ها، پلتفرم برای همه کارآمدتر شد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی تغییر نقش برنامه‌نویسان در عصر مدل‌های زاینده اشاره کردیم، ابزارها در حال تبدیل شدن از «ماشین‌نویس» به «مدیر پروژه» هستند.

چرخش معماری

لاسون استدلال می‌کند سیستم‌های سازمانی در ابتدا برای اپراتورهای انسانی طراحی شدند و فرض بر این بود که یک انسان بخشی از چرخه (Loop) است. عامل‌ها با این ساختار مشکل دارند چون نمی‌توانند مرزها را ببینند و هر API با گویش متفاوتی صحبت می‌کند. بسیاری از گردش‌های کاری حیاتی اغلب در «یک رشته پیام در اسلک مربوط به سال ۲۰۲۲» یا «یک ماژول مستندنشده Terraform» پنهان شده‌اند.

برای حل این مشکل، لاسون سه تکامل معماری حیاتی را برای آینده‌ی موفق عامل‌محور ترسیم می‌کند:

• از API به قابلیت‌ها: حرکت از نقاط انتهایی استاندارد (مانند POST، GET، PATCH) به سمت عملیات در سطح نیت که بیان می‌کند شما می‌خواهید چه کاری انجام دهید؛ مثلاً دستوراتی مانند create_a_site یا deploy-repository.
• از درخواست-پاسخ به رویداد-محور: تغییر از مدل «درخواست کن و منتظر بمان» به مدلی که در آن عامل‌ها مشترک رویدادها می‌شوند، رفتار سیستم را رصد می‌کنند و در صورت داشتن اجازه، به‌طور خودگردان عمل می‌کنند.
• از ماشین-خوان به عامل-خوان: حذف بخش‌های «مرموز» معماری که فقط توسط تعداد کمی از افراد درک می‌شود. در عوض، پلتفرم‌ها باید نقشه‌های پیچیدگی معماری (Architectural Complexity Blueprints) بسازند تا عامل‌ها و انسان‌ها پیش از اعمال تغییرات، سیستم را درک کنند.

این روند یک حلقه مداوم انسان-عامل می‌سازد. چرخه توسعه دیگر یک تحویل ساده به تیم‌های عملیات نیست؛ بلکه همه به‌طور هم‌زمان مشارکت می‌کنند. انسان برای ارائه قضاوت، سلیقه و جهت‌دهی در حلقه می‌ماند، در حالی که عامل با سرعت ماشین عمل می‌کند تا توانایی ساخت‌وساز را برای همه تقویت کند.

حصارها و مسئولیت‌ها

وقتی هوش مصنوعی محدودیت پهنای باند انسانی را حذف می‌کند، شغل مهندس به این تغییر می‌کند که تصمیم بگیرد چه چیزی را «نسازد». لاسون هشدار می‌دهد «حقیقت تلخ» این است که توسعه‌دهندگان احتمالاً مجبور به ساخت چیزهایی می‌شوند که در عرض چند ماه منقضی می‌شوند، نه چند سال. یافتن مسیرهای درست و قرار دادن نیت در نقاط کلیدی است که آینده شغلی را تضمین می‌کند.

چون اکنون هر کسی در دنیا می‌تواند به‌معنای واقعی کلمه هر چیزی بسازد، بار مسئولیت بر دوش مهندسان است تا مطمئن شوند این ساخته‌ها برای کسب‌وکار، مشتری، امنیت و جهان مناسب هستند. این مسئولیت شامل پیاده‌سازی فشرده‌سازی (Compaction)، تفکر درباره تراکم (Compression) و ساخت منابعی است که اینترنت را باز، دموکراتیک و سازگار با محیط‌زیست نگه دارند.

برای حفظ اعتماد در محیط عملیاتی، لاسون سه مرز سخت‌گیرانه در Netlify اجرا می‌کند:
۱. سندباکس (Sandboxing): هر عامل فقط در محیط ایزوله و مشخص خود اجرا می‌شود.
۲. انسان در حلقه (Human-in-the-Loop): این حالت پیش‌فرض است و بر بخش‌های معنادار و نیت-محور شغل تمرکز دارد.
۳. قابلیت حسابرسی (Auditability): هر اقدام عامل ثبت (Log) می‌شود تا فوراً قابل بازگشت (Rollback) باشد.

لاسون یک پرسش حیاتی می‌پرسد: «اگر نمی‌توانید توضیح دهید عامل چه کرده است، چرا باید به آن در محیط عملیاتی اعتماد کنید؟» در نتیجه، مهندسی از «پیاده‌سازی قابلیت» به «طراحی دقیق حصارهای سیستم» تکامل می‌یابد.

آینده مهندسی

عامل‌ها اکنون در تمام چرخه زیرساختی سازمان حضور دارند. آن‌ها تست می‌سازند، خطاها را شناسایی می‌کنند، بلوک‌های ساخت را تحلیل می‌کنند، پیشنهاد اصلاحیه می‌دهند و در خط لوله CI/CD درخواست‌های ادغام (PR) باز می‌کنند. اگرچه برخی سیستم‌ها هنوز به این سطح از پیچیدگی نرسیده‌اند، اما مهندسان باید از همین‌جا بازتعریف نیازهای خود را شروع کنند.

در نهایت، طراحی برای عامل‌ها در واقع طراحی برای انسان‌هاست. لاسون اشاره می‌کند که هوش مصنوعی صنعت را مجبور کرد معماری، ساختار و سیگنال‌ها را شفاف کند و این خود باعث شد همه توسعه‌دهنده‌های بهتری شوند. «مهارت مهندسی آینده»، همان قضاوتی است که برای ساخت سیستم‌هایی که عامل‌ها بتوانند به‌طور مؤثر با آن‌ها کار کنند لازم است، تا AX خلاقیت انسانی را تقویت کند، نه اینکه جایگزین آن شود.

چه یک معمار سازمانی باشید و چه یک توسعه‌دهنده مستقل، تمرکز اکنون باید به سمت استک فنی داخلی، افراد و فرآیندهایی حرکت کند که از این حلقه‌های خودگردان پشتیبانی می‌کنند.

گام بعدی شما

• اگر مدیر فنی هستید، بررسی کنید کدام بخش‌های معماری شما «مرموز» است و برای تبدیل آن‌ها به نقشه‌های عامل-خوان برنامه‌ریزی کنید.
• به‌جای تمرکز بر یادگیری سینتکس‌های جدید، روی درک عمیق «بافت کسب‌وکار» و «طراحی سیستم» تمرکز کنید.
• مدل‌های «انسان در حلقه» را برای هر فرآیند خودکارسازی در تیمتان تعریف کنید تا قابلیت حسابرسی را حفظ کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.