تصور کنید تمام جزئیات بصری یک محصول را با دقت میلی‌متری به یک طراح دیکته کنید و در نهایت با محصولی مواجه شوید که هیچ‌کس نمی‌داند چطور از آن استفاده کند. این دقیقاً همان تله‌ای است که مهندسی بیش از حد پرامپت‌ها ایجاد می‌کند.
بر اساس گزارش یک توسعه‌دهنده در ۲۰ ژوئیه ۲۰۲۶، آزمایش روی دو ابزار Lovable و Bolt نشان داد که ارائه یک سند تحویل (handoff document) بسیار دقیق، می‌تواند کاربرد محصول را نابود کند. توسعه‌دهنده برای هر دو ابزار، یک سند تحویل یکسان و بسیار مفصل برای ساخت یک ابزار میزبانی فرمول یک تهیه کرد. هدف این ابزار، مدیریت مهمانان VIP، دسترسی به پادوک (paddock access) و برنامه‌های سفر ۳ روزه برای صنعتی بود که تنها از بلیت‌های Paddock Club سالانه بیش از ۴۵۰ میلیون دلار درآمد دارد. برای درک اهمیت این موضوع، باید دانست که در فصل گذشته ۶۵,۰۰۰ مهمان با پرداخت تقریباً ۷,۰۰۰ دلار برای هر بلیت حضور داشتند و درآمد این بخش سالانه ۱۰ درصد رشد می‌کند؛ بنابراین، ریسک‌های مربوط به هماهنگی و مدیریت در این سطح بسیار بالاست. این چالش مدیریت رویدادهای عظیم، مشابه نیازهایی است که در بهره‌گیری از استدلال Gemini برای مدیریت تجمعات در جام جهانی بررسی کردیم.
بسیاری تصور می‌کنند جزئیات بیشتر یعنی نتیجه بهتر. اما این تجربه ثابت کرد که تعیین دقیق توکن‌های بصری (Visual Tokens) — مثل کدهای رنگی دقیق (Hex Codes) و فونت‌های خاص — فضای تصمیم‌گیری هوش مصنوعی را می‌بندد. در واقع، مدل‌ها به‌جای به‌کارگیری قضاوت معماری، صرفاً رنگ‌های درخواستی را روی یک قالب آماده و تکراری از یک پنل مدیریتی (admin panel) «رنگ کردند».
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی محدودیت‌های مدل‌های مولد اشاره کردیم، تضاد بین «اجرای دستور» و «درک هدف» همچنان یک چالش اساسی است.
جزئیات فرآیند آزمایش
توسعه‌دهنده تنها به نگاه کردن به پیش‌نمایش‌ها اکتفا نکرد. او برای بررسی دقیق، از یک مرورگر بدون رابط کاربری (headless browser) استفاده کرد تا وارد هر دو پلتفرم شود و تک‌تک صفحات را کلیک کند. این بررسی‌ها شامل موارد زیر بود:
- داشبورد اصلی و لیست‌های مهمانان
- ابزار برنامه‌ریز سفر (itinerary builder) و جریان اشتراک‌گذاری
- صفحه عمومی که برای مهمانان نمایش داده می‌شود
- حالت‌های خاص (Edge Cases) مانند لینک‌های نامعتبر
داستان دو شکست متفاوت
نتایج این رویارویی، داستان دو نوع شکست متفاوت بود. Lovable شبیه به یک مهندس مطیع عمل کرد. این ابزار تقویم موجود در سند را دقیقاً طبق دستور اجرا کرد، تاریخ‌های صحیح مسابقات از ژوئن به بعد و دور جدید مادرید را به‌درستی درج نمود. همچنین پیاده‌سازی وارد کردن فایل‌های CSV، مدل‌های داده و نشان‌های سطح دسترسی (access-tier badges) را دقیقاً همان‌طور که خواسته شده بود، اجرا کرد. او حتی بخش ارسال ایمیل را طبق مشخصات سند به‌صورت Stub (ساختار اولیه) پیاده کرد. اما در هدف اصلی شکست خورد: جریان زمان‌بندی مهمانان پشت یک برچسب خاکستری تقریباً نامرئی با اندازه ۲ پیکسل و متن «۰ تخصیص یافته» مخفی شده بود. هیچ راهنمایی یا وضعیت «صفحه خالی» (empty state) وجود نداشت و همین امر باعث شد ویژگی اصلی محصول عملاً غیرقابل پیدا کردن باشد. این نوع نقص‌های کاربردی که در لایه‌ی کد پنهان هستند، ما را به یاد پروژه Loupe و شناسایی باگ‌های خاموش در کدهای تولیدشده با AI می‌اندازد.
در مقابل، Bolt غریزه‌ی محصول بهتری داشت اما نظم را به کل فراموش کرد. این ابزار یک سیستم بصری و کاربرپسند بر پایه «چیپ‌ها» (chip-based system) برای تخصیص مستقیم مهمانان به آیتم‌های سفر در داخل فرم طراحی کرد. تایپوگرافی آرام‌تر بود و به‌جای استفاده از حروف تماماً بزرگ (ALL CAPS)، از حالت Title Case استفاده کرد. همچنین لینک‌های مهمانان به‌جای اینکه پشت دکمه‌ها مخفی شوند، به‌صورت متن ساده نمایش داده شدند. با این حال، Bolt داده‌های مرجع را نادیده گرفت و تقویم خودش را اختراع کرد؛ برای مثال، بحرین را به عنوان دور اول لیست کرد و مسابقاتی را گنجاند که در جدول زمانی فعلی حضور نداشتند؛ اشتباهی که اعتبار محصول را در مقابل مخاطبان سخت‌گیر فرمول یک فوراً نابود می‌کند.
شکاف معماری
شکاف معماری در اینجا نهفته است. چون دستورات بصری بسیار سخت‌گیرانه بود — شامل پس‌زمینه‌های تقریباً سیاه، گوشه‌های تیز و فونت Space Grotesk — هر دو ابزار به یک استتیک «حالت تاریک» (dark mode) یکسان پناه بردند. هر دو از رنگ قرمز نئونی روی پس‌زمینه تقریباً سیاه با شبکه‌ای تخت از کارت‌های مشابه و بدون هیچ تصویری استفاده کردند. با وجود اینکه مرورگر بدون رابط کاربری هیچ ترجیحی برای حالت تاریک تنظیم نکرده بود، هیچ‌کدام از ابزارها گزینه حالت روشن (light mode) را ارائه ندادند.
طراحی واقعی یعنی تصمیم‌گیری درباره‌ی سلسله‌مراتب، تأکید و تصمیم‌گیری در مورد اینکه چه چیزهایی باید حذف شوند، نه فقط انتخاب کدهای رنگی. با تعریف بیش از حد «ظاهر»، توسعه‌دهنده به‌طور غیرمستقیم توانایی هوش مصنوعی در تصمیم‌گیری درباره‌ی چیدمان و قابلیت کشف (discoverability) را گرفت. نتیجه شد دو محصول: یکی که واقعیت‌ها را می‌دانست اما نمی‌توانست کاربر را هدایت کند، و دیگری که می‌توانست کاربر را هدایت کند اما درباره‌ی واقعیت‌ها دروغ می‌گفت. برای رسیدن به دقت داده‌ای در کنار انعطاف‌پذیری، می‌توان از ترکیب استنتاج قطعی و هوش مصنوعی بهره برد تا از خطاهای فکت‌بندی جلوگیری شود.
برای اصلاح این وضعیت، ابزار با حذف محدودیت‌های سخت‌گیرانه بصری بازطراحی شد. در نسخه جدید:
- طراحی پیش‌فرض روشن شد (حالت تاریک به یک انتخاب تبدیل گشت، نه یک قفس).
- رویکردی تحریری و تصویرمحور با استفاده از عکس‌های واقعی پیست‌ها برای انتقال احساسات به کار رفت.
- فونت Inter برای کارهای خواندنی و آرام جایگزین Space Grotesk شد که بیشتر برای نمایش شخصیت (Character) بود.
- رنگ قرمز به‌جای پوشاندن کل صفحه، فقط به‌صورت محدود و به عنوان رنگ تأکیدی (accent) استفاده شد.
- جریان تخصیص کاربرپسند و مبتنی بر چیپ‌ها که از مدل Bolt الگوبرداری شده بود، جایگزین شد.
این تغییر نشان‌دهنده‌ی یک تنش حیاتی در توسعه با هوش مصنوعی است: مرز بین ارائه جهت‌دهی کافی و تصاحب تصادفیِ تنها تصمیماتی که یک طراح انسانی باید بگیرد. وقتی بیش از حد بر «چگونه» تمرکز می‌کنید، اغلب «چرا»ی تجربه کاربری را فدا می‌کنید.
گام بعدی شما
- در پرامپت‌های طراحی، به‌جای تعیین کد رنگ و فونت، «هدف احساسی» و «نقش کاربر» را توصیف کنید.
- از مدل‌های مختلف برای استخراج «منطق جریان کاری» (Workflow) و «دقت داده‌ای» به‌صورت مجزا استفاده کنید و سپس آن‌ها را ترکیب کنید.
- ابتدا اجازه دهید هوش مصنوعی یک پیش‌نویس معماری ارائه دهد و سپس در مراحل تکمیلی، محدودیت‌های بصری را اعمال کنید.
اما تأثیر این رویکرد بر سرعت توسعه در مقیاس تجاری حتی پیچیده‌تر است — به بررسی ما درباره‌ی ابزارهای Vibe Coding مراجعه کنید.
گفتگو