تصور کنید به یک پیمانکار می‌گویید «یک اتاق خواب به خانه‌ام اضافه کن» و او بدون نقشه، هر طور که فکر می‌کند دیوارها را می‌کشد. نتیجه احتمالاً چیزی است که با نیاز شما فاصله دارد، اما ظاهرش شبیه اتاق است؛ این دقیقاً همان اتفاقی است که در کدنویسی بر اساس حس (Vibe Coding) می‌افتد. وقتی پرامپتی مثل «ثبت‌نام کاربر را به اپلیکیشن اضافه کن» می‌نویسید، هوش مصنوعی باید فیلدها، قوانین رمز عبور، فرآیندهای تأیید ایمیل و روش‌های ذخیره‌سازی را حدس بزند. این فرآیند نامنظم، همان چیزی است که GitHub Spec Kit قصد نابودی آن را دارد. این ابزار که به صورت متن‌باز منتشر شده است، مرجع تصمیم‌گیری را از حدس‌های مدل به مشخصات تأییدشده توسط انسان منتقل می‌کند. این رویکرد در واقع تلاشی برای جایگزینی کدنویسی حسی با توسعه مستند‌محور در نرم‌افزارهای پیچیده است تا دقت سیستم‌ها افزایش یابد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی ریسک سیستم‌های خودبهبودبخش و این موضوع که توسعه مبتنی بر هوش مصنوعی چگونه می‌تواند شکست‌های نرم‌افزاری غیرقابل توضیح را عادی کند اشاره کردیم، اتکای مطلق به خروجی‌های مدل بدون نظارت، منجر به خطاهای سیستمی نامرئی می‌شود. گیت‌هاب با معرفی توسعه مبتنی بر مشخصات (Spec-Driven Development یا SDD)، یک چارچوب سخت‌گیرانه ایجاد کرده است. در این مدل، «مشخصات» (Specification) دیگر یک سند جانبی یا فکر بعدی نیست، بلکه تنها منبع حقیقت است که عامل کدنویس را هدایت می‌کند. تصور کنید در یک پروژه ساختمانی، نقشه فقط یک پیشنهاد نباشد، بلکه یک قرارداد قانونی باشد که سازنده باید پیش از دریافت دستمزد ثابت کند که دقیقاً از آن پیروی کرده است. در اینجا فرآیند وارونه شده است: مشخصات یک نقشه اجرایی است که عامل‌های کدنویسی هوش مصنوعی را پیش می‌برد.
سه سطح سخت‌گیری در SDD
طبق مستندات GitHub Spec Kit، تمام مشخصات با شدت یکسانی برخورد نمی‌شوند و بر اساس اینکه سند تا چه زمانی مرجع باقی می‌ماند و سطح بلوغ ابزارهای موجود چقدر است، به سه سطح تقسیم می‌شوند:
- Spec-first: در این سطح، یک سند دقیق پیش از شروع کدنویسی نوشته می‌شود تا پیاده‌سازی اولیه را هدایت کند. اما به محض اینکه کد ایجاد شد، ممکن است سند نادیده گرفته شود یا کد از آن فاصله بگیرد (Drift). ارزش اصلی این روش در ایجاد شفافیت اولیه است و برای ساخت نمونه‌های اولیه (Prototypes) و اولین نسخه‌های assisted-AI بسیار مناسب است.
- Spec-anchored: در این سطح، سند حفظ شده و هم‌زمان با نرم‌افزار از طریق تست‌های خودکار و قراردادها تکامل می‌یابد. هر تغییر در رفتار سیستم، هم در سند و هم در کد اعمال می‌شود. تست‌هایی که از روی سند استخراج شده‌اند — مانند سناریوهای BDD یا OpenAPI با تست‌های قراردادی — در صورت بروز فاصله بین کد و سند، شکست می‌خورند. این روش برای اکثر سیستم‌های عملیاتی (Production) مناسب است.
- Spec-as-source: در این سطح پیشرفته، خودِ سند فایل منبع اصلی است و عامل‌ها کد را مستقیماً از روی تغییرات سند تولید یا به‌روزرسانی می‌کنند. انسان‌ها فقط سند را ویرایش می‌کنند و هرگز به کد تولیدشده دست نمی‌زنند تا انحراف کد از سند به طور ساختاری حذف شود. این روش نیازمند ابزارهای تولید بسیار بالغ و قابل اعتماد است و در حال حاضر عمدتاً برای موارد تعریف‌شده مانند تولید Server Stubs از روی OpenAPI کاربردی است.
به عنوان یک قاعده کلی، توسعه‌دهندگان باید از حداقل سطح سخت‌گیری استفاده کنند که ابهامات را در بافتار (Context) خاص پروژه آن‌ها از بین می‌برد.
تبدیل مشخصات به قرارداد
در جریان‌های سنتی کد-محور، اسناد نیازمندی‌ها به مرور زمان قدیمی می‌شوند و نمودارهای طراحی می‌پوسند، در نتیجه کد تبدیل به حقیقت دوفاکتو (de facto) می‌گردد. برای درک اینکه یک تابع چه کاری انجام می‌دهد، فرد مجبور است پیاده‌سازی آن را بخواند. SDD این رابطه را وارونه می‌کند: مشخصات تبدیل به توصیفی معتبر می‌شود که هم انسان و هم ماشین برای ساخت و نگهداری سیستم از آن استفاده می‌کنند. در این مدل، سند «قصد» (Intent) را اعلام می‌کند و کد آن را «تحقق» (Realize) می‌بخشد. این هدف با استراتژی‌هایی نظیر حذف حدس و گمان در طراحی معماری نرم‌افزار هم‌سو است تا ابهامات از ابتدای مسیر حذف شوند.
به گزارش گیت‌هاب، سه ویژگی کلیدی یک سند را از «مستندات ساده» به «قرارداد» تبدیل می‌کند:
۱. محدودیت متوالی (Sequential Constraint): هر مرحله، مرحله بعد را محدود می‌کند. فاز «تعیین» (Specify) به سؤال چه چیزی پاسخ می‌دهد، فاز «برنامه‌ریزی» (Plan) به سؤال چگونه پاسخ می‌دهد و سپس وظایف، پیاده‌سازی و اعتبارسنجی می‌آیند. هر مرحله یک خروجی (Artifact) تولید می‌کند که راهنمای مرحله بعد است و بدین ترتیب زنجیره‌ای از پاسخگویی ایجاد می‌شود.
۲. مرجعیت دائمی (Persistent Authority): سند همیشه نقطه مرجع باقی می‌ماند. وقتی در مرحله اعتبارسنجی شکافی پیدا می‌شود، توسعه‌دهنده یا کد را اصلاح می‌کند یا سند را بازبینی می‌کند. مشخصات لنگرگاه تمام اصلاحات است.
۳. قابلیت تأیید (Verifiability): برخلاف اسناد طراحی سنتی که صرفاً خوانده می‌شوند، یک قرارداد برای تأیید شدن است. اگر کد از سند فاصله بگیرد، باید چیزی در سیستم شکست بخورد. این دقیقاً مشابه مشخصات API مانند OpenAPI است که در آن تیم‌های فرانت‌اند و بک‌اند به صورت موازی و بر اساس یک قرارداد توافق‌شده کار می‌کنند.
البته یک بررسی واقع‌بینانه لازم است: یک تاییدیه موفق فقط ثابت می‌کند که کد با سند مطابقت دارد. اگر خودِ سند اشتباه باشد، هوش مصنوعی با دقت کامل، یک سیستم اشتباه را پیاده‌سازی خواهد کرد.
گردش کار Spec Kit: از قصد تا همگرایی
ابزار GitHub Spec Kit با عامل‌هایی مثل Copilot، Claude، Gemini و Codex ادغام می‌شود تا یک خط لوله خطی و محدود را اجرا کند. این سیستم را می‌توان از طریق افزونه‌ها (Extensions)، پیش‌فرض‌ها (Presets)، گردش‌های کاری (Workflows) و بسته‌ها (Bundles) گسترش داد. فرآیند از یک توالی سخت‌گیرانه پیروی می‌کند: تعیین $ \rightarrow $ برنامه‌ریزی $ \rightarrow $ وظایف $ \rightarrow $ پیاده‌سازی $ \rightarrow $ همگرایی.
۱. قانون اساسی (Constitution): با استفاده از دستور /speckit-constitution کاربر اصول و محدودیت‌های کلی پروژه را یک بار برای کل پروژه تعریف می‌کند. برای مثال، قانون اساسی می‌تواند بیان کند: «لیست کارهای من یک اپلیکیشن وب تطبیقی است»، «منطق تجاری در بک‌اند قرار دارد و هرگز در UI نباشد» و «هر ویژگی باید همراه با تست‌های خودکار باشد». این کار اصول راهنمایی را ایجاد می‌کند که تمام مراحل بعدی با آن‌ها ارزیابی می‌شوند و قالب‌های وابسته را همگام نگه می‌دارد.
۲. تعیین (Specify): با دستور /speckit-specify کاربر تعریف می‌کند که ویژگی چه چیزی است و چرا وجود دارد. برای یک لیست کارهای من، این شامل نیازمندهایی مثل «کاربر بتواند تسک اضافه کند، آن را به عنوان انجام‌شده علامت بزند، حذف کند و تسک‌ها را بر اساس وضعیت فیلتر کند» و محدودیت‌هایی مثل «یک تسک باید عنوانی غیرخالی داشته باشد» می‌شود. این مرحله فایل spec.md را ایجاد می‌کند که بر رفتار کاربر و اهداف تمرکز دارد، نه روی پشته تکنولوژی (Tech Stack). همچنین ممکن است فایل checklists/requirements.md را برای بررسی کیفیت خودِ سند نگهداری کند.
۳. برنامه‌ریزی (Plan): دستور /speckit-plan وارد بحث چگونه می‌شود. اینجا جایی است که تکنولوژی وارد می‌شود. در مثال ما، برنامه مشخص می‌کند که یک اپلیکیشن وب Angular، یک REST API و یک دیتابیس رابطه‌ای با مدل داده‌ای Task(id, title, status, createdAt) استفاده شود. این دستور فایل plan.md را تولید می‌کند که جزئیات معماری و محدودیت‌های فنی را شرح می‌دهد.
۴. وظایف (Tasks): دستور /speckit-tasks برنامه را به یک فایل tasks.md تبدیل می‌کند که وظایف در آن بر اساس وابستگی‌ها مرتب شده‌اند. وظایف در فازهای مختلف سازماندهی می‌شوند: Setup (راه‌اندازی)، Foundational (پیش‌نیازهای مسدودکننده)، یک فاز برای هر User Story به ترتیب اولویت (مثلاً اضافه کردن، تکمیل، حذف، فیلتر) و در نهایت فاز Polish برای مسائل عرضی. تست‌ها در فاز User Story تولید می‌شوند و وظایفی که قابلیت اجرای موازی دارند، صراحتاً علامت‌گذاری می‌شوند.
۵. پیاده‌سازی (Implement): دستور /speckit-implement کد را با اجرای وظایف موجود در tasks.md به ترتیب وابستگی می‌نویسد. این دستور وضعیت چک‌لیست‌ها را به عنوان یک دروازه (Gate) می‌خواند؛ اگر مواردی تیک نخورده باشند، پیش از ادامه کار اجازه می‌گیرد و هرگز علامت‌های چک‌لیست را تغییر نمی‌دهد. برای ویژگی‌های بزرگ، کاربران می‌توانند اجرای دستور را به فازهای خاصی (مثلاً فقط Setup و Foundational) محدود کنند.
۶. همگرایی (Converge): مرحله نهایی، /speckit-converge است که کدبیس را در برابر سند، برنامه و وظایف ارزیابی می‌کند. این مرحله فقط به صورت Append-only است و هرگز کدی را حذف نمی‌کند. این ابزار خلاصه‌ای از یافته‌ها را بر اساس شدت خطا چاپ می‌کند. اگر شکافی پیدا شود، وظایف جدیدی به بخش «Convergence» در فایل tasks.md اضافه می‌کند و این روند تا زمانی که سیستم «همگرا» (Converged) گزارش شود، تکرار می‌گردد.
دروازه‌های کیفیت و اعتبارسنجی
برای جلوگیری از اینکه هوش مصنوعی روی ابهامات برنامه‌ریزی کند، Spec Kit سه ابزار کیفی خاص ارائه می‌دهد که به عنوان دروازه در چرخه حیات توسعه نرم‌افزار (SDLC) عمل می‌کنند:
- Clarify: این ابزار سوالات هدفمندی درباره هر چیزی که به اندازه کافی تعریف نشده است می‌پرسد و پاسخ‌ها را دوباره به سند (Spec) بازمی‌گرداند. این ابزار پیش از برنامه‌ریزی اجرا می‌شود تا اطمینان حاصل شود که بنیاد پروژه محکم است.
- Checklist: چک‌لیست‌های کیفی سفارشی تولید می‌کند. این چک‌لیست‌ها در اختیار بازبین (Reviewer) هستند و باید پیش از شروع فاز پیاده‌سازی برآورده شوند.
- Analyze: یک ابزار فقط-خواندنی (Read-only) است که تضادها، شکاف‌ها و ابهامات را در فایل‌های
spec.md،plan.mdوtasks.mdگزارش می‌کند. این ابزار تضمین می‌کند که پیش از نوشتن حتی یک خط کد، سازگاری کامل وجود داشته باشد.
تغییر نقش مهندس نرم‌افزار
این چارچوب انسان را از چرخه حذف نمی‌کند، بلکه جایگاهی را که قضاوت انسان در آن اعمال می‌شود، تغییر می‌دهد. پذیرفتن تغییرات تولیدشده توسط AI با کمترین مقاومت، صرفاً همان «کدنویسی بر اساس حس» است که حالا تعداد فایل‌هایش بیشتر شده است. در عوض، ماشین‌ها کارهای مکانیکی را بر عهده می‌گیرند: تولید کد، همگام نگه داشتن مستندات و شناسایی انحرافات.
انسان‌ها همچنان بر موارد زیر اختیار دارند:
- قصد و معنای دامنه (Intent and Domain Meaning): تعریف اینکه سیستم واقعاً باید به چه هدفی دست یابد.
- تحمل ریسک (Risk Tolerance): تصمیم‌گیری درباره اینکه چه مقدار ریسک در یک پیاده‌سازی خاص پذیرفتنی است.
- محدودیت‌های قانونی و اخلاقی: کدگذاری الزاماتی که هیچ ردپای اجرایی (Execution Trace) نمی‌تواند آن‌ها را آشکار کند.
در عمل، این به معنای ایجاد مرزهای صریح برای تأیید است. یک تغییر در Schema که باعث شکستگی شود، تغییر در سیاست‌ها، یک بازسازی (Refactoring) پیشنهادی یا کاهش سازگاری (Compatibility Downgrade) هرگز نباید بدون تصمیم انسان عبور کند. برای مهندس، ارزش دیگر از سرعت نوشتن خطوط کد نمی‌آید، بلکه از کیفیت مشخصاتی می‌آید که آن‌ها پالایش و تأیید می‌کنند. مهندس به یک ارکستراتور تبدیل می‌شود که «چه چیزی» را در بالادست تعریف و «چگونه» را در مرزها تأیید می‌کند. این مدلی از «خودمختاری محدود» (Bounded Autonomy) است: اجرا خودکار است، اما معنا همچنان انسانی باقی می‌ماند.
تحلیل: پایان عصر پرامپت‌نویسی
برای یک توسعه‌دهنده کاربردی، این اتفاق به معنای تغییر از «مهندسی پرامپت» به «مهندسی مشخصات» (Specification Engineering) است. با جداسازی چه چیزی (Spec) از چگونه (Plan)، Spec Kit اجازه چابکی معماری را می‌دهد. اگر توسعه‌دهنده‌ای متوجه شود که در سند مشخصات عبارت «از PostgreSQL استفاده کن» را نوشته است، باید آن را به بخش برنامه منتقل کند. این جداسازی اجازه یک آزمایش قدرتمند را می‌دهد: تغییر دادن تنها بخش «برنامه» برای انتقال بک‌اند به یک تکنولوژی دیگر، در حالی که سند مشخصات، قرارداد REST و مدل داده‌ها دست‌نخورده باقی می‌مانند.
این رویکرد مستقیماً به بدهی فنی (Technical Debt) ایجاد شده توسط پرامپت‌های آشفته پاسخ می‌دهد. وقتی مشخصات تبدیل به قرارداد شود، کد به یک جزئیات پیاده‌سازی قابل جایگزین (Disposable) تبدیل می‌شود. اثر مرتبه دوم این کار، کاهش توهمات (Hallucinations) هوش مصنوعی است، زیرا مدل دیگر نیازی به حدس زدن نیازمندی‌ها ندارد، بلکه توسط یک سند تأییدشده محدود شده است.
برای مشاهده این فرآیند در عمل، می‌توانید پیاده‌سازی یک اپلیکیشن تطبیقی Angular را با استفاده از این ابزارها در پروفایل گیت‌هاب rosidotidev بررسی کنید.
گفتگو