عامل‌های کدنویس و ظهور توسعه‌دهندگان غیرفنی؛ شکافی جدید در امنیت سازمانی

تصور کنید یک کارمند بخش فروش، ابزاری برای مدیریت سرنخ‌ها (Lead Management) می‌سازد که قرار بود شش ماه در صف انتظار تیم مهندسی بماند. او این کار را تنها در یک بعدازظهر و با استفاده از Claude Code انجام داد و عملاً تمام فرآیندهای طولانی بک‌لاگ مهندسی را دور زد. این دیگر یک سناریوی تخیلی یا یک مثال ساده نیست، بلکه واقعیت جدید «توسعه‌دهنده شهروند» (Citizen Developer) در عصر هوش مصنوعی زاینده است. یک نماینده فروش (SDR) که پیش‌تر درخواست ابزاری برای مدیریت سرنخ‌ها داده بود، شاهد بود که درخواستش در جلسات بررسی اولویت‌ها (Backlog Grooming) می‌میرد. از آنجایی که هیچ‌یک از مهندسان شرکت برای او کار نمی‌کردند، تیکت او هرگز نمی‌توانست در نبرد اولویت‌بندی، بر موارد موجود در نقشه‌راه (Roadmap) پیروز شود. بنابراین، او تصمیم گرفت خودش نسخه‌ای «ناقص و شلخته» از آن را بسازد.

دهه‌هاست که کارکنان غیرفنی به‌طور مخفیانه «IT سایه» (Shadow IT) ایجاد می‌کنند. این روند از دهه ۹۰ میلادی شروع شد؛ زمانی که نرم‌افزارهای حسابداری از طریق تماس‌های تلفنی فروش خریداری می‌شد و روی سرورهای غیرمجاز Dell که به پورت‌های اترنت وصل شده بودند، نصب می‌شد. در اوایل دهه ۲۰۰۰، سایت‌های بازاریابی با Dreamweaver ساخته می‌شدند و تیم IT مجبور بود راهی پیدا کند تا آن‌ها را روی IIS 5 بالا بیاورد. تفاوت امروز در مقیاس و سرعت است. امروز، ما با کارمند فروشی روبروییم که Claude Code را دانلود می‌کند و اپلیکیشنی را بالا می‌آورد که اطلاعات حساس شخصی (PII) را ذخیره می‌کند. تکانه و انگیزه همان است، اما ابزارها تغییر کرده‌اند. برای مدیران امنیت (CISO) و متخصصان IT، این یک حادثه امنیتی است که اغلب منجر به یک توبیخ ساده برای کارمند می‌شود؛ کارمندی که صرفاً از استقلال خود برای پیشبرد کسب‌وکار استفاده کرده است. این چالش‌ها با آمارهای اخیر همخوانی دارد، چرا که گزارش IBM نشان می‌دهد ۴۳٪ از حوادث امنیتی شرکت‌ها با ابزارهای غیرمجاز AI رخ داده است و عملاً IT سایه را به ابعادی جدید رسانده است.

طبق یک مطالعه در سال ۲۰۲۱ توسط Gartner، حدود ۴۱٪ از کارکنان حتی پیش از عرضه ChatGPT، در حال ایجاد قابلیت‌های فناوری یا تحلیلی خارج از نظارت تیم IT بودند. یعنی از هر پنج نفر، دو نفر زمانی این کار را می‌کردند که هنوز کدنویسی سخت بود. اکنون، این کار به‌شدت آسان شده است. نیمی از شرکت شما در حال حاضر در حال دور زدن شما هستند؛ آن‌ها فقط این موضوع را به شما نمی‌گویند.

اکنون سد ورود کاملاً از بین رفته است. مدیر عملیات یک شرکت بیمه منطقه‌ای را در نظر بگیرید که در تمام تاریخ خود هرگز تیمی برای توسعه نرم‌افزار استخدام نکرده است. ۲۰ سال دانش سازمانی در فایل‌های اکسل او ذخیره شده است و برای نخستین بار، راهی وجود دارد تا این دانش را بدون استخدام هیچ‌کس، به چیزی فراتر تبدیل کند. او در این مسیر هیچ سیاست IT شرکتی را نقض نمی‌کند، زیرا اصلاً چنین سیاستی وجود ندارد؛ هیچ‌کس هرگز تصور نمی‌کرد که او به چنین ابزاری نیاز داشته باشد.

