تصور کنید یک بنیانگذار استارتاپ است که میتواند یک محصول کامل را در ۴۸ ساعت راهاندازی کند، اما در ماه چهارم متوجه شود که هیچکس در تیم نمیتواند حتی یک خط از کدهای سیستم را تغییر دهد بدون اینکه کل برنامه فرو بریزد.
این کابوس همان توقف ناگهانی پروژههایی است که با روش Vibe Coding (کدنویسی بر اساس حس) ساخته شدهاند؛ یعنی توصیف محصول با زبان ساده و سپردن کامل پیادهسازی به هوش مصنوعی. طبق گزارش Studio Labs، این رویکرد شکافی عمیق بین یک «دموی خیرهکننده» و یک «محصول آماده بهرهبرداری» ایجاد میکند.
این روند با گسترش استفاده از عاملهای (Agents) — برنامههای هوشمندی که مثل کارمندانی خودکار، کارهای پیچیده را مدیریت میکنند — شتاب گرفته است. برای نمونه، پلتفرم Vibe Arcade ادعا میکند مجموعهای از بازیها را بدون نوشتن حتی یک خط کد ساخته است. اما طبق بررسیهای صورت گرفته تا ۱۰ ژوئیه ۲۰۲۶، الگوی تکراری عجیبی دیده میشود: محصولاتی که در مرحله «حس» بسیار بصری و جذاباند، به محض مواجهه با مشتریان واقعی، متوقف میشوند.
همانطور که در تحلیلهای پیشین ما دربارهی بدهی فنی در عصر AI اشاره کردیم، سرعت تولید کد نباید با کیفیت معماری اشتباه گرفته شود. شکست فنی این روش در سه مرحله رخ میدهد:
- مکانیابی باگ: تولید سریع کد توسط AI باعث میشود خطاهای حیاتی در نقاطی پنهان شوند که برنامهنویسان انسانی هرگز آنها را پیدا نمیکنند.
- تورم ویژگیها: افزودن یک قابلیت جدید اغلب باعث میشود نیمی از کدهای قبلی بهدلیل نبود ساختار، نیاز به بازنویسی کامل داشته باشند. این چالش نبودِ ساختار سیستماتیک در مقیاس بالا است که پیشتر در تجربیات توسعهدهندگان ژاپنی هنگام استقرار مدلهای Fabric را مشاهده کردیم.
- از دست رفتن زمینه: پس از چند هفته، عامل هوشمند کنترل معماری خودش را از دست میدهد و نتیجه، مهاجرتهای شکستخورده و کدهای غیرقابلفهم است.
این وضعیت ثابت میکند که سرعت نوشتن کد هرگز گلوگاه اصلی توسعه نرمافزار نبوده است. چالش واقعی همچنان مدلسازی دامنه و تصمیمگیری درباره این است که چه چیزی مقیاسپذیر است و چه چیزی تبدیل به «بدهی فنی» میشود. وقتی یک مدیر تصور میکند نسخههای بعدی مدلها بهصورت خودکار این نقصهای معماری را اصلاح میکنند، در واقع سختترین بخش مهندسی — یعنی درک مسئله — را نادیده گرفته است.
برای شما به عنوان توسعهدهنده یا مدیر محصول، این یعنی پروژهی «ساختهشده با AI» شما احتمالاً در ماه چهارم به یک سقف سخت برخورد میکند. بهجای پریدن مستقیم به سراغ پرامپتها، ابتدا باید مدل دامنه و معماری را طراحی کنید و سپس اجرای آن را به عامل بسپارید.
گام بعدی شما
- پیش از درخواست کد، روابط دادهها و محدودیتهای سیستم را بهصورت مستند بنویسید.
- معماری کلی پروژه را در یک فایل متنی مجزا نگه دارید تا عامل هوشمند در مراحل بعدی «زمینه» را گم نکند.
- هر ویژگی جدید را با بررسی اثرش بر ساختار کلی کد، نه فقط روی خروجی نهایی، تست کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو