اگر با کمک عامل‌هایی مثل Cursor اپلیکیشن‌های پیچیده می‌سازید، احتمالاً در لحظه انتقال از محیط محلی به تولید با یک دیوار بلند برخورد خواهید کرد. شکاف بین «روی سیستم من کار می‌کند» و داشتن یک URL فعال در حال گسترش است؛ زیرا هوش مصنوعی ساختارهای چندسرویسی پیچیده‌ای می‌سازد که پلتفرم‌های میزبانی سنتی برای درک آن‌ها طراحی نشده‌اند.
این چالش هسته اصلی پدیده «وایب-کدینگ» (Vibe-coding) است؛ رویکردی که در آن برنامه‌نویسان از مدل‌های زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — برای سرهم کردن سریع اپلیکیشن‌هایی با وابستگی‌های متنوع استفاده می‌کنند. برای تست این موضوع، یک توسعه‌دهنده اپلیکیشنی کامل ساخت تا ببیند پلتفرم‌های مختلف چگونه با کدهای تولیدشده توسط AI برخورد می‌کنند. این یک صفحه ساده، یک برنامه لیست کارهای روزانه (Todo app) یا یک دموی تمیز با یک فریم‌ورک و یک متغیر محیطی نبود. این پروژه دقیقاً برای شبیه‌سازی چیزی طراحی شد که مردم پس از گذراندن چند شب با Cursor، Claude یا ChatGPT می‌سازند: یک اپلیکیشن با ابعاد یک محصول واقعی که دارای سیستم احراز هویت، پایگاه داده، پردازش‌های پس‌زمینه و APIهای شخص ثالث است.
اپلیکیشن مورد آزمایش: VibeSplit
نتیجه این تلاش، اپلیکیشنی به نام VibeSplit بود؛ ابزاری برای تقسیم هزینه‌های گروهی با قابلیت اسکن رسیدها توسط AI. این برنامه به کاربران اجازه می‌دهد رسیدها را آپلود کنند، آن‌ها را با AI تحلیل کنند، هزینه‌ها را تقسیم کرده، تراز حساب‌ها را ردیابی کنند، افراد دیگر را دعوت نمایند و در نهایت تسویه حساب کنند. طبق گزارش نویسنده، این اپلیکیشن دقیقاً از آن دسته برنامه‌هایی است که با یک دستیار کدنویسی AI ساختنش آسان به نظر می‌رسد، اما وقتی باید در یک محیط واقعی اجرا شود، بسیار دشوار می‌شود.
برای شبیه‌سازی یک استک (Stack) واقعی تولیدشده توسط AI، از فناوری‌های زیر استفاده شد:
- Next.js 15 با App Router و TypeScript
- Prisma به همراه PostgreSQL
- Supabase Auth برای لینک‌های جادویی (Magic links) و ورود با گوگل
- Inngest برای مدیریت کارهای پس‌زمینه (Background jobs)
- OpenAI Vision برای تحلیل و استخراج داده از رسیدها
- Stripe برای پرداخت‌های تسویه حساب
- Resend برای ارسال ایمیل‌های اپلیکیشن
بر اساس مستندات این آزمایش، این ترکیب خاص دقیقاً بخش‌های «نامنظم» و پیچیده استقرار را آشکار می‌کند که اپلیکیشن‌های ساده پنهان می‌کنند. در حالی که یک فرانت‌اند استاتیک می‌تواند تقریباً هر پلتفرمی را خوب جلوه دهد، VibeSplit به یک پایگاه داده واقعی، اسرار (Secrets) واقعی، URLهای بازگشتی OAuth، URLهای وب‌هوک (Webhook)، مهاجرت‌های دیتابیس (Migrations) و متغیرهای محیطی عمومی در زمان ساخت نیاز داشت.
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی چالش‌های زیرساختی ابزارهای No-code و AI-driven اشاره کردیم، مشکل اصلی همواره تبدیل «ایده» به «زیرساخت پایدار» است.
رویارویی پلتفرم‌ها
Railway در ابتدا پروژه را به عنوان یک اپلیکیشن Node/Next شناسایی کرد اما در ابتدایی‌ترین مراحل شکست خورد. طبق گزارش منتشر شده، استقرار ابتدا با خطای ۵۰۲ مواجه شد چون پلتفرم و اپلیکیشن روی شماره پورت توافق نداشتند. حتی پس از رفع این مشکل، Railway با وجود وجود طرح‌واره (Schema) در Prisma، پایگاه داده PostgreSQL مورد نیاز را به‌طور خودکار ایجاد نکرد. این موضوع توسعه‌دهنده را مجبور کرد تا به‌صورت دستی متغیر DATABASE_URL را متصل کند، مهاجرت‌های Prisma را مدیریت کند و بررسی کند که آیا محیط زمان اجرا (Runtime) با انتظارات اپلیکیشن مطابقت دارد یا خیر. تجربه کاربر از «استقرار مخزن کد من» به «عیب‌یابی هم‌زمان پیکربندی پلتفرم، مفروضات اپلیکیشن و سیم‌کشی سرویس‌ها» تغییر کرد.
Vercel فرآیند ساخت فرانت‌اند را بی‌نقص انجام داد که با توجه به بهینه‌سازی آن برای Next.js قابل پیش‌بینی بود. اما سایت فعال بلافاصله خطای ۵۰۰ (Internal Server Error) داد. مشکل اینجا بود که صرفاً وجود یک Build موفق برای فرانت‌اند کافی نبود؛ اپلیکیشن به دیتابیس، Prisma، مهاجرت‌ها، مقادیر Supabase، مسیرهای API، Server Actions و چندین Secret شخص ثالث نیاز داشت. نویسنده اشاره می‌کند که در Vercel، موفقیت در مرحله Build می‌تواند فریبنده باشد؛ یعنی Build پاس می‌شود و یک URL ایجاد می‌گردد، اما اولین جریان کاربر (User flow) واقعی فاش می‌کند که پلتفرم نتوانسته شکل کامل بک‌اند اپلیکیشن را استنتاج کند.
Jetpacked روان‌ترین تجربه را ارائه داد زیرا با پروژه نه فقط به عنوان یک فرانت‌اند Next.js، بلکه به عنوان یک استقرار کامل (Full-stack) برخورد کرد. این پلتفرم به‌طور خودکار نیاز به Postgres و تنظیمات Prisma را شناسایی کرد. به‌جای اینکه کاربر را مجبور کند ابتدا زیرساخت را بسازد، Jetpacked مخزن کد را خواند، استک را درک کرد و صرفاً مقادیری را درخواست کرد که قابل استنتاج نبودند. استقرار در این پلتفرم با کمترین اصطکاک نسبت به دو مورد دیگر تکمیل شد، زیرا پلتفرم متوجه شد که پایگاه داده بخشی از ساختار کلی اپلیکیشن است.
تله‌های پنهان در استقرار
با وجود برتری Jetpacked، این تست سه مشکل بحرانی را شناسایی کرد که هیچ ارائه‌دهنده‌ی میزبانی فعلی به‌طور کامل آن‌ها را حل نکرده است:
- متغیرهای زمان ساخت در برابر زمان اجرا: در Next.js، متغیرهای عمومی مانند
NEXT_PUBLIC_SUPABASE_URLباید در زمان Build در بسته مرورگر (Browser Bundle) جای‌گذاری شوند. اگر پلتفرمی متغیرها را فقط هنگام شروع کانتینر تزریق کند، بک‌اند ممکن است درست کار کند، اما فرانت‌اند به‌طور بی‌صدا با مقادیر جایگزین (Placeholder) از فایل.env.exampleارسال می‌شود. این یک مشکل ظریف در محیط تولید است که در آن کانتینر محیط زمان اجرای صحیح را دارد، اما مرورگر کدی را اجرا می‌کند که با مقدار اشتباه ساخته شده است. - پیکربندی ارائه‌دهندگان خارجی: برای Supabase Auth، یک دسته مجزا از کارها وجود داشت. متغیرهای محیطی اپلیکیشن را به پروژه درست هدایت می‌کردند، اما خودِ Supabase به پیکربندی URL تولید نیاز داشت. ارائه‌دهنده گوگل باید فعال می‌شد، URL بازگشتی (Callback) استقرار شده باید اضافه می‌شد و URL سایت باید از اشاره به localhost دست می‌کشید. هیچ‌کدام از این موارد در مخزن کد اپلیکیشن نیستند و هیچ پلتفرم میزبانی نمی‌تواند آن‌ها را به‌طور کامل از روی کد استنتاج کند.
- یکپارچگی سرویس‌ها: سرویس Stripe به URLهای بازگشتی نیاز دارد که به اپلیکیشن فعال اشاره کنند و Inngest برای کارهای پس‌زمینه به یک Endpoint قابل دسترس نیاز دارد. این وابستگی‌ها به این معناست که استقرار تنها درباره سرور نیست، بلکه درباره پیکربندی ارائه‌دهندگان خارجی است تا URL تولید جدید را به رسمیت بشناسند.
درس‌های نهایی برای وایب-کودرها
این آزمایش ثابت می‌کند که شناسایی نام یک فریم‌ورک مانند 'Next.js' دیگر کافی نیست. برای اپلیکیشن‌های تولیدشده توسط AI، «شکل استقرار» در واقع یک ترکیب است: Next.js به علاوه Prisma به علاوه Postgres به علاوه مهاجرت‌ها به علاوه Supabase به علاوه کارهای پس‌زمینه به علاوه متغیرهای محیطی عمومی زمان ساخت به علاوه اسرار مخصوص سرور.
برای توسعه‌دهنده، این بدان معناست که جریان کاری «وایب-کدینگ» در حال حاضر توسط زیرساخت محدود شده است. در حالی که AI می‌تواند کد یک سیستم پیچیده را در چند دقیقه بنویسد، بازسازی دستی آن معماری در یک داشبورد ابری همچنان یک نقطه اصطکاک بزرگ است. استاندارد پلتفرم‌های استقرار باید از «آیا می‌تواند یک اپلیکیشن Next.js بسازد؟» به «آیا می‌تواند آن چیز پیچیده و سرویس-محور را که کسی واقعاً ساخته است، درک کند؟» تغییر کند.
اگر در حال انتقال یک پروژه تولیدشده توسط AI به محیط تولید هستید، ابتدا متغیرهای محیطی خود را برای نیازهای زمان ساخت (Build-time) بازبینی کنید و URLهای بازگشتی OAuth را در داشبورد ارائه‌دهنده خود دوباره چک کنید.
گام بعدی شما
- اگر پروژه‌ای را با AI ساخته‌اید، پیش از استقرار، لیستی از تمام متغیرهای محیطی (Env Vars) را تهیه کنید و تفکیک کنید کدام‌ها در زمان Build نیاز هستند.
- URLهای بازگشتی (Redirect URLs) را در پنل‌های مدیریت OAuth (مثل گوگل یا گیت‌هاب) به‌روز کنید تا با دامنه جدید تطابق داشته باشند.
- برای پروژه‌های Full-stack پیچیده، پلتفرم‌هایی را امتحان کنید که قابلیت شناسایی خودکار دیتابیس (مانند Jetpacked) را دارند.
اما این تنها بخشی از چالش است؛ برای درک اینکه چگونه هزینه استنتاج در مقیاس بالا می‌تواند سودآوری این اپلیکیشن‌ها را نابود کند، تحلیل ما درباره مدل‌های هزینه GPU را بخوانید.
گفتگو