تعریف توسعه‌دهنده شهروند

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

• توسعه‌دهنده فرانت‌اند که ناچار می‌شود در بخش بک‌اند کد بزند، یک شهروند است.
• توسعه‌دهنده بک‌اند که شروع به کلنجار رفتن با Terraform می‌کند، یک شهروند است.
• یک متخصص Node.js زمانی که مجبور می‌شود در محیط Elixir کار کند، به یک شهروند تبدیل می‌شود.

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

چه هر خط کد را با دست بنویسید، چه از Language Server و Autocomplete استفاده کنید، و چه اجازه دهید Claude کل کد را بنویسد در حالی که شما فقط رفتار برنامه را مشخص می‌کنید و باگ‌ها را می‌گیرید، ماهیت شغل یکسان باقی می‌ماند. از دیدگاه DevOps یا پلتفرم، توسعه‌دهنده شهروند و توسعه‌دهنده حرفه‌ای یکسان به نظر می‌رسند. هر دو در حال ایجاد تغییراتی در یک سیستم عملیاتی (Production) هستند که باید پایدار بماند. هدف مشترک هر دو این است: نگاه به یک نیاز تجاری، تصمیم‌گیری برای اینکه این نیاز باید خودکار شود و از طریق یک رابط کاربری قابل تعامل باشد، و سپس تبدیل آن به واقعیت. تفاوت تنها در این است که یکی تمرین بیشتری نسبت به دیگری دارد؛ بین متخصص و شهروند یک طیف (Gradient) وجود دارد. ما این مرز را فقط به این دلیل رسم کردیم که حقوق متخصصان بیشتر بود.

ظهور «کدنویسی حسی» و بحران کدهای بی‌کیفیت

دموکراتیزه شدن خلق نرم‌افزار بهای سنگینی در امنیت دارد. صنعت اکنون با موجی از «کدهای بی‌کیفیت» (Slop) روبروست؛ کدهایی که از نظر عملکردی کار می‌کنند اما شکننده هستند و فاقد نظارت حرفه‌ای‌اند. این پدیده را می‌توان Vibe Coding (کدنویسی حسی) نامید؛ جایی که برنامه‌نویس به‌جای تکیه بر منطق سخت و معماری، بر اساس «حس» و خروجی‌های ظاهری مدل پیش می‌رود.

هزینه کدهای بی‌کیفیت (Slop):

• در ماه اکتبر، پژوهشگران ۵۶۰۰ اپلیکیشن «حسی» را در محیط عملیاتی اسکن کردند و بیش از ۲۰۰۰ آسیب‌پذیری یافتند.
• این اسکن‌ها ۴۰۰ مورد نشت کلیدهای امنیتی (Secrets) و ۱۷۵ مورد افشای داده‌های شخصی، از جمله شماره حساب‌های بانکی و سوابق پزشکی را نشان داد.
• مورد Moltbook یک هشدار جدی است؛ این سرویس تنها سه روز پس از عرضه، ۱.۵ میلیون توکن API را لو داد، زیرا یک کلید Supabase در کدهای جاوااسکریپت سمت کاربر (Client-side) باقی مانده بود.

کدهای بی‌کیفیت روی هم انباشته می‌شوند. هر کسی که تجربه نگه داشتن پیجر (Pager) برای پاسخ به حوادث فنی را داشته باشد، می‌داند که یک تصمیم چهار ثانیه‌ای در امروز، همان دلیلی است که دو سال بعد شما را در یک تماس اضطراری برای رفع حادثه (Incident Call) قرار می‌دهد. و این تماس‌های اضطراری از همین حالا شروع شده‌اند.

محاسبات مدیرعامل

از منظر تجاری، این موازنه ساده است. هیچ‌کس کسب‌وکاری را شروع نمی‌کند با این فکر که بخواهد ۴۰ نفر را استخدام کند که دوست دارند بر سر فرمت کد بحث کنند، هزینه‌های عملیاتی (OpEx) را با مصرف ابری بالا ببرند و برای گرفتن تیشرت‌های رایگان به لاس‌وگاس بروند. آن‌ها کسب‌وکار را برای حل یک مسئله شروع می‌کنند. نرم‌افزار و توسعه‌دهندگان صرفاً ابزاری برای رسیدن به آن هدف هستند.

