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

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

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

برای درک عمق این خطر، کافی است به تاریخچهٔ خطاهای انسانی در ابزارهای ساده‌تر نگاه کنیم تا ببینیم حذف لایه‌های بازبینی چه هزینه‌هایی دارد. طبق گزارش‌های رسمی، در سال ۲۰۱۲ بانک जेपी مورگان چیس (JPMorgan Chase) به دلیل یک خطای ساده در یک صفحه گسترده (Spreadsheet)، ۶.۲ میلیارد دلار در معاملات «نهنگ لندن» از دست داد. بازرسان دریافتند که یک فرمول به‌جای میانگین، مجموع دو عدد را تقسیم کرده بود. چون هیچ‌کس خروجی ابزار را بازبینی نکرد، بانک به اشتباه تصور کرد ریسکش بسیار پایین‌تر از مقدار واقعی است.

به همین ترتیب، در سال ۲۰۱۰، کارمن راینهارت و کنت روگوف مقاله‌ای منتشر کردند که ادعا می‌کرد رشد اقتصادی در صورت رسیدن بدهی‌های عمومی به ۹۰٪ GDP کند می‌شود. این داده‌ها سال‌ها سیاست‌های کاهش هزینه‌های دولت‌ها در سراسر جهان را هدایت کرد. اما در سال ۲۰۱۳، یک دانشجای تحصیلات تکمیلی متوجه شد که این مقاله به‌طور بی‌صدا، پنج کشور را از میانگین خود حذف کرده بود. این خطا سه سال بدون بازبینی باقی ماند؛ چون خروجی، «تمام‌شده» به نظر می‌رسید و این «به نظر تمام‌شدن»، به اشتباه با «درست بودن» یکی پنداشته شد.

هوش مصنوعی زاینده (Generative AI) — شبیه دستیاری است که با سرعت برق هر چه بخواهید می‌نویسد، اما گاهی بدون اینکه متوجه شود، در دل متن بمبی ساعتی می‌گذارد — اکنون این ریسک‌ها را به سطح جدیدی برده است. برخلاف یک صفحه گسترده، ابزارهای کدنویسی AI می‌توانند کد بنویسند، بازبینی کنند، تست کنند و مستقیماً منتشر کنند. این یعنی کل مکانیسم شناسایی خطاهایی شبیه «نهنگ لندن» از چرخه حذف می‌شود.

به نقل از تحلیلگران این حوزه، سه تله اصلی در این مسیر وجود دارد:

• نقاط کور ساختاری: سازندگان معمولاً چنان غرق در ایده‌های خود هستند که حفره‌های منطقی کار را نمی‌بینند و نمی‌توانند فاصله لازم برای تحلیل انتقادی داشته باشند.
• اتکای کاذب: AI ممکن است آیکونی بسازد که با یک کلیک کل صفحه را ببندد یا تماس تصویری را بدون دلیل در میانه جمله قطع کند، در حالی که ظاهر کد و خروجی اولیه بی‌نقص است و هیچ دلیل দৃশ্য‌پذیری برای شکست ندارد. این چالش در تقابل ابزارهای مختلف دیده می‌شود؛ جایی که برخی مدل‌ها بر اجرای دقیق داده‌ها و برخی دیگر بر تجربه کاربری تمرکز می‌کنند و هر کدام نقاط کور خاص خود را دارند.
• تله موافقت: مدل‌های AI اغلب بیش از حد «هم‌صدا» و موافق هستند و نمی‌توانند نقش یک مهندس سخت‌گیر و مستقل را ایفا کنند که با هر خط کد مخالفت کند تا حقیقت 드러 شود.

ریموند پانکو، پژوهشگر دانشگاه هاوایی، اشاره می‌کند که برنامه‌های صفحه گسترده (Spreadsheet) ذاتاً خطا‌زا نیستند، بلکه انسان‌ها هستند که خطا می‌کنند. خطر اصلی، خودِ ابزار نیست، بلکه نبودِ کسی است که خروجی ابزار را به چالش بکشد و بازبینی کند.

برای مقابله با این وضعیت، چارچوب‌های جدیدی مانند agentsmyth در حال ظهور هستند. این سیستم به‌جای تمرکز صرف بر سرعت در نوشتن کد، یک «قرارداد» شامل هفت گیت (دروازه) مشخص را اجرا می‌کند:
۱. تفکر (Think)
۲. برنامه‌ریزی (Plan)
۳. ساخت (Build)
۴. بازبینی (Review)
۵. آزمایش (Test)
۶. انتشار (Ship)
۷. بازتاب/بازبینی نهایی (Reflect)

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

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

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

گام بعدی شما

• اگر از ابزارهای کدنویسی AI استفاده می‌کنید، هرگز کد را بدون اجرای تست‌های واحد (Unit Test) منتشر نکنید.
• سعی کنید یک «بازبین انسانی» یا حتی یک مدل زبانی مجزا با پرامپتی سخت‌گیرانه برای شکار باگ‌ها تعریف کنید.
• برای پروژه‌های حساس، از متدولوژی‌های گام‌به‌گام (مانند زنجیره تفکر) استفاده کنید تا مسیر تصمیم‌گیری مدل شفاف شود.

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