از وایب کدینگ تا توسعه مبتنی بر Spec: قدرت یه Spec خوب
تغییر مسیر در توسعه با کمک AI
از وقتی دستیارهای AI برای کدنویسی جدیتر وارد کار شدن، خیلی از ما به یه مدل کاری جدید عادت کردیم که معمولاً بهش میگن Vibe Coding.
یعنی چی؟ خیلی ساده: چیزی که میخوای رو با زبان خودت به AI میگی، کد تحویل میگیری، اجراش میکنی و بعد بر اساس چیزی که میبینی، درخواست بعدی رو میدی.
برای ساخت نمونه اولیه، تست کردن ایدهها و پروژههای کوچیک، این روش واقعاً جذابه. مثلاً مینویسی: «یه صفحه لاگین برام بساز» و چند ثانیه بعد، یه نقطه شروع قابلاستفاده داری.
اما وقتی همین مدل آزاد و بدون ساختار رو برای ساختن یه محصول واقعی ادامه بدیم، کمکم دردسرها شروع میشن.
مشکل اینه که پرامپتهای مبهم، کلی تصمیم مهم رو باز میذارن. اونوقت AI خودش باید تصمیم بگیره از چه کتابخونهای استفاده کنه، ساختار پروژه چطور باشه، احراز هویت چطور پیادهسازی بشه یا دادهها چه مسیری رو طی کنن.
ممکنه برای یه فیچر عالی جواب بده، اما وقتی چند هفته بعد سراغ فیچر بعدی میری، مدل یه تصمیم متفاوت میگیره. کمکم پروژهات پر میشه از الگوهای ناهماهنگ، وابستگیهای اضافی و تصمیمهایی که کسی دقیقاً نمیدونه چرا گرفته شدن.
این به معنی بد بودن کدنویسی با AI نیست. فقط یعنی AI برای اینکه خروجی خوبی بده، به زمینه (Context) و محدودیتهای درست نیاز داره.
اینجاست که Spec-Driven Development یا همون توسعه مبتنی بر Spec مهم میشه.
از پرامپتنویسی تا Context Engineering
ایده اصلی SDD سادهست: قبل از اینکه شروع کنیم به نوشتن کد، مشخص میکنیم دقیقاً چی میخوایم بسازیم و چه محدودیتهایی داریم.
به جای اینکه کد، جایی باشه که تصمیمها وسط راه توش شکل میگیرن، اول یه Spec مینویسیم که هدف، ساختار، ابزارها و رفتار مورد انتظار سیستم رو روشن میکنه.
کد همچنان مهمه، اما دیگه نقطه شروع نیست؛ نتیجه اجرای یه طرح مشخصه.
توی تیمهای بزرگ یا پروژههای حساس، گاهی برای این کار از روشهای خیلی رسمیتر و ساختارمندتر استفاده میشه؛ مثلاً زبانهایی برای نوشتن دقیق نیازمندیها یا چند Agent مختلف برای برنامهریزی، پیادهسازی و بررسی خروجی.
ولی واقعیت اینه که همیشه به یه سیستم پیچیده نیاز نداریم. تو خیلی از پروژهها، یه فایل Markdown خوب و حسابشده میتونه همون زمینهای رو فراهم کنه که AI قبل از شروع کدنویسی بهش نیاز داره.
یه Spec خوب چه چیزهایی داره؟
فرض کن یه فایل مثل ARCHITECTURE.md به Agent میدی. از این لحظه به بعد، لازم نیست برای هر چیز مهمی حدس بزنه.
تو از قبل تصمیم گرفتی چه ابزارهایی باید استفاده بشن، مدل داده چطوره، قوانین امنیتی چی هستن و ساختار کلی پروژه چه شکلیه.
یه Spec خوب معمولاً این بخشها رو داره:
User Story و نیازمندیها
کاربر قراره چه کاری انجام بده، خروجی مطلوب چیه و محدوده این فیچر کجاست.پیشزمینه و دلیل تصمیمها
چرا این قابلیت رو میسازیم و چه چیزهایی روی طراحی نهایی اثر گذاشتن.استک فنی و ابزارهای مجاز
فریمورک، کتابخونهها، دیتابیس، ORM و هر وابستگیای که باید استفاده بشه.مدل داده و Schema
موجودیتها، فیلدها، ارتباط بین دادهها، محدودیتها و migrationها.تصمیمهای معماری
احراز هویت و سطح دسترسی، ساختار API، اعتبارسنجی، مدیریت خطا و جریان تغییر دادهها.نیازمندیهای غیرفانکشنال
امنیت، پرفورمنس، تست، دسترسپذیری، لاگگیری و نحوه دیپلوی.
هدف این نیست که قضاوت مهندسی رو حذف کنیم. برعکسه؛ هدف اینه که تصمیمهای مهم رو قبل از اینکه پروژه پیچیده بشه، آگاهانه بگیریم.
وقتی Spec به اندازه کافی کامل باشه، AI وقت کمتری برای حدس زدن صرف میکنه و بیشتر روی پیادهسازی همون چیزی تمرکز میکنه که واقعاً میخوایم.
Spec نباید یه سند فراموششده باشه
ارزش Spec فقط به این نیست که یه بار نوشته بشه و بره گوشه ریپازیتوری خاک بخوره.
Spec خوب یه سند زندهست.
هر وقت نیازمندیها تغییر میکنن، آپدیتش میکنی. هر وقت یه تصمیم معماری عوض میشه، دلیلش رو هم ثبت میکنی. وقتی یه دولوپر جدید یا یه Agent جدید وارد پروژه میشه، این فایل باید بهش کمک کنه بفهمه سیستم فقط چی کار میکنه نه؛ بلکه چرا اینطوری ساخته شده.
به این شکل، فایل Markdown دیگه فقط مستندات نیست. تبدیل میشه به حافظه پروژه؛ چیزی که نسخهبندی میشه، review میشه و توی کارهای بعدی هم به درد میخوره.
وایب کدینگ هنوز هم جای خودش رو داره
قرار نیست وایب کدینگ رو کنار بذاریم. برای کشف ایدهها خیلی خوبه.
میتونی باهاش سریع یه رابط بسازی، چند راهحل رو امتحان کنی، یه MVP بالا بیاری یا حتی بفهمی دقیقاً چی میخوای.
مدل عملیتر معمولاً اینه:
- اول سریع ایده رو بررسی کن.
- چیزهایی که یاد گرفتی رو تبدیل به یه Spec روشن کن.
- نسخه اصلی و production-ready رو بر اساس اون Spec بساز.
- برای تغییرات بعدی هم به همون Spec برگرد.
اینطوری هم سرعت AI رو داری، هم جلوی بههمریختگی معماری رو میگیری.
فرصت واقعی کجاست؟
AI داره بخشی از کارهای تکراری نوشتن کد رو از دوش ما برمیداره. در عوض، بخش مهمتر کار ما پررنگتر میشه: اینکه تصمیم بگیریم چی باید ساخته بشه، چه محدودیتهایی مهمن، اجزای سیستم چطور به هم وصل میشن و محصول چطور با رشدش قابلاعتماد باقی میمونه.
یه Spec خوب، شکل مکتوب همین فکر کردنه.
هرچقدر Context دقیقتر و تصمیمهای روشنتری به AI بدیم، احتمال بیشتری داره که خروجی فقط سریع تولید نشه، بلکه امن، قابلفهم و قابلنگهداری هم باشه.