درسهای غیرمنتظره از یه آزمایش پروتوتایپ با کمک هوش مصنوعی
هوش مصنوعیخلاصهٔ کاملتر
به گفتهٔ نویسنده که طراح تیم Adobe Firefly ـه، ساختن محصول برای سالها یه ریتم آشنا داشته: تحقیق، تعریف، اکتشاف، نوشتن اسپک و تحویل به تیم بعدی. ولی به مرور دیده که هر بار ایده از دل اسپکها، ماکهای ثابت و جلسههای بازبینی رد میشه، امکان فاصلهگرفتن از نیت اولیهٔ طراحی بیشتر میشه و تیم مجبور میشه بین سرعت، کیفیت و یادگیری یکی رو انتخاب کنه.
برای همین، تو یه پاد آزمایشی کوچیک و عمداً میانرشتهای (یه مدیر محصول، سه مهندس و خود نویسنده) سراغ یه سؤال ساده رفتن: اگه با کمک هوش مصنوعی مستقیم داخل کدبیس محصول پروتوتایپ بسازیم چی میشه؟ اونا از قبل میدونستن vibe coding برای اکتشاف اولیه خوبه، ولی میخواستن ببینن یه حلقهٔ نزدیک و مشترک بین طراحی، مهندسی و محصول زیر فشار واقعی محصول دووم میاره یا نه.
بهجای اینکه پیادهسازی رو به مرحلهٔ آخر موکول کنن، از همون اول جزئی از فرایند طراحی حسابش کردن. با یه سری نیازمندی کوتاه محصول شروع کردن و سریع وارد چرخهٔ «طراحی-ساخت-بازخورد» شدن؛ نویسنده با ابزارهای کدنویسی هوش مصنوعی، تیکهتیکه بخشهای تجربه رو روی کدبیس Firefly بالا میآورد و بعد از بازبینی مهندسی، تغییرها تو شاخهٔ اصلی merge و برای بازخورد به اشتراک گذاشته میشد. نتیجه: تو فقط ۸ روز کاری، دو قابلیت به یه بیلد production اضافه شد.
به گفتهٔ نویسنده، سرعت تیتر واضح ماجراست، ولی چیزی که بیشتر غافلگیرش کرد «نزدیکی» بود. وقتی فاصلهٔ بین ایده و پیادهسازی کم میشه، تصمیمهای طراحی وقتی محصول هنوز داره شکل میگیره بهش جهت میدن، محدودیتها همون موقع که پیدا میشن حل میشن نه هفتهها بعد، و مهندسها بهجای رفتار حدسی به پیادهسازی واقعی واکنش نشون میدن. طراحی داخل خود اپ هم ظرافتهایی مثل زمانبندی، حرکت و حالتها رو نشون میداد که ماک ثابت نمیگیره.
این کار نحوهٔ گذروندن وقت نویسنده رو هم عوض کرد. قبلاً یه قابلیت به دهها اسکرین و توضیح دقیق تو Figma نیاز داشت، ولی حالا از Figma گزینشیتر برای همفکری و اسکچ اولیه استفاده میکرد؛ بعد از توافق روی جهت کلی، بیست دقیقه تا یه ساعت چند اسکرین کلیدی میکشید تا فقط نیت تعامل رو توضیح بده، بیاینکه هر حالت مرزی رو از اول پیشبینی کنه. بقیهٔ وقتش صرف ساختن مستقیم تجربه با ابزارهای AI میشد.
مهمترین حرف نویسنده اینه که هیچکدوم از اینها بهخاطر ابزارها جواب نداد. یه تصور رایج اینه که vibe coding نیاز به همکاری رو کم میکنه، ولی به گفتهٔ او دقیقاً برعکسه: نزدیکشدن به فرایند ساخت، وابستگیش به مهندسی و محصول رو بیشتر کرد. مهندسی پایداری production، کیفیت تجربه و زیرساخت و گاردریلها رو تضمین کرد و محصول هم مسئلهٔ درست رو نامگذاری و اولویتها رو هماهنگ کرد.
شکل همکاری هم از «تحویلدادن» به «همپوشانی» تغییر کرد؛ چون کار زودتر ملموس میشد، تیم میتونست همون موقع که تصمیمها هنوز منعطف بودن سؤالها رو مطرح و محدودیتها رو حل کنه. جمعبندی نویسنده اینه که اصول بنیادین طراحی — همدلی، قضاوت، سلیقه و مهارت — با vibe coding از بین نمیرن، بلکه مهمتر میشن؛ و این وقتی بهترین نتیجه رو میده که هیچکس تنها کار نکنه.
نکات کلیدی:
- یه پاد کوچیک تو Adobe Firefly با vibe coding مستقیم داخل کدبیس، تو ۸ روز کاری دو قابلیت به production رسوند.
- ارزش اصلی سرعت نبود، بلکه نزدیکشدن ایده به پیادهسازی و بازخورد زودتر و واقعیتر بود.
- طراحی داخل خود اپ، ظرافتهایی مثل زمانبندی، حرکت، حالتها و دسترسپذیری رو زودتر آشکار کرد.
- سهم Figma کمتر و گزینشیتر شد و بیشتر وقت صرف ساختن مستقیم تجربه شد.
- برخلاف تصور رایج، vibe coding همکاری رو کم نکرد بلکه شدیدترش کرد و اصول بنیادین طراحی سر جاشون موندن.
