تصور کنید صاحب کسبوکاری هستید که اخیراً محصولی زنده و کاربردی را تنها با کمک مدل Claude روانه بازار کرده است. او این کار را بدون دانستن زبان برنامهنویسی بک-اند، نوع پایگاه داده یا حتی نحوه عملکرد مکانیسمهای احراز هویت (Authentication) انجام داده است. او کاملاً بر روشی تکیه کرده است که اندرو کارپاتی آن را Vibe Coding (برنامهنویسی بر اساس حس) نامیده است؛ اصطلاحی برای توصیف ساخت نرمافزار از طریق پرامپتهای هوش مصنوعی، بدون خواندن یا درک کدهای تولیدشده.
این رویکرد توهمی خطرناک از پیشرفت ایجاد میکند: نرمافزار در مسیرهای ساده و ایدهآل (Happy Path) بهسادگی کار میکند، اما سازنده تا لحظه انفجار سیستم، نسبت به فضای داخلی موتور کاملاً نابیناست. در این مورد خاص، برنامه صرفاً یک پروتوتایپ یا دمو نبود، بلکه یک محصول واقعی با کاربران واقعی و دادههای واقعی بود؛ یعنی یک کسبوکار روی سیستمی اداره میشد که مالک آن نمیتوانست نحوه کارکردش را برای هیچ انسان دیگری توصیف کند.
این روند دقیقاً زمانی رخ میدهد که هوش مصنوعی خلق نرمافزار را برای مؤسسان غیرفنی دموکراتیزه میکند. همانطور که در تحلیلهای پیشین ما دربارهی این موضوع که چگونه کتابخانههای پرامپت ماژولار میتوانند وظایف پیچیدهای مانند سئو (SEO) و برنامهریزی سفرها را خودکار کنند اشاره کردیم، اکنون سد ورود برای عرضه محصولات دیجیتال کاملاً شکسته شده است. این تسهیلات در دسترسترین حالت خود را در ابزارهای جدیدی برای ساخت اپلیکیشنهای کامل با زبان طبیعی یافتهاند که فاصله میان ایده و اجرا را به حداقل رساندهاند. بسیاری از کاربران حالا با هوش مصنوعی مانند یک معمار رفتار میکنند، نه یک پیمانکار؛ و به همین دلیل، سالها تجربه مهندسی بنیادین که باعث ایجاد تشخیص الگوهای ضروری میشود را نادیده میگیرند.
توهم کد «سالم»
به نقل از گزارشی در ۲۶ ژوئن ۲۰۲۶ در وبسایت dev.to، خطر اصلی این نیست که مدلهایی مثل GPT-5 کدهای بد مینویسند. در واقع، این مدلها اغلب کدهایی تمیز، استاندارد و اصطلاحاً Idiomatic برای مسائل تعریفشده تولید میکنند. ریسک واقعی، نبودِ کاملِ درک در تمام لایههای سیستم است. جذابترین بخش Vibe Coding این است که نرمافزار سریعاً «کار میکند»؛ شما میتوانید در محیط برنامه کلیک کنید و ببینید که دقیقاً همان اتفاقی میافتد که توصیف کرده بودید.
با این حال، شکاف عمیقی میان «کار کردن در دمو» و «آماده بودن برای محیط تولید» (Production-ready) وجود دارد. این شکاف تنها در شرایط استرسزای دنیای واقعی، تحت یک حمله هدفمند یا در هنگام بار ترافیکی شدید (Heavy Load) نمایان میشود. وقتی سیستمی که بر اساس «حس» ساخته شده به دیوار محیط تولید برخورد میکند، فقدان تخصص در چهار نقطه بحرانی و مشخص خودش را نشان میدهد:
- آسیبپذیریهای امنیتی: مدلهای هوش مصنوعی ذاتاً خوشبین هستند. آنها برای مسیر موفقیت کد میزنند و اغلب ورودیهای خصمانه (Adversarial Inputs)، پیشفرضهای ناامن یا کنترلهای دسترسی شکسته را نادیده میگیرند. این موضوع میتواند منجر به آسیبپذیریهای IDOR شود، زیرا هوش مصنوعی هرگز به این فکر نمیکند که پرسوجوها (Queries) را بر اساس کاربر احرازهویتشده محدود کند.
- گلوگاههای مقیاسپذیری: سیستم ممکن است تحت فشار کرش کند یا با خطای Time-out مواجه شود، زیرا هوش مصنوعی فراموش کرده است ایندکسهای لازم را روی ستونهایی که در پایگاه داده مورد پرسوجو هستند، قرار دهد.
- بدهی نگهداری: غیربرنامهنویسان نمیتوانند ارزیابی کنند که آیا پروژه در حال فراخوانی وابستگیهای تکراری (Redundant Dependencies) است یا از بستهها و کتابخانههایی استفاده میکند که دیگر توسط توسعهدهندگان پشتیبانی نمیشوند.
- نابینایی سیستمی: وقتی برنامه در نهایت خراب شود — که قطعاً چنین اتفاقی میافتد — برنامهنویسِ حسی هیچ ایدهای ندارد که برای یافتن خطا کجا را نگاه کند، چون اصلاً نمیداند موتور برنامه چگونه میچرخد.
چرا مستندات فنی راهکار قطعی نیستند؟
برخی معتقدند «توسعه مبتنی بر مشخصات» (Spec-driven development) — یعنی نوشتن یک مدل داده مفصل، تعریف مرزهای احراز هویت و ایجاد یک قرارداد API پیش از شروع — این ریسکها را حل میکند. این یک روش بهتر است و به هر کسی که از کمک AI استفاده میکند توصیه میشود. با این حال، یک مستند (Spec) تنها به اندازه درکِ نویسندهاش ارزشمند است.
یک غیربرنامهنویس تعریف میکند سیستم «چه کاری» باید انجام دهد. در مقابل، یک مهندس نرمافزار با بررسی آن مستند، فوراً میبیند چه چیزهایی «غایب» است. متخصص روی جزئیاتی دست میگذارد که یک تازهکار کاملاً نادیده میگیرد:
- شرایط مسابقه (Race Conditions) که پیشبینی نشدهاند.
- شکافها در مدل مجوزهای دسترسی (Authorization Model).
- ساختارهای دادهای که در زمان حذف رکوردها با شکست مواجه میشوند.
- فرضيات کشینگ (Caching) که در زمان نوشتنهای همزمان (Concurrent Writes) میشکنند.
تأیید اینکه آیا اجرای مدل هوش مصنوعی واقعاً با یک مستند فنی متقاعدکننده مطابقت دارد، نیازمند همان قضاوت مهندسی است که Vibe Coding آن را دور میزند. این دانش سالها زمان میبرد تا ساخته شود و نمیتوان آن را میانبر زد یا نادیده گرفت. توسعه مبتنی بر مشخصات تنها مشکل ریسک را جابهجا میکند، اما آن را حذف نمیکند.
ایستگاه بازرسی انسانی
عرضه نرمافزاری که با دادههای واقعی سروکار دارد و نیازمند امنیت واقعی است، مستلزم وجود انسانی است که مهندسی نرمافزار را بفهمد تا به عنوان آخرین ایستگاه بازرسی عمل کند. هوش مصنوعی میتواند یک ضربکننده بهرهوری عظیم باشد، اما نمیتواند جایگزین قضاوت (Judgment) شود. یک مهندس حرفهای باید چهار بازبینی حیاتی انجام دهد:
۱. بازبینی معماری: تحلیل اینکه آیا ساختار سیستم پایدار خواهد بود و آیا مرزهای بین اجزا منطقی هستند یا خیر. هدف این است که اطمینان حاصل شود سیستم در افق زمانی ۱۲ ماهه قابل نگهداری باقی میماند.
۲. بازرسی امنیتی: تفکر مانند یک مهاجم برای شکار کنترلهای دسترسی شکسته و آسیبپذیریهایی که هوش مصنوعی از قلم انداخته است.
۳. بررسی مقیاسپذیری: شناسایی گلوگاههای بدیهی و اطمینان از اینکه پرسوجوهای پایگاه داده منطقی هستند، پیش از آنکه سیستم به ۱۰ برابر بار فعلی خود برسد.
۴. حسابرسی وابستگیها: بررسی هر بسته برای آسیبپذیریهای شناختهشده و تعیین اینکه آیا پروژه واقعاً به تمام کتابخانههایی که فراخوانی شدهاند نیاز دارد یا خیر.
تفاوت این دو حالت شبیه تفاوت جراحی توسط یک جراح با استفاده از سیستم رباتیک در مقابل کسی است که سعی میکند بعد از دیدن یک آموزش یوتیوب جراحی کند. ابزار، تخصص نمیبخشد؛ بلکه تخصص است که نحوه استفاده از ابزار را شکل میدهد. مهندس میداند چه زمانی پیشنهاد AI را رد کند و تشخیص دهد که یک راهکار تولیدشده بیش از حد سادهانگاشته (Naive) است و نیاز به بازطراحی کامل دارد.
برای غیربرنامهنویسان، مسیر مسئولانه این است که از هوش مصنوعی برای نمونهسازی (Prototyping)، اکتشاف و آزمایشهای آخر هفته استفاده کنند. اینها فعالیتهای کمریسک هستند. اما پیش از انتقال به محیط تولید، آنها باید یک مهندس نرمافزار را به عنوان یک ایستگاه بازرسی دائمی استخدام کنند، نه فقط برای یک بازرسی یکباره. خطرناکترین وضعیت در عصر فعلی هوش مصنوعی، داشتن «اعتماد بدون درک» است.
اگر شما مهندسی هستید که از شما خواسته شده یک سیستم Vibe-coded را بازبینی کنید، با دقت نگاه کنید. شکافها تقریباً همیشه دقیقاً در جایی هستند که انتظار دارید: در مدیریت ورودیها، تعیین محدوده دادهها (Data Scoping) و موارد مربوط به خطاها. مسیر موفقیت (Happy Path) معمولاً کار میکند، اما هر چیز دیگری یک قمار است. به محض وقوع یک حادثه در دنیای واقعی، «حسها» دیگر کار نمیکنند. تنها چیزی که پوشش واقعی ایجاد میکند، قضاوت مهندسی است.
گام بعدی شما
- اگر غیرفنی هستید، از AI برای ساخت MVP استفاده کنید اما پیش از جذب کاربر واقعی، یک Audit فنی جامع بگیرید.
- اگر مهندس هستید و سیستمی Vibe-coded را بازبینی میکنید، مستقیماً سراغ مدیریت ورودیها و لایههای دسترسی بروید؛ احتمالاً حفرهها آنجاست.
- یاد بگیرید چگونه «مستندات فنی» را به جای «پرامپتهای بلند»، به عنوان ورودی به مدل بدهید تا خطاهای معماری کاهش یابد.
اما ابزارهای جدیدی در راهند که سعی میکنند خودشان نقش این بازرس انسانی را بازی کنند — در تحلیل ما دربارهی مدلهای استدلالی (Reasoning Models) بررسی کنید که آیا آنها میتوانند جایگزین قضاوت مهندسی شوند یا خیر.
گفتگو