قبل از Vibe Coding چه چیزهایی از توسعه نرم‌افزار باید بدانیم؟

وقتی مدل زبانی بزرگ (LLM) در چند دقیقه صفحه و فرم می‌سازد، وسوسه این است که مبانی را «برای بعد» بگذارید. بعد معمولاً وقتی می‌رسد که برنامه اجرا می‌شود اما رفتارش را نمی‌فهمید، یا Accept All چند پرونده را طوری عوض می‌کند که نقطهٔ شروع ندارید.

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

پاسخ کوتاه

برای Vibe Coding مفید — یعنی توصیف نیت، اجرای خروجی، و حلقهٔ اصلاح — لازم نیست الگوریتم‌نویس حرفه‌ای باشید. لازم است ده مفهوم را در سطح «حداقل کافی» بشناسید: مبانی برنامه‌نویسی، Git، HTTP، رابط برنامه‌نویسی کاربردی (API)، پایگاه داده (Database)، اشکال‌زدایی (Debugging)، تست (Testing)، امنیت پایه، استقرار (Deployment)، و معماری پایه.

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

AI تایپ را ارزان کرده است. قضاوت هنوز مال کسی است که می‌فهمد برنامه چه می‌کند و عمداً چه کارهایی را نمی‌کند.

• ارشد بودن شرط شروع نیست؛ نخواندن خروجی هم استراتژی نیست.
• هر موضوع سه سطح دارد: جهت‌دهی، ارزیابی، مالکیت تولید. برای شروع، سطح اول و بخشی از دوم کافی است.
• بهترین مسیر موازی است: با AI بسازید، همان خروجی را به‌عنوان مادهٔ درسی بخوانید.

تز: فهم نرم‌افزار کیفیت هدایت AI را بالا می‌برد

مدل پیشنهاد می‌دهد. شما محدوده، معیار تمام‌شدن، و پذیرش را تعیین می‌کنید. اگر واژه‌ها را نشناسید، پرامپت مبهم می‌شود و مدل فرض می‌کند. اگر رفتار سیستم را نشناسید، «اجرا شد» را با «درست است» یکی می‌گیرید.

آندری کارپاتی (Andrej Karpathy) در فوریهٔ ۲۰۲۵ Vibe Coding را برای پروژهٔ آخرهفته توصیف کرد: دیدن، گفتن، اجرا. مارتین فاولر (Martin Fowler) و سیمون ویلیسون (Simon Willison) خط کشیدند: نخواندن کد با مهندسی یاری‌شده یکی نیست. این مقاله لایهٔ وسط است: چه فهمی لازم است تا از «حس» به مالکیت بروید — بدون سال‌ها صبر.

چارچوب سه‌سطحی: چقدر از هر موضوع کافی است؟

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

1. جهت‌دهی: واژه‌ها و یک مدل ذهنی. می‌توانید از AI کار مشخص بخواهید و محدوده را بگویید.
2. ارزیابی: خواندن خروجی و تشخیص بی‌معنایی. می‌توانید diff را نگاه کنید، خطا را به ادعا تبدیل کنید، و پیشنهاد خطرناک را رد کنید.
3. مالکیت تولید: تغییر کنترل‌شده، تست، برگشت، و توضیح سیستم برای دیگری. این سطح برای محصول با کاربر واقعی است، نه برای پیش‌نمونهٔ شخصی.

قانون تشویقی: با سطح جهت‌دهی شروع کنید و همان روز ارزیابی را تمرین کنید. مالکیت تولید را وقتی بار کنید که ریسک واقعی شود — نه به‌عنوان بلیت ورود به یادگیری.

جدول زیر سقف نیست؛ کفِ مفید است. ستون اول همان چیزی است که از تازه‌کار می‌خواهیم — نه مصاحبهٔ استخدام.

ده مفهوم حداقلی — با کفِ قابل لمس

هدف هر بخش یکی است: بفهمید «کافی» کجاست تا نه خودتان را بترسانید، نه با توهمِ ندانستنِ لازم جلو بروید. مثال‌ها کوچک‌اند؛ عمداً.

مبانی برنامه‌نویسی

برنامه دنباله‌ای از دستورهاست که داده را عوض می‌کند. متغیر نام یک مقدار است. شرط مسیر را دو شاخه می‌کند. حلقه کار را تکرار می‌کند. تابع یک تکه کار نام‌دار است با ورودی و خروجی. نوع داده — متن، عدد، فهرست، شیء — مشخص می‌کند چه عملی مجاز است.

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

Git

Git حافظهٔ کار است، نه دکمهٔ ذخیره. commit یک عکس معنادار از تغییر است. diff نشان می‌دهد چه خطی عوض شد. شاخه آزمایش را از مسیر اصلی جدا می‌کند. چت با مدل این کارها را نمی‌کند؛ با بستن نشست از بین می‌رود.

حداقل جهت‌دهی: بعد از هر رفتار تمام‌شده یک commit با پیام انسانی. حداقل ارزیابی: قبل از Accept بزرگ، diff را بخوانید. اگر پیام فقط wip است و هزار خط یک‌جا آمده، فردا حتی خودتان مالک آن تغییر نیستید. Git SCM همین را ساده می‌گوید: عکس وضعیت، نه جادوی ابری.

HTTP

وب روی HTTP است: درخواست و پاسخ. روش نیت را می‌گوید — GET خواندن، POST ایجاد، DELETE حذف. کد وضعیت نتیجه را خلاصه می‌کند: ۲xx موفق، ۴xx مشکل درخواست یا مجوز، ۵xx مشکل سرور.

حداقل جهت‌دهی: «صفحه را بگیر» یعنی GET؛ «فرم را بفرست» اغلب POST. حداقل ارزیابی: حذف با GET، یا درمان ۴۰۴ مثل ۵۰۰، یعنی قرارداد فهمیده نشده. مرجع پایدار MDN است؛ نسخهٔ فریم‌ورک جای پروتکل را نمی‌گیرد.

API

API قرارداد است: با این ورودی، آن خروجی؛ با این خطا، آن کد. در وب معمولاً JSON روی HTTP. احراز هویت غالباً در سرآیند است، نه در متن صفحه. نسخه و مسیر بخشی از قراردادند.

حداقل جهت‌دهی: مسیر، بدنه، و پاسخ موفق/ناموفق را در پرامپت بنویسید. حداقل ارزیابی: آدرس یا تابعی که در مستند سرویس نیست، احتمالاً بافته است. API را از UI جدا ببینید؛ اگر فقط با کلیک می‌فهمید سیستم چیست، مدل هم مرز را گم می‌کند.

Database

حافظهٔ برنامه با بستن فرایند از بین می‌رود. پایگاه داده داده را ماندگار می‌کند و قواعدی مثل یکتایی و ارتباط را اعمال می‌کند. جدول با سطر و ستون، یا سند JSON، هر دو «جا» هستند؛ سؤال مهم این است منبع حقیقت کجاست.

حداقل جهت‌دهی: چه موجودیتی ذخیره می‌شود و چه چیزی یکتاست. حداقل ارزیابی قبل از طرح تولیدشده: کلید اصلی چیست؟ چه یکتاست؟ حذف چه چیزی را یتیم می‌کند؟ برداشتن قید «تا ارور ندهد» پنهان‌کردن مسئله است. فرق کش موقت و دادهٔ کسب‌وکار را بفهمید؛ UI بازنویسی می‌شود، دادهٔ خراب سخت‌تر.

Debugging

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

حداقل جهت‌دهی: به‌جای «درستش کن»، خطا را خام بدهید، انتظار را بگویید، محدوده را قفل کنید. اگر مدل پروندهٔ نامربوط را عوض کرد، برگردانید. برای کد ماندگار، خطا باید ادعا شود نه فقط paste. وقتی مسیر فهم دارید — حتی بدون جواب آماده — از vibe debug خارج شده‌اید.

Testing

اجرا شدن تست نیست. تست یعنی ادعا قابل‌تکرار: با این ورودی، این خروجی؛ با ورودی خراب، این خطا. مسیر شاد (happy path) لازم است و کافی نیست. مدل در نوشتن تست برای کدی که خودش ساخته سوگیری دارد؛ ممکن است همان توهم را قفل کند.

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

امنیت پایه

سه عادت روزاول کافی است؛ لازم نیست مصاحبهٔ نفوذ بدهید. راز در مخزن و لاگ نرود. ورودی کاربر دشمن است. ورود (authentication) با مجوز (authorization) یکی نیست. در diff دنبال secret، شبکه و مسیر فایل بگردید. OWASP Top 10 زبان مشترک محصول وب است؛ مدل ممکن است لاگین شبیه بسازد و مرز مجوز را غلط بکشد — این فقط با خواندن دیده می‌شود.

Deployment

