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

باگی که از سال 2013 همان‌جا باقی مانده است

پژوهشگران امنیتی این هفته با جزئیات توضیح دادند که چگونه می‌توان هزاران سرور متصل به اینترنت از تولیدکنندگان بزرگ را از راه دور و از طریق کنترل‌کننده‌های مدیریت برد اصلی، یا BMCها، به‌عنوان درِ پشتی مورد سوءاستفاده قرار داد — رایانه‌های کوچک و جداگانه‌ای که تقریباً روی مادربرد هر سرور سازمانی تعبیه شده‌اند و مستقل از آنچه روی ماشین اصلی رخ می‌دهد، سیستم‌عامل، پشته شبکه و نشانی IP خود را اجرا می‌کنند (Ars Technica). BMCها به کارکنان فناوری اطلاعات اجازه می‌دهند حتی وقتی سرور خاموش است یا کاملاً پاسخ‌گو نیست، آن را از راه دور راه‌اندازی مجدد کنند، دوباره ایمیج‌گذاری کنند یا زیر نظر بگیرند — واقعاً مدیریت مفیدِ «چراغ‌ها خاموش» است. اما طبق گفته پژوهشگران، مشکل اینجاست که پروتکل زیربنایی دست‌کم از سال 2013 به‌عنوان هدفی آسان شناخته شده و برخی از آسیب‌پذیری‌هایی که اکنون از آن‌ها سوءاستفاده می‌شود، بیش از یک دهه قدمت دارند. Ars آن را «سطح حمله‌ای موازی، فراگیر، کم‌نظارت و کم‌وصله» توصیف می‌کند — نه حفره‌ای جدید، بلکه حفره‌ای قدیمی که بی‌سروصدا نادیده گرفته شده، چون پایین‌تر از جایی قرار دارد که بیشتر توجه نرم‌افزاری و امنیتی معطوف به آن است.

کدنویسی عامل‌محور به‌زودی این موارد را با سرعت بیشتری افزایش می‌دهد

در همان هفته، Meta، Muse Code را عرضه کرد؛ یک عامل کدنویسی مبتنی بر ترمینال که به Claude Code، Codex و حوزه‌ای رو‌به‌رشد از مهارکننده‌هایی می‌پیوندد که با حداقل دخالت انسان، نرم‌افزار می‌نویسند و منتشر می‌کنند (TechCrunch). توضیح خود زاکربرگ درباره آن گویاست: در کاری به‌اندازه کافی بزرگ، عامل به چندین عامل فرعی تقسیم می‌شود که به‌طور موازی و در درخت‌های کاری ایزوله، هم‌زمان چند قابلیت را می‌سازند. این واقعاً بهره‌وری را افزایش می‌دهد. اما از نظر ساختاری، به این معناست که بیش از هر زمان دیگری، به ازای هر واحد توجه انسانی، زیرساخت بیشتری برپا، پیکربندی و مستقر می‌شود — نمونه‌های ابری بیشتر، محیط‌های آزمایشی بیشتر، و سرورهای بیشتری که به‌سرعت به‌دست افرادی فراهم می‌شوند که شاید هرگز به تنظیمات BMC دست نزنند یا گزارش تغییرات سفت‌افزار را نخوانند. ابزارهای عامل‌محور در نوشتن برنامه کاربردی بسیار خوب‌اند. اما درباره اینکه تراشه مدیریت خارج از باندِ زیر آن برنامه با سفت‌افزاری شش‌ساله اجرا می‌شود یا نه، هیچ نظری ندارند.

هیچ‌کدام از این‌ها به این معنا نیست که ابزارهای کدنویسی عامل‌محور ذاتاً ناامن‌اند — این موضوعی جدا از مسئله مطرح‌شده در مقاله Ars Technica است. نکته محدودتر است: حجم زیرساختی که ایجاد می‌شود، سریع‌تر از انضباط کم‌زرق‌وبرقِ وصله‌کردن لایه فیزیکی زیر آن مقیاس می‌گیرد، و این شکاف صرفاً به این دلیل که کد روی آن هوشمندتر شده، خودبه‌خود از بین نمی‌رود.

