تیمهای مهندسی هوش مصنوعی Vibe Coding را به نفع مشخصات فنی کنار میگذارند
در سهماهه اول سال ۲۰۲۶، چندین تیم مهندسی که سال گذشته را صرف «Vibe Coding» کرده بودند — یعنی بهطور آزادانه از AI agent درخواست میکردند و تکرار را تا زمانی که چیزی کار کند ادامه میدادند — بیسروصدا مسیر خود را تغییر دادند. دلیل این نبود که agents بدتر شده بودند. بلکه این بود که prompting بدون ساختار زمانی که به agents برای تغییرات چندفایلی و Pull Requestهای خودکار اعتماد شد، دیگر مقیاسپذیر نبود. راهحلی که تیمها بر روی آن به اجماع رسیدند توسعه مبتنی بر مشخصات فنی (Spec-Driven Development یا SDD) است: نوشتن یک مشخصات فنی ساختاریافته پیش از آنکه agent حتی به کد دست بزند، و در نظر گرفتن آن مشخصات — نه دیف نهایی — بهعنوان منبع حقیقت.
این بازگشت به اسناد نیازمندیهای سبک Waterfall نیست که کسی آنها را نمیخواند. این یک واکنش مستقیم به یک حالت شکست خاص است: کد مطمئن و ظاهراً درست که بیصدا مشکل اشتباهی را حل میکند، زیرا کسی کار agent را بر اساس یک تعریف واقعی از «انجامشده» پایهگذاری نکرده است. تا اواسط ۲۰۲۶، هر فروشنده اصلی coding-agent — GitHub، AWS، اکوسیستم Claude Code انتروپیک، و موجی از فریمورکهای Open Source — نسخه خود را از گردشکارهای مبتنی بر مشخصات فنی منتشر کرده است، و این الگو از «آزمایش جالب» به رویه پیشفرض در تیمهای تولیدی تبدیل شده است.
چرا Vibe Coding در مقیاس بزرگ از کار میافتد
یک رفع باگ تکفایلی یا یک اسکریپت کوچک، prompting آزادانه را تحمل میکند، زیرا شعلهی انفجار کوچک است و یک انسان کل دیف را در چند ثانیه بررسی میکند. ویژگیهای چندفایلی به این شکل کار نمیکنند. از یک agent خواسته شود «صورتحساب اشتراک اضافه کند»، باید تصمیمات مربوط به schema پایگاه داده، قراردادهای مدیریت خطا، الگوهای نامگذاری و موارد لبهای که هرگز بیان نشدهاند را استنتاج کند — و با اطمینان استنتاج خواهد کرد، حتی زمانی که اشتباه باشد. شکست بهصورت crash ظاهر نمیشود؛ بلکه سه اسپرینت بعد بهصورت انحراف معماری، منطق تکراری، و پایگاه کدی که دیگر با مدل ذهنی هیچکس مطابقت ندارد، خود را نشان میدهد.
شواهد تجاری برای این موضوع اکنون عمومی شده است. GitHub گزارش داده است که تیمهایی که از ابزار Spec Kit آن در پروژههای داخلی استفاده میکنند، ویژگیها را با تقریباً یک مرتبه بزرگی سیکلهای «بازتولید از صفر» کمتر نسبت به تیمهایی که از prompting موردی استفاده میکنند، عرضه میکنند. AWS موارد مشتریانی را منتشر کرده است که در آن ویژگیهایی که ۴۰ ساعت زمان مهندسی تخمین زده شده بودند، در کمتر از ۸ ساعت تلاش انسانی تحویل داده شدند، پس از آنکه کار ابتدا بهعنوان یک مشخصات فنی تألیف شد و agent پیادهسازی مکانیکی را بر اساس معیارهای پذیرش واضح انجام داد.
ابزارهایی که مشخصات فنی را به حالت پیشفرض تبدیل میکنند
پنج فریمورک اکنون چشمانداز مبتنی بر مشخصات فنی را تعریف میکنند، و رویکردهای واقعاً متفاوتی دارند:
- GitHub Spec Kit — یک CLI متنباز با مجوز MIT با بیش از ۹۳٬۰۰۰ ستاره GitHub (نسخه v0.8.7 در می ۲۰۲۶ منتشر شد). هر پروژه Spec Kit با یک «قانون اساسی» شروع میشود: یک فایل Markdown از اصول غیرقابل تغییر و سراسری پروژه — استانداردهای تست، محدودیتهای معماری، قراردادهای نامگذاری — که در هر جلسه agent بهعنوان یک قرارداد پایدار بین توسعهدهنده و agent باقی میماند.
- AWS Kiro — یک انشعاب از VS Code که در می ۲۰۲۶ به دسترسی جهانی گسترده رسید و مشخصات فنی را در مرکز IDE قرار میدهد. Kiro یک Pipeline سختگیرانه اعمال میکند:
requirements.md(داستانهای کاربری با معیارهای پذیرش نوشتهشده به نماد EARS — «WHEN [شرط] THE SYSTEM SHALL [رفتار]»، قالبی که در اصل در Rolls-Royce برای سیستمهای ایمنی-بحرانی توسعه یافته است) →design.md(معماری و نمودارهای توالی) →tasks.md(مراحل پیادهسازی مجزا و قابل ردیابی) → کد. - BMAD-METHOD — یک فریمورک با مجوز MIT (نسخه v6.6.0، آوریل ۲۰۲۶؛ بیش از ۴۶٬۷۰۰ ستاره) که دوازده یا بیشتر نقش تخصصی agent را هماهنگ میکند — مدیر محصول، معمار، طراح UX، توسعهدهنده، QA، اسکرام مستر — که هرکدام سند agent قبلی را میخواند و سند خود را تولید میکند، و زنجیرهای قابل ردیابی از نیازمندی تا کد تحویلشده ایجاد میکند.
- Tessl — بهصورت «tiles» در دایرکتوری
.tessl/پروژه نصب میشود و با هر agent سازگار با MCP از جمله Claude Code و Cursor کار میکند. agents آن دستورالعمل دارند که ابتدا سؤالات روشنکننده بپرسند، مشخصات فنی را بنویسند، منتظر تأیید صریح توسعهدهنده بمانند و تنها پس از آن پیادهسازی کنند — با مشخصات فنی که در مخزن بهعنوان حافظه بلندمدت و یک مسیر حسابرسی در طول تکامل برنامه باقی میماند. - OpenSpec — سبکترین گزینه: رایگان، دارای مجوز MIT، کاملاً در مخزن زندگی میکند، به کلید API یا سرور MCP نیاز ندارد. از سناریوهای اختیاری Given/When/Then و یک مدل ردیابی دلتای متمایز (ADDED / MODIFIED / REMOVED) که بهطور خاص برای تکامل یک پایگاه کد موجود بهجای ساختهای Greenfield طراحی شده است، استفاده میکند.
کار آکادمیک شروع به همگامی با این رویه کرده است: یک مقاله طبقهبندی فرآیند در سال ۲۰۲۶ که فریمورکهای AI software development agents را مقایسه میکرد، نشان داد که رشته مشترک در همه آنها جدا کردن «چه چیزی بسازیم» از «چگونه بسازیم» به مصنوعات مجزا و قابل خواندن برای agent است — دقیقاً همان انضباطی که Vibe Coding از آن چشمپوشی میکند.
یک Prompt بد در مقابل یک مشخصات فنی واقعی
تفاوت در مقایسه کنار هم بهراحتی دیده میشود. در اینجا یک prompt Vibe Coding معمولی برای یک ویژگی واقعی آورده شده است:
بد: "یک راه برای کاربران اضافه کن تا دادههای خود را بهعنوان فایل CSV خروجی بگیرند، آن را زیبا کن."
این prompt که به agent با دسترسی نوشتن چندفایلی داده میشود، هر تصمیم واقعی را انجامنشده رها میکند: کدام فیلدها خروجی گرفته شوند، دادههای تودرتو یا مرتبط چگونه مسطح شوند، با خروجیهای ۵۰۰٬۰۰۰ ردیفی چه اتفاقی بیفتد، آیا endpoint نیاز به محدوده احراز هویت دارد، نام فایل و encoding باید چه باشد. agent پاسخها را انتخاب خواهد کرد — و در هر تولید مجدد متفاوت انتخاب خواهد کرد.
در اینجا همان ویژگی بهعنوان یک مشخصات فنی، در قالب سبک EARS که Kiro و Spec Kit هر دو تشویق میکنند، آورده شده است:
خوب:
- WHEN کاربری با حساب فعال روی "Export Data" کلیک میکند THE SYSTEM SHALL یک CSV شامل ستونهای: id, email, created_at, last_login, subscription_tier تولید کند.
- WHEN خروجی شامل بیش از ۵۰٬۰۰۰ ردیف باشد THE SYSTEM SHALL پاسخ را بهجای بافر کردن در حافظه، stream کند.
- WHEN کاربری بدون مجوز خروجی از endpoint درخواست میکند THE SYSTEM SHALL یک ۴۰۳ با بدنه خطا مطابق با schema خطای API موجود برگرداند.
- THE SYSTEM SHALL فایل را
export-{userId}-{ISO8601 date}.csvنامگذاری کرده و آن را بهعنوان UTF-8 with BOM برای سازگاری با Excel encode کند.
هیچ چیز در اینجا مهندسی عجیبی نیست — این همان تفکری است که یک مهندس شایسته در یک بررسی طراحی انجام میدهد. تفاوت در این است که قبل از شروع agent نوشته شده است، بنابراین agent بر اساس معیارهای صریح پیادهسازی میکند بهجای بداههسازی آنها، و یک بازبین میتواند دیف را با مشخصات فنی مقایسه کند بهجای معکوسسازی مهندسی نیت از کد.
یک مشخصات فنی خوب باید شامل چه مواردی باشد
صرف نظر از اینکه یک تیم چه فریمورکی را اتخاذ میکند، مشخصات فنی که واقعاً در گردشکارهای مبتنی بر agent دوام میآورند، یک شکل مشترک دارند:
- مرزهای محدوده صریح — آنچه ویژگی انجام نمیدهد، نه فقط آنچه انجام میدهد.
- معیارهای پذیرش قابل آزمایش — نوشته شده بهعنوان عبارات WHEN/THEN یا Given/When/Then که یک agent (یا یک مجموعه تست) میتواند بهصورت مکانیکی تأیید کند، نه نثری که یک انسان باید تفسیر کند.
- شکل داده و موارد لبهای — schema، قابلیت null بودن، محدودیت اندازه، و آنچه در مرزها اتفاق میافتد (ورودی خالی، حداکثر ورودی، دسترسی همزمان).
- محدودیتهای غیرعملکردی — بودجه عملکرد، نیازمندیهای احراز هویت/مجوز، و قراردادهای مدیریت خطا که با پایگاه کد موجود مطابقت دارند.
- یک «قانون اساسی» یا سند هدایت پایدار — قوانین سراسری پروژه (استانداردهای تست، الگوهای معماری، وابستگیهای ممنوعه) که نباید در هر مشخصات فنی تکرار شود.
- یک دروازه تأیید انسانی صریح — نقطهای که در آن یک توسعهدهنده مشخصات فنی را تأیید میکند قبل از اینکه agent مجاز به تولید کد شود، نه بعد از آن.
نکات کلیدی
تیمهایی که در سال ۲۰۲۶ coding agents AI را اتخاذ میکنند، باید مشخصات فنی را بهعنوان واحد کار مهندسی در نظر بگیرند، نه prompt را. بهطور مشخص: یک فریمورک مشخصات فنی را انتخاب کنید (OpenSpec برای شروع کماصطکاک روی یک پایگاه کد موجود، Spec Kit یا Kiro اگر تیم یک Pipeline الزامی نیازمندی-طراحی-وظایف میخواهد) و نیاز داشته باشید که هر وظیفه agent چندفایلی از یک مشخصات فنی نوشتهشده با معیارهای پذیرش قابل آزمایش شروع شود. یک سند «قانون اساسی» پایدار با قوانین معماری و سبکی که برای هر ویژگی اعمال میشود نگه دارید، تا مشخصات فنی فقط نیاز به پوشش آنچه واقعاً جدید است داشته باشند. و عادت بررسی را حول بررسی کد در برابر معیارهای پذیرش مشخصات فنی ایجاد کنید — نه بازخوانی تمام دیف خط به خط، که دقیقاً همان گلوگاهی است که توسعه مبتنی بر مشخصات فنی برای حذف آن طراحی شده است.