محدودیت‌های Vibe Coding وقتی می‌خواهید یک محصول واقعی بسازید

یک فروشگاه را در نظر بگیرید که در یک بعدازظهر با هوش مصنوعی (Artificial Intelligence) یا AI سر پا شده: کاتالوگ هست، سبد هست، دکمهٔ پرداخت هست، و ورود با ایمیل «کار می‌کند». روی لپ‌تاپ صاحبش زیباست. سؤال این مقاله این نیست که آن بعدازظهر بی‌ارزش بوده. سؤال این است که از آن صفحه تا محصولی که موجودی را دروغ نمی‌گوید، پول را دو بار برنمی‌دارد، و حساب دیگران را نشان نمی‌دهد، چه کارهایی مانده که حلقهٔ Vibe Coding به‌تنهایی انجام نمی‌دهد.

حمله به ابزار نیست. مدل زبانی بزرگ (Large Language Model) یا LLM در ساخت ظاهر، مسیر شاد و کد تکراری واقعاً سریع است. ناکافی‌بودن از جنس کار باقی‌مانده است: معماری، امنیت، تست، اشکال‌زدایی (Debugging)، استقرار (Deployment)، نگهداری و تفکر محصول. اگر این هفت لایه را روی همان فروشگاه ببینید، تصمیم روشن‌تر از شعار «AI همه‌چیز را می‌نویسد» می‌شود.

پاسخ کوتاه

Vibe Coding برای فهمیدن این‌که ایده اصلاً به درد می‌خورد عالی است. برای محصول واقعی — با مشتری، موجودی، پرداخت و هویت — کافی نیست، چون «اجرا شد» فقط مسیر شاد را نشان می‌دهد.

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

Vibe coding your way to a production codebase is clearly risky. — سیمون ویلیسون، مارس ۲۰۲۵

صحنه: فروشگاهی که «کار می‌کند»

فرض کنید یک فروشگاه کوچک لوازم خانه. سه قابلیت را مدل در چند ساعت می‌سازد: فهرست کالا و کم‌کردن موجودی بعد از خرید؛ صفحهٔ پرداخت که به یک درگاه آزمایشی وصل است؛ و ورود کاربر با ایمیل و گذرواژه. هر سه روی localhost سبزند. مشتری آزمایشی می‌خرد، موجودی یکی کم می‌شود، ایمیل «سفارش ثبت شد» می‌آید.

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

آنچه AI راحت می‌کند، آنچه برای انسان می‌ماند

جدول زیر تقسیم کار است، نه حکم ممنوعیت. ستون چپ را دست‌کم نگیرید؛ همان‌ها دلیل ارزشمند بودن Vibe Coding در اکتشاف‌اند. ستون راست را هم به «بعداً» نسپارید اگر پول و دادهٔ واقعی در راه است.

معماری: موجودی یک عدد روی صفحه نیست

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

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

نشانهٔ هشدار در همین فروشگاه ساده است. اگر با یک prompt جدید بتوانید «تخفیف لحظه‌ای» اضافه کنید و سه جدول بی‌ربط عوض شود، ساختار نداشته‌اید؛ میان‌بر داشته‌اید. AI میان‌بر را سریع می‌سازد. انسان باید بگوید کدام میان‌بر مجاز نیست.

امنیت: ورود ≠ هویت، و پرداخت صفحهٔ زیبا نیست

فهرست ده ریسک برتر OWASP در ویرایش ۲۰۲۱ کنترل دسترسی شکسته را در صدر گذاشت: در داده‌های مشارکتی، ۹۴٪ برنامه‌ها برای نوعی از این ضعف آزموده شدند و این دسته بیشترین رخداد را داشت. تزریق (Injection) — از جمله SQL و XSS — سوم است. این‌ها شعار نیستند؛ الگوهای تکراری‌اند که در فروشگاه خیلی زود ظاهر می‌شوند.

مدل فرم لاگین می‌سازد. محصول باید بگوید کاربر A سفارش کاربر B را با عوض‌کردن شناسه در نشانی نبیند — همان الگوی ارجاع مستقیم ناامن که OWASP مثال زده است. مدل دکمهٔ «ادمین» می‌سازد. محصول باید بگوید مخفی‌کردن دکمه در رابط کاربری (UI) مجوز نیست؛ مجوز فقط در سرور معتبر است. مدل درگاه را وصل می‌کند. محصول باید بگوید مبلغ و وضعیت پرداخت از پاسخ امضاشدهٔ درگاه می‌آید، نه از پارامتر قابل‌ویرایش مرورگر.

رازها میدان جداگانه‌اند. CWE-798 — استفاده از اعتبارنامهٔ سخت‌کدشده — ضعفی با احتمال بهره‌برداری بالاست: کلید در پرونده، گذرواژه در مخزن، یک حساب پشتی برای «تست». چارچوب Twelve-Factor می‌گوید پیکربندی متغیر بین محیط‌ها، از جمله اعتبارنامه، باید بیرون کد باشد؛ آزمون ساده‌اش این است که اگر مخزن همین الآن عمومی شود، رازی لو نرود. GitHub Secret scanning دقیقاً برای همین کلاس نشت ساخته شده: کلید و توکنی که وارد تاریخچهٔ Git شود، هدف است.

