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

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

اما الان داریم یه اتفاق عجیب می‌بینیم که اسمش رو گذاشتن وایب کدینگ (Vibe Coding).

ابزارهایی مثل Cursor یا Claude Code، لایه‌ی دستور زبان رو تقریبا حذف کردن. دیگه بحث این نیست که چطور کد بزنیم، بحث اینه که چطور ابزار رو هدایت کنیم.

توی این دنیای جدید، شما دیگه یه «نویسنده کد» نیستید؛ شما یه رهبر ارکستر یا یه هدایت‌گر هستید.

تفاوتش کجاست؟

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

وقتی هوش مصنوعی می‌تونه در عرض چند ثانیه هزار خط کد بنویسه، داشتن دانش فنی برای نوشتن اون کدها دیگه مزیت رقابتی نیست. مزیت رقابتی تبدیل می‌شه به «سلیقه» (Taste) و «چشم‌انداز محصول».

یعنی اینکه بدونی چه چیزی برای کاربر درسته، چه چیزی بهینه است و کجا باید روی تجربه کاربر حساس بود.

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

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

گلوگاه فنی از بین رفته یا بهتره بگیم به گلوگاه «سلیقه» و «بینش» تبدیل شده.

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

قدرت از دست کسی که «می‌دونه چطور کد بزنه» داره می‌ره به دست کسی که «می‌دونه چه چیزی باید ساخته بشه».

تخصص دیگه توی تسلط بر زبان‌های برنامه‌نویسی نیست؛ توی داشتن سلیقه‌ی محصولیه.

اگه بخوای از اسنپ‌پی درگاه پرداخت اقساطی بگیری، توی گایدلاین‌‌هاشون یه قانون دقیق هست درباره اینکه وقتی کاربر می‌خواد درگاه بانکی رو انتخاب کنه، لوگو، عنوان و توضیحات درگاه باید چطور باشه:

توضیحات باید زیر عنوان باشه، نه جلوش.

خیلی دقیق.

این فقط یه اتفاق نیست. این یه جور «پاتولوژی» یا بیماری رایج توی خیلی از تیم‌های محصوله.

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

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

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

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

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

پیکسل‌ها درست می‌شن، ولی محصول هنوز غلطه.

گفتگوی دوستانه مثل «هم‌نوایی» و «هم‌نوازی» می‌مونه.

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

اما در میدان کسب و کار و محصول، گفتگو مثل جراحیه.

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

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

مسائل سخت با ساده‌سازی‌های عجولانه حل نمی‌شن، بلکه با سرسختی در برابر پاسخ‌های راحت حل می‌شن.

هم‌نوایی برای دوستانه، سرسختی برای محصول.

تعدادش هر روز عوض می‌شه. بستگی داره کی داره تعریفش می‌کنه.

یه‌جا ۱۰ تا می‌گن، یه‌جا ۷ تا، یه‌جا هم ۵ تا. لیست‌ها بیشتر از اینکه کار کنند، بزرگ‌نمایی می‌کنند.

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

اما الان هر لیستی رو که باز کنی، تهش هست. انگار از همیشه اونجا بوده.

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

«کلیدی»، کوتاه‌ترین عمر رو داره.

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

اما یه چیز دیگه هم هست.

چیزهایی که تو هیچ نسخه‌ای از این لیست‌ها نمیان:

‌خود انتقادگری، تحمل ابهام یا «نه‌ گفتن» به یه ایده‌ی جذاب.

این‌ها قابل اندازه‌گیری نیستن، قابل تدریس هم نیستن، برای همین تو لیست جا نمی‌شن.

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

چیزی که جابه‌جا نمی‌شه، اونیه که از اول هیچ وقت تو لیست نبوده.

فعلا اینطوریه که باید بتونی دستور پیچیده یا دقیق‌تری بهش بدی (prompt).
باید یه چیزی کامنت کنی تا کاربلدها پرامپت رو برات تو دایرکت بفرستند.

برد در اینه که بگردی مدلی پیدا کنی که همه کاری ازش بر میاد (آچار فرانسه).

باور عمومی اینه که هر چی مدل بزرگ‌تر و گران‌تر باشه، نتیجه بهتره.

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

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

تخصص دیگه توی نوشتن پرامپت نیست؛ توی معماری انتخابه.

احتمالا بهترین دستیاران (agent) هم اونهایی هستند که از مدل‌های متعددی بهره می‌برن و توی سپردن هر کاری به مدل مناسبش دقیق‌تر عمل می‌کنن.