آیا بدون دانش فنی می‌توان Vibe Coding کرد؟

سؤال معمولاً با دو قطب جواب داده می‌شود: «دیگر برنامه‌نویس لازم نیست» یا «بدون مدرک کامپیوتر حتی شروع نکن». هر دو غلط‌اند. واقعیتِ قابل‌مشاهده این است که مدل زبانی بزرگ (Large Language Model) یا LLM ورود را آسان‌تر کرده؛ و واقعیتِ کمتر دیده این است که تولید کد با ساختن نرم‌افزار قابل‌اعتماد یکی نیست.

این مقاله طرف ترس یا هیجان نیست. می‌گوید بدون دانش فنی کجا می‌شود شروع کرد، کجا ظاهر «کار می‌کند» فریبنده است، چه کلاس ریسک‌هایی ممکن است دیده نشوند، و چرا در پروژهٔ واقعی مسئولیت فنی و تجاری همچنان مال انسان است — بدون ادعای حقوقیِ بدون منبع.

پاسخ کوتاه

بله، می‌توانید — با شرط. بدون دانش فنی می‌توانید ایده را توصیف کنید، خروجی را اجرا کنید، و برای خودتان یا یک دایرهٔ کوچکِ کم‌ریسک ابزار بسازید. آندری کارپاتی (Andrej Karpathy) همین سبک را برای پروژهٔ آخرهفتهٔ دورریختنی توصیف کرد؛ مارتین فاولر (Martin Fowler) صریحاً نوشته چون به کد نگاه نمی‌شود، برای کسی بدون دانش برنامه‌نویسی هم «مناسب» است — برای نرم‌افزار دورریختنی و مخاطب محدود.

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

If you’re going to put your name to it you need to be confident that you understand how and why it works. — سیمون ویلیسون

چرا ورود واقعاً آسان‌تر شده است

مانع قدیمی این بود که قبل از دیدن هر نتیجه‌ای باید نحو، ابزار و محیط را یاد می‌گرفتید. حالا می‌توانید رفتار را بگویید و چیزی روی صفحه ببینید. ویلیسون در ۱۹ مارس ۲۰۲۵ نوشته اگر این سبک به میلیون‌ها نفر اجازه دهد کار تکراری زندگی‌شان را خودکار کنند، خبر خوبی است؛ و برای بعضی همان تجربه شیب ورود به حرفه را کم می‌کند.

۲۷ فوریهٔ ۲۰۲۵ کوین روس (Kevin Roose) در نیویورک‌تایمز — در مقام کسی که خود را برنامه‌نویس حرفه‌ای نمی‌داند — از ساخت چند ابزار کوچک با توصیف ایده نوشت و آن‌ها را «نرم‌افزار برای یک نفر» نامید. ارزش آن گزارش در اثبات جادو نیست؛ در نشان‌دادن کفِ واقعی است: ایده + صبر می‌تواند به ابزار شخصی برسد، و همان متن محدودیت و خطا را هم گفت.

مریم-وبستر در تعریف slang نوشت در این کار لازم نیست بفهمید کد چرا کار می‌کند و اغلب باید وجود باگ را بپذیرید. این جمله تشویق به بی‌احتیاطی نیست؛ توصیف همان سبکی است که نام‌گذارش «تقریباً کار می‌کند» خواند. پس پاسخ «آیا می‌توان شروع کرد؟» بله است. سؤال بعدی «برای چه و با چه شرطی؟» است.

تولید کد ≠ ساختن نرم‌افزار قابل‌اعتماد

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

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

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

ظاهر کار می‌کند، زیر پوست چه می‌تواند غلط باشد

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

امنیت: مجوز، راز، دادهٔ کاربر

فرم ورود روی صفحه به‌معنای هویت درست نیست. OWASP در Top 10 ویرایش ۲۰۲۱ کنترل دسترسی شکسته را در صدر گذاشت: کاربر نباید با عوض‌کردن یک شناسه در نشانی، دادهٔ دیگری را ببیند؛ مخفی‌کردن دکمهٔ ادمین در رابط مجوز نیست. بدون دانش فنی، «لاگین دارم» با «دسترسی درست دارم» یکی گرفته می‌شود.

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

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

معماری و عملکرد: وقتی یک نفر می‌شود صد نفر

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

نگهداری: وقتی خودتان فردا به خودتان می‌رسید

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

چه کارهایی بدون دانش فنی منطقی‌اند

مرز را با ریسک بکشید، نه با غرور. کارهای زیر معمولاً با دانش کم و احتیاط معقول جورند:

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

این فهرست اجازهٔ انتشار عمومی هر چیزی که «بالا آمد» نیست. اجازهٔ شروع است.

چه کارهایی بدون دانش فنی هنوز خطرناک‌اند

این‌جا هم مرز ریسک است:

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

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

مسئولیت فنی و تجاری همچنان می‌ماند

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

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

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

اگر دانش فنی ندارید، حداقل چه چیزی را یاد بگیرید

هدف ارشد شدن قبل از اولین prompt نیست. هدف این است که بتوانید سؤال درست بپرسید و پیشنهاد خطرناک را رد کنید. پنج سؤال عملی از یک دورهٔ کامل مفیدترند:

1. داده کجا ذخیره می‌شود و اگر برنامه را خاموش کنم چه می‌ماند؟
2. چه کسی به چه چیزی دسترسی دارد — و این تصمیم در سرور است یا فقط در صفحه؟
3. راز یا کلید داخل پرونده هست؟ اگر مخزن عمومی شود چه لو می‌رود؟
4. اگر کاربر دو بار کلیک کند یا شبکه قطع شود، چه وضعیتی باید بماند؟
5. اگر امشب بشکند، از کجا می‌فهمم کجا را نگاه کنم؟

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

سه برچسب، سه سطح ریسک

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

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

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

جمع‌بندی

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

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

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

منابع و مراجع

• 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/
• Kevin Roose، The New York Times (۲۷ فوریهٔ ۲۰۲۵): https://www.nytimes.com/2025/02/27/technology/personaltech/vibecoding-ai-software-programming.html
• Martin Fowler — Vibe Coding: https://martinfowler.com/bliki/VibeCoding.html
• Andrej Karpathy، پست اصلی (۲ فوریهٔ ۲۰۲۵)؛ بایگانی: https://archive.ph/yNSTA
• Merriam-Webster — vibe coding: https://www.merriam-webster.com/slang/vibe-coding
• OWASP Top 10:2021 — A01 Broken Access Control: https://owasp.org/Top10/2021/A01_2021-Broken_Access_Control/
• CWE-798 — Use of Hard-coded Credentials: https://cwe.mitre.org/data/definitions/798.html
• The Twelve-Factor App — Config: https://12factor.net/config
• GitHub Docs — About secret scanning: https://docs.github.com/en/code-security/secret-scanning/about-secret-scanning
• GitHub Docs — Removing sensitive data from a repository: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/removing-sensitive-data-from-a-repository