گزارش Veracode در ۲۰۲۵ روی بیش از صد LLM نشان داد نحوِ درست خیلی بهتر شده، اما امنیت کد تولیدشده اغلب همراه آن بالا نیامده؛ در مجموعهٔ اولیه حدود ۴۵٪ موارد یک ضعف قابل‌کشف وارد خروجی می‌شد. «مدل جدیدتر برابر کد امن‌تر» قانون نیست. در فروشگاه یعنی Accept All روی پرداخت و هویت، ریسک را از روی صفحه پاک نمی‌کند؛ فقط پنهانش می‌کند.

تست: مسیر شاد فروشگاه دروغِ آرامش است

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

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

اشکال‌زدایی: وقتی موجودی منفی می‌شود

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

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

جملهٔ «تا مجبور نشوی vibe debug کنی، همه چیز بازی است» شوخی است، اما دقیق است. فروشگاهی که موجودی‌اش گاهی منفی می‌شود، دیگر پروژهٔ آخرهفته نیست.

استقرار: localhost محصول نیست

مدل یک دستور اجرا و یک فایل محیط نمونه می‌نویسد. استقرار واقعی تصمیم‌های دیگری دارد: پایگاه دادهٔ تولید از توسعه جدا است یا نه؟ کلید درگاه آزمایشی جای کلید واقعی را می‌گیرد یا هر دو در یک پرونده‌اند؟ اگر نسخهٔ جدید سفارش‌های نیمه‌کاره را بشکند، برگشت (rollback) دارید؟

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

نگهداری: درگاه عوض می‌شود، شما می‌مانید

دمو را می‌توان دور انداخت. محصول می‌ماند: درگاه نسخهٔ API عوض می‌کند، نرخ مالیات تغییر می‌کند، انبار دوم اضافه می‌شود، و کسی که prompt اول را نوشته شاید در تیم نباشد. نگهداری یعنی تغییر کنترل‌شده روی سامانه‌ای که دادهٔ واقعی دارد.

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

تفکر محصول: کد جواب مسئلهٔ غلط را هم سریع می‌نویسد

prompt «فروشگاه بساز» یک کاتالوگ می‌سازد. تفکر محصول می‌پرسد: خریدار کیست؟ حداقل سفارش چیست؟ مرجوعی دارید یا نه؟ موجودی نمایشی است یا تعهد فروش؟ پرداخت در لحظه است یا پیش‌فاکتور؟ چه چیزی عمداً در نسخهٔ اول نیست؟

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

یک تمرین کوتاه قبل از prompt بعدی: یک پاراگراف مسئله، سه معیار پذیرش، یک ضدهدف. مثلاً «مرجوعی نداریم؛ پرداخت فقط یک درگاه؛ ادمین سفارش دیگران را نمی‌بیند». همین سه خط کیفیت خروجی را بیشتر از ده صفت «حرفه‌ای و مقیاس‌پذیر» بالا می‌برد.

چطور متعادل بمانیم: AI را نگه دارید، کافی‌بودنش را نه

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

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

روایت Y Combinator از زمستان ۲۰۲۵ نشان داد حتی تیم‌های فنی هم ممکن است درصد بالایی از خط‌ها را با مدل بنویسند. همان روایت از زبان خودشان به سلیقهٔ قضاوت و عمق اشکال‌زدایی برگشت. درصد خط نوشته‌شده با درصد محصول آماده‌یکی نیست.

جمع‌بندی

فروشگاهی که در یک بعدازظهر «کار می‌کند» پیروزی حلقهٔ توصیف-تولید-اجرا است. محصولی که موجودی‌اش دروغ نمی‌گوید، پرداخت نیمه‌کاره را درست برمی‌گرداند، و سفارش دیگران را نشان نمی‌دهد، به هفت کار دیگر نیاز دارد: معماری، امنیت، تست، اشکال‌زدایی، استقرار، نگهداری و تفکر محصول.

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

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

منابع و مراجع

• Simon Willison — Not all AI-assisted programming is vibe coding (۱۹ مارس ۲۰۲۵): https://simonwillison.net/2025/Mar/19/vibe-coding/
• Benj Edwards، Ars Technica — Will the future of software development run on vibes? (۵ مارس ۲۰۲۵): https://arstechnica.com/ai/2025/03/is-vibe-coding-with-ai-gnarly-or-reckless-maybe-some-of-both/
• Martin Fowler — Vibe Coding: https://martinfowler.com/bliki/VibeCoding.html
• Andrej Karpathy، پست اصلی (۲ فوریهٔ ۲۰۲۵)؛ بایگانی: https://archive.ph/yNSTA
• OWASP Top 10:2021 — A01 Broken Access Control: https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
• OWASP Top 10:2021 — A03 Injection: https://owasp.org/Top10/2021/A03_2021-Injection/
• Veracode — 2025 GenAI Code Security Report: https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
• Veracode — Insights from 2025 GenAI Code Security Report (۳۰ ژوئیهٔ ۲۰۲۵): https://www.veracode.com/blog/genai-code-security-report/
• The Twelve-Factor App — Config: https://12factor.net/config
• CWE-798 — Use of Hard-coded Credentials: https://cwe.mitre.org/data/definitions/798.html
• GitHub Docs — About secret scanning: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
• Ivan Mehta، TechCrunch — YC W25 (۶ مارس ۲۰۲۵): https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/