localhost محصول نیست. استقرار یعنی همان برنامه جایی که کاربر و شکست واقعی هست. پیکربندی را با متغیر محیطی از کد جدا کنید؛ راز محیط‌ها قاطی نشود. حداقل جهت‌دهی: «روی ماشین من، بدون دادهٔ واقعی». اگر مدل اسکریپت استقرار نوشت، بپرسید تکرارپذیر است یا به فایل دستی وابسته. Twelve-Factor App همین جدایی را اصل کرده. rollback یعنی راه برگشت — نه پرامپت دوباره «درستش کن».

معماری پایه

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

مسیر یادگیری عملی: موازی، نه صف انتظار

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

1. هفتهٔ اول: یک اسکریپت یا صفحهٔ محلی. متغیر و تابع را در خروجی پیدا کنید. Git را با commit کوچک روشن کنید.
2. هفتهٔ دوم: یک فرم که داده را در فایل یا SQLite ذخیره کند. HTTP را در ابزار توسعه‌دهندهٔ مرورگر ببینید. یک تست برای مسیر اصلی بنویسید یا بپذیرید.
3. هفتهٔ سوم: یک API خیلی کوچک. خطا را عمداً بسازید و با پیام خام اشکال‌زدایی کنید. راز را از کد بیرون بکشید.
4. هفتهٔ چهارم: استقرار روی یک محیط غیرمحلی با دادهٔ ساختگی. نقشهٔ یک‌جمله‌ای اجزا را روی کاغذ بکشید. هر پیشنهاد بزرگ را با diff بخوانید.

این تقویم ضدبهانه است نه قانون. مفهوم گیرکرده را روی همان پروژه تمرین کنید. دورهٔ «تا تمام نشود سراغ AI نرو» معمولاً فقط ترس می‌سازد.

چه چیزی لازم نیست — تا بعداً

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

اشتباه‌های رایج

• صبر کردن تا «ارشد شوم» و در نتیجه نساختن هیچ‌چیز.
• ساختن همه‌چیز با Accept All و بعد تعجب از این‌که اشکال‌زدایی ممکن نیست.
• یکی دانستن اجرای ظاهر با صحت رفتار.
• فرستادن دادهٔ واقعی مشتری به چت یا به برنامهٔ آزمایشی.
• خواستن معماری ماندگار در اولین پرامپت، بدون نقشهٔ مرز.
• تست نخوانده؛ تستی که همان توهم مدل را ثبت می‌کند.
• نبود Git، یا یک commit غول‌آسا در پایان روز.
• ترک مبانی با این جمله که «دیگر لازم نیست کد بدانم».

جمع‌بندی

سرعت Vibe Coding وقتی مفید است که نیت دقیق و قضاوت خروجی داشته باشید. قضاوت از مدرک ارشد نمی‌آید؛ از حداقل کافی روی همان ده مفهوم جدول می‌آید.

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

پرسش‌های متداول

باید قبل از اولین پرامپت همهٔ این ده مورد را تمام کنم؟

خیر. با جهت‌دهی روی برنامه‌نویسی و Git شروع کنید. بقیه را روی همان پروژهٔ کوچک اضافه کنید. مقاله برای ساختن صف انتظار نوشته نشده.

اگر برنامه‌نویس نیستم، اصلاً Vibe Coding به درد من می‌خورد؟

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

مدل خودش توضیح می‌دهد؛ چرا خودم یاد بگیرم؟

توضیح مدل ممکن است با رفتار یکی نباشد. یادگیری یعنی بتوانید توضیح را آزمایش کنید. بدون آن، اطمینانِ لحن را با شواهد عوض کرده‌اید.

از کدام موضوع اگر فقط یکی را بردارم؟

اگر مجبورید یکی را امروز: خواندن خطا به‌اضافهٔ Git با commit کوچک. این دو حلقهٔ «شکست و برگشت» را زنده نگه می‌دارند. فردا HTTP و راز را اضافه کنید.

چه زمانی از حالت حس به مهندسی با کمک AI بروم؟

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

منابع و مراجع

• Andrej Karpathy — معرفی Vibe Coding روی X (۲ فوریه ۲۰۲۵): https://x.com/karpathy/status/1886192184808149383
• Martin Fowler — Vibe Coding (۲۱ مه ۲۰۲۶): https://martinfowler.com/bliki/VibeCoding.html
• Simon Willison — Not all AI-assisted programming is vibe coding (۱۹ مارس ۲۰۲۵): https://simonwillison.net/2025/Mar/19/vibe-coding/
• Git SCM — Documentation: https://git-scm.com/docs
• MDN — HTTP overview: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
• MDN — HTTP request methods: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods
• OWASP Top 10:2021: https://owasp.org/Top10/2021/
• The Twelve-Factor App: https://12factor.net/