تصور کنید برنامه‌نویسی به جای حل مسئله، به یک بازی حدس زدن تبدیل شود که در آن شما فقط می‌گویید «یک چیزی شبیه به این می‌خواهم» و کد را بدون بررسی دقیق اجرا می‌کنید. اگر امروز کدها را بدون درک منطق زیربنایی‌شان می‌پذیرید، در واقع دارید مهارت‌های مهندسی خود را با یک توهمِ تسلط معاوضه می‌کنید.
این وضعیت با ظهور Vibe Coding (برنامه‌نویسی بر اساس حس) شدت یافته است؛ اصطلاحی که آندری کارپاتی (Andrej Karpathy) برای توصیف روشی از کار با هوش مصنوعی به کار برد که در آن جزئیات فنی نادیده گرفته می‌شوند. این رویکرد در عمل باعث شده تا ساختارهای پیچیده‌ای نظیر بازی‌های مرورگر تنها از طریق دستورات متنی و بدون کدنویسی دستی خلق شوند. طبق این دیدگاه، خطر واقعی اتوماسیون نیست، بلکه تغییری است که در آن توسعه‌دهنده دیگر نمی‌پرسد «چرا این کد کار می‌کند؟» و فقط می‌پرسد «بعدی چیست؟».
این روند زمانی رخ می‌دهد که دستیارهای هوش مصنوعی توهمی از سواد و درک ایجاد می‌کنند. برای بسیاری، این ابزارها از جایگزین‌های ساده برای جست‌وجو — شبیه به یک جست‌وجوی گوگل در سال ۲۰۱۰ — به شریکاهای فعال در بدنه کد تبدیل شده‌اند. اما همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، میزان اتکا به این شرکا در صنعت به‌شدت متفاوت است. در این میان، تضاد میان سرعت توسعه و امنیت در Vibe Coding به یکی از چالش‌های کلیدی در برابر روش‌های سنتی مهندسی پرامپت تبدیل شده است.
مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — اکنون می‌تواند به گونه‌ای تعامل کند که فقدان درک واقعی‌اش را بپوشاند. این موضوع حس کاذبی از صلاحیت ایجاد می‌کند. یک توسعه‌دهنده تازه‌کار باید بداند که انتخاب ابزار یک تصمیم استراتژیک است. ابزارها یک نسخه واحد برای همه نیستند؛ بلکه موضوع بر سر تطبیق ابزار درست با مسئله فنی خاص پیش‌رو است.
به نقل از یادداشتی در dev.to به‌تاریخ ۳۰ جولای ۲۰۲۶، توسعه‌دهندگان در حال حاضر به دو روش Vibe Coding می‌کنند:
- برنامه‌نویسی حسی غیرفعال (Passive Vibe Coding): در این حالت، هوش مصنوعی کد را می‌نویسد و انسان صرفاً آن را می‌پذیرد. در این مود، هوش مصنوعی است مالکیت فرآیند تفکر است.
- برنامه‌نویسی حسی فعال (Active Vibe Coding): در اینجا انسان ایده‌ها را می‌کاود، به پیشنهادات هوش مصنوعی اعتراض می‌کند و نتیجه نهایی را شکل می‌دهد. در این حالت، مالکیت منطق نزد انسان می‌ماند.
بر اساس مستندات این رویکرد، برنامه‌نویسی حسی فعال مانند یک شراکت عمل می‌کند و شامل چندین مکانیسم پویا است:
- شکل‌دهی تکرارشونده (Iterative Shaping): کاربر بر اساس خروجی هوش مصنوعی، به آن فشار می‌آورد و مسیر را تغییر می‌دهد.
- پرس‌وجوی انتقادی (Critical Inquiry): هوش مصنوعی ممکن است سوالی بپرسد که نقطه ضعف تفکر اولیه انسان را آشکار کند.
- تغییر چشم‌انداز (Perspective Shifting): مدل مسیری یا رویکردی را پیشنهاد می‌دهد که توسعه‌دهنده پیش از این ندیده بود.
- تشخیص خطا (Error Detection): تشخیص لحظاتی که مدل با اطمینان کامل، اما در واقعیت، اشتباه می‌کند.
سازنده‌های باتجربه بر پایه «قضاوت» عمل می‌کنند؛ مهارتی در بازشناسی الگوها که حاصل سال‌ها شکستن و تعمیر سیستم‌هاست. وقتی یک مهندس ارشد حس می‌کند «یک جای کار می‌لنگد»، در واقع شهودی را به کار می‌گیرد که هوش مصنوعی هنوز قادر به بازسازی آن نیست. این قضاوت جادو نیست، بلکه نتیجه مشاهده الگوها توسط مغز در طی تجربه طولانی‌مدت است.
انتخاب ابزار درست همچنان حیاتی است. همان‌طور که یک پتک برای تخریب بتن بهتر از چکش میخ‌زنی است، مدل‌های خاص مختلف اهداف متفاوتی دارند. Gemini، ChatGPT، Alexa یا Grok هر کدام نقاط قوت متفاوتی دارند. سالم‌ترین فرآیند توسعه آن است که از این ابزارها برای تقویت قضاوت انسانی استفاده شود، نه جایگزینی آن.
این وضعیت یک چالش انتقالی میان‌نسلی در زنجیره ابزارهای انسانی ایجاد می‌کند:
- خروج ارشدها (Senior Exit): توسعه‌دهندگان باسابقه در نهایت فرسوده می‌شوند، نقش خود را تغییر می‌دهند یا بازنشسته می‌شوند.
- صعود تازه‌وارها (Junior Ascension): برنامه‌نویسان جدیدتر باید در نهایت مسئولیت بدنه کد (Codebase) را بر عهده بگیرند.
- انتقال دانش (Knowledge Transfer): آنچه امروز آموخته می‌شود، باید به دیگران کمک کند تا فردا سیستم را بفهمند، نگهداری کنند و بهبود بخشند.
اگر تازه‌وارها فقط به Vibe Coding غیرفعال تکیه کنند، درک بنیادینی که برای نگهداری از سیستم‌های قدیمی (Legacy) یا بهبود آن‌ها لازم است را نخواهند داشت. این نگرانی از کاهش درک معماری سیستم در برابر افزایش سرعت توسعه، در حال تبدیل شدن به یک بحران اعتماد در مهندسی نرم‌افزار است. انسان‌ها ذاتاً کاوشگر هستند و ما همیشه روش‌های قدیمی را زیر سوال می‌بریم و به دنبال مسیرهای جدید می‌گردیم.
مهندسی در اساس خود یعنی «تصمیم نهایی». حتی اگر جرقه اولیه یک ایده از هوش مصنوعی باشد، مسئولیت معماری همچنان بر عهده انسان است. درک یک سیستم شبیه راه رفتن بدون نقشه است؛ شاید هر قدم را ندانی، اما مقصد را آن‌قدر خوب می‌شناسی که متوجه شوی چه زمانی از مسیر خارج شده‌ای. هدف این است که از هوش مصنوعی برای بهتر فکر کردن استفاده کنیم، نه برای اجتناب کامل از تفکر.
در نهایت، سوال اصلی برای توسعه‌دهندگان امروز ساده است: مالکیت تفکر با کیست؟ اگر هوش مصنوعی از معادله حذف شود، برنامه‌نویس باید دقیقاً بداند چه چیزی ساخته شده و چرا کار می‌کند. برای جلوگیری از تحلیل‌رانی مهارت‌ها، توسعه‌دهندگان باید آگاهانه تعاملی «فعال» داشته باشند؛ با به چالش کشیدن منطق ماشین و مستندسازی استدلال‌های پشت تغییرات تولید شده توسط AI. در اواخر سال ۲۰۲۶، باید به الگوهای نوظهور در نحوه آموزش مهندسان تازه‌کار برای دی‌باگ کردن کدهای نوشته شده توسط هوش مصنوعی توجه ویژه‌ای داشت.
گام بعدی شما
- در هر تغییر کد توسط AI، از مدل بخواهید «دلیل انتخاب این الگو بر روی جایگزین‌ها» را توضیح دهد.
- تمرینی برای «دی‌باگ کردن دستی» کدهای تولید شده توسط هوش مصنوعی بدون کمک گرفتن از خودِ مدل طراحی کنید.
- مستندات فنی خود را نه بر اساس «چه چیزی» (What)، بلکه بر اساس «چرایی» (Why) تغییرات بنویسید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو