توهم سرعت: چرا وایب‌کدینگ UI-محور بدهی ساختاری عمیق را پنهان می‌کند

یک توسعه‌دهنده وارد Lovable می‌شود و می‌نویسد: «یک داشبورد تحلیلی زیبا با نمودارهای تعاملی بساز.» ده دقیقه بعد، یک داشبورد خیره‌کننده روی صفحه است. سه ماه بعد، همان تیم در حال بازنویسی کل backend است — چون داشبورد روی داده‌های hardcode شده ساخته شده، پایگاه داده برای نمایش نه ذخیره طراحی شده، و هیچ API که بتوان scale کرد وجود ندارد. به دام «توهم سرعت» خوش آمدید.

۱. وسوسه UI اول: چرا همه این کار را می‌کنند

وایب‌کدینگ UI-محور (UI-first) جذاب‌ترین رویکرد است چون نتیجه‌اش فوری و ملموس است. وقتی از ابزارهایی مثل Lovable، v0، یا Bolt.new استفاده می‌کنید، اولین چیزی که می‌بینید یک رابط کاربری زیبا است. این چند مزیت روانشناختی دارد:

• اثبات سریع ایده: می‌توانید به سرمایه‌گذار چیزی نشان دهید که «کار می‌کند»
• feedback فوری: در ده دقیقه می‌فهمید طراحی‌تان درست است یا نه
• انگیزه: دیدن نتیجه سریع توسعه‌دهنده را انرژی می‌دهد
• ارتباط با ذینفعان: UI قابل نمایش است — معماری پشت‌صحنه نیست

در واقع، UI-first در ابزارهای وایب‌کدینگ تبدیل به الگوی غالب شده. داده‌های Lovable نشان می‌دهد بیش از ۷۵٪ prompt‌های کاربران با توصیف ظاهر شروع می‌شوند: «یک صفحه زیبا برای...» یا «یک داشبورد که نشان دهد...».

اما این جذابیت ظاهری یک دام پنهان دارد. وقتی UI دیکته می‌کند که data چه شکلی باشد، کل معماری نرم‌افزار به دنبال نیازهای یک نمایش خاص می‌رود — نه به دنبال نیازهای واقعی کسب‌وکار.

۲. آناتومی یک MVP کاذب

بگذارید مثال واقعی‌تری ببینیم. فرض کنید از v0 می‌خواهید «یک اپلیکیشن مدیریت task با قابلیت drag-and-drop بسازد». در چند دقیقه یک UI زیبا دارید با:

• کانبان board با ستون‌های Todo، In Progress، Done
• کارت‌های قابل drag-and-drop
• رنگ‌بندی اولویت
• modal برای ایجاد task جدید

عالی به نظر می‌رسد. اما وقتی نگاه می‌کنید:

• task‌ها در یک آرایه JavaScript در component state هستند — هیچ backend نیست
• هر بار صفحه refresh شود، همه چیز از بین می‌رود
• ساختار داده کاملاً flat است: {"{"}id, title, status, priority{"}"}
• هیچ concept از user، team، یا project وجود ندارد
• چند نفر نمی‌توانند همزمان استفاده کنند

این یک MVP کاذب است — ظاهر MVP را دارد اما ساختار اصلی ندارد. تیم‌هایی که با این کد شروع می‌کنند و بعد «backend اضافه می‌کنند»، با یک مشکل اساسی روبه‌رو می‌شوند: ساختار داده UI آن‌قدر در code پیچیده شده که تغییر دادنش به یک بازنویسی کامل نیاز دارد.

«ما یک کلون Notion با v0 در ۳ روز ساختیم. سه ماه بعد مجبور شدیم کل backend را از اول بنویسیم چون ساختار داده‌ای که UI تعریف کرده بود با نیازهای واقعی collaboration کار نمی‌کرد.» — بنیان‌گذار استارتاپ SaaS، مصاحبه Indie Hackers، ۲۰۲۵

۳. بدهی ساختاری پنهان: هزینه‌های واقعی

بدهی ساختاری ناشی از UI-first چند شکل دارد:

۱. پایگاه داده denormalized:

وقتی UI یک صفحه خاص را نشان می‌دهد، ساده‌ترین پایگاه داده آن است که دقیقاً همان داده را ذخیره کند. نتیجه: جداول بسیار flat، تکرار داده، و وقتی نیاز به query متفاوت باشد، مشکلات جدی.

مثال: UI نشان می‌دهد «تعداد task‌های هر کاربر». پایگاه داده یک فیلد task_count در جدول user ذخیره می‌کند. وقتی می‌خواهید task‌های هر کاربر در هر پروژه را جداگانه بدانید، باید کل schema را عوض کنید.

۲. Props drilling جهنم:

UI component‌های زیادی ساخته می‌شوند که باید داده بین آن‌ها pass شود. چون معماری state management از اول طراحی نشده، داده از parent به child به grandchild منتقل می‌شود — props drilling که با بزرگ‌تر شدن اپ به یک کابوس تبدیل می‌شود.

۳. API endpoint‌های یک‌صفحه‌ای:

هر endpoint برای یک صفحه خاص طراحی می‌شود: /api/dashboard-data، /api/profile-page. این endpoint‌ها نمی‌توانند reuse شوند. وقتی UI تغییر می‌کند، API باید تغییر کند. وقتی mobile app اضافه می‌شود، نمی‌تواند از همان API استفاده کند.

۴. منطق کسب‌وکار در UI:

چون backend وجود ندارد یا ضعیف است، منطق مهم کسب‌وکار — مثل محاسبه قیمت، بررسی دسترسی، یا ارزیابی اعتبار — در component‌های UI پیاده‌سازی می‌شود. این منطق قابل تست نیست، قابل reuse نیست، و قابل امنیت‌سازی نیست.

۴. الگوی ضد آنتی‌پترن UI-محور

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

نشانه‌های هشداردهنده در کد:

• پایگاه داده schema‌ای که دقیقاً شبیه ساختار UI است — نه ساختار کسب‌وکار
• API endpoint‌هایی با نام‌هایی مثل getHomepageData یا getDashboardStats
• منطق کسب‌وکار پیچیده در React component
• فقدان مدل دامنه — هیچ entity مرکزی مثل User، Order، Product در core وجود ندارد
• تست‌هایی که فقط ظاهر را تست می‌کنند، نه رفتار

نشانه‌های هشداردهنده در فرآیند:

• اولین چیزی که به ذینفعان نشان می‌دهید screenshot است، نه spec
• data model را «بعداً» تعریف می‌کنید
• وقتی یک feature جدید می‌خواهید، اول UI آن را در ذهن می‌بینید
• تیم backend از تصمیمات UI آگاه نیست تا وقتی که دیر شده

«در Domain-Driven Design، UI آخرین لایه‌ای است که طراحی می‌شود — نه اولین. UI باید زبان دامنه را بیان کند، نه دامنه را شکل دهد.» — Eric Evans، Domain-Driven Design، ویرایش دوم ۲۰۲۴

۵. رویکرد صحیح: دامنه اول، UI بعد

رویکرد درست برعکس UI-first است: Domain-First Design — طراحی از دامنه کسب‌وکار به سمت UI.

مرحله ۱ — تعریف دامنه (Domain Model):

قبل از هر کدی، entity‌های اصلی کسب‌وکار را تعریف کنید:

• چه موجودیت‌هایی وجود دارند؟ (User، Task، Project، Team)
• هر موجودیت چه خصوصیاتی دارد؟
• روابط بین موجودیت‌ها چیست؟
• قوانین کسب‌وکار چه هستند؟ (یک User می‌تواند چند Team داشته باشد؟ یک Task می‌تواند بدون Project باشد؟)

مرحله ۲ — طراحی API Contract:

بر اساس دامنه، یک API contract بنویسید — قبل از اینکه هر خط کد بنویسید:

• resource‌های RESTful یا mutation‌های GraphQL را تعریف کنید
• request/response schema را مستند کنید
• error case‌ها را صریحاً تعریف کنید
• authentication و authorization rules را مشخص کنید

مرحله ۳ — UI که از API مصرف می‌کند:

حالا UI را بسازید — اما با یک قانون مهم: UI فقط اطلاعاتی را نشان می‌دهد که از API می‌آید. هیچ داده hardcode نه. هیچ منطق کسب‌وکار در component نه.

۶. چطور با AI مدل دامنه را بسازیم

خبر خوب این است که هوش مصنوعی در طراحی Domain Model هم عالی عمل می‌کند — اگر prompt درست باشد. به جای:

«یک اپلیکیشن مدیریت task بساز»

بنویسید:

«می‌خواهم یک اپلیکیشن مدیریت task بسازم. قبل از هر کدی، مدل دامنه را طراحی کن: entity‌های اصلی، خصوصیات، روابط، و قوانین کسب‌وکار را به صورت متن ساختاریافته تعریف کن. سپس یک API contract کامل با OpenAPI spec بنویس. فقط بعد از تأیید من روی API contract، شروع به پیاده‌سازی کن.»

این prompt چند تفاوت مهم دارد:

• صریحاً خواسته که قبل از کد، طراحی باشد
• هوش مصنوعی را موظف به تولید artifact‌های مستند (API spec) کرده
• یک checkpoint تأیید انسانی قبل از شروع پیاده‌سازی تعریف کرده
• ترتیب کار را مشخص کرده: دامنه → API → پیاده‌سازی

وقتی هوش مصنوعی ابتدا domain model را طراحی می‌کند، چند اتفاق مثبت می‌افتد: سؤال‌های خوب می‌پرسد («آیا یک Task می‌تواند به چند Project تعلق داشته باشد؟»)، inconsistency‌هایی را که شما ندیده‌اید پیدا می‌کند، و در نهایت کدی می‌نویسد که با نیازهای واقعی هماهنگ است نه با ظاهر اولیه.

الگوی ADR (Architecture Decision Record):

از هوش مصنوعی بخواهید برای هر تصمیم مهم معماری یک ADR کوتاه بنویسد:

• تصمیم چیست؟
• چرا این تصمیم گرفته شد؟
• گزینه‌های دیگر چه بودند و چرا رد شدند؟
• پیامدها و trade-off‌ها چیستند؟

این ADRها همان «چرایی» هستند که در وایب‌کدینگ معمولاً از دست می‌رود — و همان چیزی که مهندس جدید برای فهمیدن سیستم نیاز دارد.

مقایسه رویکرد UI-اول در برابر دامنه-اول

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

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

نتیجه‌گیری: سرعت واقعی در طراحی درست است

توهم سرعت در وایب‌کدینگ UI-محور این است: «در ۲ ساعت MVP آماده است.» واقعیت این است: «در ۲ ساعت یک دمو آماده است که ۳ ماه بعد باید بازنویسی شود.»

سرعت واقعی در طراحی درست نهفته است. یک هفته صرف تعریف domain model و API contract کردن، می‌تواند ماه‌ها از بازنویسی معماری را صرفه‌جویی کند. این سرمایه‌گذاری به نظر می‌رسد «آهسته» است — اما در افق ۶ ماه، سریع‌ترین مسیر به یک محصول پایدار است.

هوش مصنوعی این تغییر رویکرد را تسریع می‌کند، نه مانع آن. یک prompt خوب که با دامنه شروع می‌کند، چند برابر بهتر از هزار prompt که با UI شروع می‌کند نتیجه می‌دهد. کلید این است که از هوش مصنوعی بخواهیم ابتدا فکر کند، سپس بسازد — نه برعکس.