به لایه‌های سنتی شرکت‌ها نگاه کنید: کسب‌وکار مشکلی دارد، مشکل در انتظار مدیر محصول (PM) می‌ماند، مدیر محصول در انتظار مهندسان می‌ماند و مهندسان در انتظار تیم عملیات (Ops). هر لایه کم‌بهره است و عقب می‌ماند. سه سال پیش، فردی که در رأس هرم بود، فقط منتظر می‌ماند. امروز او Claude را باز می‌کند و فکر می‌کند: «نمی‌تواند اینقدر سخت باشد». و برای او، واقعاً سخت نیست.

یک مدیرعامل با یک انتخاب روبروست: شش ماه انتظار برای یک تیم مهندسی حرفه‌ای تا یک نقشه‌راه سخت‌گیرانه را دنبال کنند، یا اجازه دهد یک کارمند همین امروز نسخه‌ای «شلخته» را عرضه کند که مشکل فوری را حل می‌کند. این تصمیم حدود چهار ثانیه زمان می‌برد. کسب‌وکار با کد بی‌کیفیت کنار می‌آید چون «شلخته بودن» قابل اصلاح است. کسب‌وکار هرگز اهمیت نداده است که ارزش (Value) چگونه ایجاد می‌شود؛ توسعه‌دهندگان حرفه‌ای صرفاً انحصار خود بر ابزارهای تولید را با «احترام» اشتباه گرفتند. هدف نهایی متعلق به کسب‌وکار است و ابزارهای تولید اکنون متعلق به همه است.

نقش جدید DevOps

این تغییر مشابه تنشی است که باعث پیدایش DevOps شد. سال‌ها پیش، توسعه‌دهندگان می‌خواستند سریع‌تر از توان تیم عملیات کد منتشر کنند، که منجر به چرخه تیکت‌ها، شوراهای نظارت بر تغییرات (CAB) و دیوارهای ارتباطی شد. این مدل جواب نداد؛ توسعه‌دهندگان صرفاً راهی برای دور زدن عملیات پیدا کردند، درست همان‌طور که اکنون «شهروندان» در حال دور زدن همه هستند.

DevOps در واقع اعترافی بود به این حقیقت که پاسخ به یک کلاس سریع‌تر از سازندگان، ساختن «جاده‌های هموار» (Paved Roads) است، نه بزرگ‌تر کردن دروازه‌های نظارتی. هدف این است که مسیر سریع و مسیر امن، یک مسیر واحد باشند. امروز نوع جدیدی از سازندگان با سرعتی بیشتر از توسعه‌دهندگان قدیمی وارد سازمان‌ها می‌شوند و بدون اینکه تیم Ops بداند، کد را مستقیماً برای کاربران می‌فرستند، بدون اینکه هرگز سروری را که Ops می‌شناسد لمس کنند.

برای مدیریت این وضعیت، Microsoft در حال هموار کردن مسیر است. آن‌ها فایل‌های مهارت (Skill Files) متن‌باز را عرضه می‌کنند تا Claude Code و Copilot را به عامل‌های آگاه از Fabric تبدیل کنند. این کار به یک تحلیلگر اجازه می‌دهد با زبان ساده انگلیسی، داده‌های سازمانی را استخراج و کوئری کند. بزرگ‌ترین شرکت نرم‌افزاری جهان، سازندگان بیشتر می‌خواهد، نه کمتر.

شکاف حاکمیتی

برای سی سال، شرکت‌ها به‌دلیل «کمیاب بودن» مهارت کدنویسی در امان بودند؛ زیرا تنها تعداد کمی از افراد می‌توانستند نرم‌افزار خلق کنند و بنابراین محدوده اثر (Blast Radius) به اندازه‌ای کوچک بود که بتوان آن را به‌صورت دستی مدیریت کرد. اکنون این کمیابی از بین رفته است. حالا تنها کنترل باقی‌مانده، «حفاظ‌ها» (Guardrails) هستند. DevOps اکنون به مهم‌ترین شغل در ساختمان تبدیل شده است، هرچند اکثر تیم‌های عملیات هنوز این را نمی‌دانند.