چرا این فقط یک داستان امنیتی نیست، بلکه نشانه‌ای شغلی است

این موضوع را در کنار تعدیل نیروهایی بگذارید که همچنان در صنعت جریان دارند — کاهش حدود 20 درصدی نیروی کار Monday.com در این هفته، که صراحتاً به بازسازی مبتنی بر هوش مصنوعی نسبت داده شده، به فهرست رو‌به‌رشد شرکت‌هایی می‌پیوندد که هنگام حذف مشاغل به هوش مصنوعی استناد می‌کنند (TechCrunch). باید درباره چیزی که اینجا نمی‌دانیم صادق بود: هیچ‌یک از این گزارش‌ها تعدیل نیرو را بر اساس وظیفه تفکیک نمی‌کنند، بنابراین داده روشنی وجود ندارد که بگوید «نقش‌های امنیتی و زیرساختی در امان‌اند.» چنین ادعایی فراتر از شواهد خواهد بود. چیزی که با اطمینان بیشتری می‌توان گفت، ساختاری است نه آماری: نقش‌هایی که سریع‌تر خودکار می‌شوند، آن‌هایی هستند که محصول کارشان متن، کد یا تعاملی با مشتری است که یک LLM می‌تواند تقریب بزند. امنیت در سطح فیزیکی و سفت‌افزار — دانستن اینکه BMC چیست، IPMI و جانشین‌هایش چگونه کار می‌کنند، چگونه دسترسی مدیریت خارج از باند را ممیزی کنیم، و چگونه وصله سفت‌افزار را در سراسر یک ناوگان اعمال کنیم بدون اینکه نیمی از آن از کار بیفتد — به ماشین نزدیک‌تر است تا مدل. این حوزه آشکارا جزو کارهایی نیست که عامل‌های فعلی هوش مصنوعی به سراغشان می‌روند، و صرفاً به این دلیل که لایه نرم‌افزاری بالای آن آسان‌تر شده، خودکارسازی‌اش آسان‌تر نمی‌شود.

واقعاً با این موضوع چه باید کرد

برای اقدام بر اساس این موضوع لازم نیست مهندس سفت‌افزار شوید. چند حرکت قابل‌بررسی:

  • بپرسید، فرض نکنید. اگر در هر شرکتی که سرورهای خودش را اجرا می‌کند (نه صرفاً ابر) در حوزه فناوری اطلاعات، پلتفرم یا امنیت کار می‌کنید، بپرسید آیا سفت‌افزار BMC اصلاً در چرخه وصله قرار دارد یا نه. بسیاری از سازمان‌ها واقعاً پاسخ این سؤال را نمی‌دانند.
  • واژگان را یاد بگیرید، نه فقط تیتر را. BMC، IPMI، Redfish و مدیریت خارج از باند — این‌ها مفاهیمی قابل جست‌وجو و به‌خوبی مستندشده‌اند، و درک آن‌ها شما را از بیشتر افرادی جلو می‌اندازد که مهارت‌سازی‌شان در عصر هوش مصنوعی کاملاً معطوف به پرامپت و عامل بوده است.
  • ببینید ابزارهای کدنویسی عامل‌محور چه چیزهایی را پوشش نمی‌دهند. وقتی شما یا تیمتان برای کارهای مرتبط با زیرساخت از ابزارهایی مانند Muse Code یا Claude Code استفاده می‌کنید، صراحتاً بپرسید چه چیزهایی خارج از دامنه‌اند — اهداف استقرار، سفت‌افزار و کنترل‌های دسترسی فیزیکی — و با این شکاف مانند جایی برای ساختن تخصص برخورد کنید، نه چیزی که باید نادیده گرفته شود.
  • زیاده‌روی نکنید. این فقط یکی از چندین حوزه تخصصی محتمل است، نه پناهگاهی امن و تضمین‌شده. آن را پوششی بدانید که ارزش بررسی دارد، نه تغییر مسیر شغلی‌ای که صرفاً بر اساس یک گزارش Ars Technica انجام شود.

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