وایب کدینگ چیست و چرا اپ ساخته‌شده با هوش مصنوعی در پروداکشن خراب می‌شود؟

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

برای امتحان کردن ایده، این روش واقعاً عالی است. مشکل از روزی شروع می‌شود که کاربر واقعی، پول واقعی یا داده واقعی وارد سیستم می‌شود.

آمار امنیت کد هوش مصنوعی چه می‌گوید؟

شرکت Veracode هر چند ماه یک بار مدل‌های هوش مصنوعی را با آزمون‌های امنیتی ثابت می‌سنجد. طبق گزارش پاییز ۲۰۲۶:

• میانگین موفقیت در آزمون امنیتی از ۵۶ به ۶۲ درصد رسیده است. یعنی هنوز حدود ۴ مورد از هر ۱۰ کار، آسیب‌پذیری دارد.
• بهترین مدل‌ها به ۷۳ درصد رسیده‌اند، پس حتی آن‌ها از هر چهار کار در بیش از یکی شکست می‌خورند.
• پیشرفت اصلی در حمله XSS بوده است، ولی میانگین آن هنوز فقط ۱۸ درصد است. Log injection هم حدود ۱۲٫۶ درصد مانده.
• این آزمون وابستگی‌های بیرونی پروژه را بررسی نمی‌کند، پس ریسک واقعی می‌تواند بیشتر باشد.

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

پروژه Vibe Security Radar در دانشگاه Georgia Tech هم آسیب‌پذیری‌های ثبت‌شده را تا ابزار هوش مصنوعی سازنده‌شان دنبال می‌کند. به گزارش Cloud Security Alliance، این تعداد از ۶ مورد در ژانویه ۲۰۲۶ به ۳۵ مورد در مارس رسید. پژوهشگران هم می‌گویند عدد واقعی چند برابر این است.

سرعت نوشتن کد، سرعت تحویل نیست

Greg Law، مدیر فنی شرکت Undo، در یادداشتی در TechRadar می‌نویسد ۷۹ درصد مدیران مهندسی گفته‌اند چرخه انتشارشان سریع‌تر نشده است. این عدد از شرکتی می‌آید که ابزار دیباگ می‌فروشد، ولی نکته اصلی آن قابل‌فهم است: گلوگاه از نوشتن کد به فهمیدن و اصلاح آن منتقل شده.

وقتی کدی را خودتان ننوشته و نخوانده‌اید، روز خرابی نمی‌دانید از کجا شروع کنید.

چه چیزهایی معمولاً خراب می‌شوند؟

این‌ها جاهایی است که هر مهندس بک‌اند اول سراغشان می‌رود:

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

پیش از پروداکشن این چک‌لیست را مرور کنید

1. همه کلیدها را از کد خارج کنید و هر کلیدی را که لو رفته عوض کنید.
2. در هر مسیر API بررسی کنید کاربر فعلی حق دسترسی به همان داده را دارد یا نه.
3. روی هر کامیت اسکن امنیتی، بررسی وابستگی‌ها و جستجوی کلیدهای لو رفته را اجرا کنید.
4. وجود واقعی هر پکیجی را که مدل پیشنهاد داده بررسی کنید. مدل‌ها گاهی نام پکیج را از خودشان می‌سازند.
5. برای ورود، پرداخت و پیامک محدودیت درخواست بگذارید.
6. سناریوهای خطا را عمداً امتحان کنید: قطع شبکه، کلیک دوباره و پاسخ نیامدن سرویس بیرونی.
7. یک بار بکاپ را واقعاً بازگردانی کنید.
8. گزارش خطا و هشدار راه بیندازید.
9. برای احراز هویت، پرداخت و داده حساس، بازبینی انسانی را اجباری کنید.

پس وایب کدینگ بد است؟

نه. برای نمونه اولیه، ابزار داخلی کوچک و سنجیدن ایده، صرفه‌جویی بزرگی است. ولی نمونه اولیه محصول نیست.

هوش مصنوعی زمان رسیدن به نسخه اول را کم کرده است. مسئولیت چیزی که منتشر می‌شود، هنوز با انسان است.

مسیر منطقی این است: با هوش مصنوعی ایده را سریع بسازید، با کاربر واقعی بسنجید و قبل از ورود پول یا داده حساس، یک مهندس کد را بررسی کند. اگر محصول ارزشش را نشان داد، این هزینه خیلی کمتر از بازنویسی پس از اولین حادثه است.

اگر اپ شما همین حالا آماده است

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