با این حال، چارچوب‌های فعلی عقب هستند. CSA اشاره می‌کند که هیچ‌یک از چارچوب‌های امنیتی بزرگ AI — از جمله NIST AI RMF، OWASP LLM Top 10 یا حتی چارچوب‌های خود CSA — راهنمای اختصاصی برای توسعه‌دهندگان شهروندی که بدون نظارت امنیتی حرفه‌ای کد عرضه می‌کنند، ارائه نداده‌اند. افرادی که استانداردها را می‌نویسند، هنوز به سرعت افرادی که نرم‌افزار می‌نویسند نرسیده‌اند. شما نمی‌توانید جلوی شهروندان را بگیرید و مدیرعامل شما هم این را نمی‌خواهد. وظیفه شما این است که متولی موارد غیرقابل مذاکره باشید: امنیت، هزینه و انطباق (Compliance)، در حالی که شرکت با سرعت نور در اطراف شما در حال ساخت‌وساز است.

مدیریت سازنده نامرئی

حاکمیت سنتی شکست می‌خورد چون توسعه‌دهنده شهروند اصلاً نمی‌داند تیم DevOps وجود دارد. او مستندات نمی‌خواند، از پورتال‌ها استفاده نمی‌کند و تیکت نمی‌زند؛ او با یک عامل (Agent) صحبت می‌کند. مدل قدیمی «سلف‌سرویس توسعه‌دهنده» مستلزم آن بود که کاربر پورتال را پیدا کند و از ماژول درست استفاده کند. این درخواست برای یک کارمند فروش که سعی دارد مشکلش را قبل از ناهار حل کند، بیش از حد زیاد است.

برای بازپس‌گیری کنترل، سازمان‌ها باید حاکمیت را به درون خودِ عامل ببرند:

• محدودیت‌های سطح عامل (Agent-Level Constraints): اگر شرکت عامل‌های کدنویسی ارائه می‌دهد، باید روش‌های خاص سازمان برای استقرار نرم‌افزار را در این عامل‌ها بگنجاند. این لزوماً نباید یک ابتکار پلتفرمی عظیم باشد.
• مسیرهای استاندارد (Standardized Paths): یک مسیر خسته‌کننده اما قابل پشتیبانی تعریف کنید: یک مکان واحد برای اجرای اپلیکیشن‌ها، یک روش واحد برای استقرار و یک راه واحد برای مدیریت هویت و کلیدهای امنیتی.
• مداخلات انسانی (Human Interventions): عامل را طوری برنامه‌ریزی کنید که دقیقاً بداند کجا باید متوقف شود و برای ادامه، تایید یک انسان را بخواهد.
• یکپارچگی پلتفرم (Platform Integration): پلتفرم‌های موجود را در دسترس عامل‌ها قرار دهید، به‌جای اینکه انتظار داشته باشید کلاس جدیدی از سازندگان، نقشه‌راه مهندسی پلتفرم را یاد بگیرند.

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

نقطه بازگشت‌ناپذیر

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

در سال ۲۰۰۹، جان آل‌سپاو و پل هاموند در کنفرانس Velocity اعلام کردند که Flickr بیش از ۱۰ بار در روز استقرار کد (Deploy) دارد. بسیاری این را بی‌پروا دانستند. پاسخ صنعت این بود که استقرار را از طریق کوچک کردن محدوده اثر (Blast Radius)، بازگشت سریع (Fast Rollbacks) و ابزارهای مشترک، امن کند. ۱۷ سال بعد، این فرکانس بازگشته است — اما این بار ۱۰ استقرار در روز توسط تیم‌های فروش، ادعاها و تحلیلگران رخ می‌دهد. تیم Ops تنها تیمی در سازمان است که می‌تواند این عدد را به اتفاقی «عادی و خسته‌کننده» تبدیل کند.

گام بعدی شما

• اگر مدیر فنی هستید، به‌جای ممنوع کردن ابزارهای AI، یک «مسیر امن» (Paved Road) برای استقرار سریع اپلیکیشن‌های کوچک تعریف کنید.
• بررسی کنید کدام بخش‌های سازمان شما در حال استفاده از Claude Code یا GitHub Copilot برای ساخت ابزارهای داخلی هستند.
• استراتژی حاکمیت خود را از «تیکت‌محور» به «عامل‌محور» تغییر دهید و محدودیت‌های امنیتی را در پرامپت‌های سیستمی عامل‌ها بگنجانید.

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