توسعهٔ مستند‌محور؛ چرا مستندات دقیق به معنای بازگشت به مدل آبشاری نیست

تصور کنید برنامه‌نویسی را به جای نوشتن خط‌به‌خط کد، به مدیریتِ قصدی (Intent Management) تبدیل کنید. اگر فکر می‌کنید نوشتن مستندات دقیق برای یک عامل هوش مصنوعی، شما را به دوران تاریک و صلبِ مدل‌های «آبشاری» بازمی‌گرداند، احتمالاً تفاوت میان «مستند» و «فرآیند» را نادیده گرفته‌اید. در عصر کدنویسی عامل‌محور، خطر واقعی مستندسازی نیست، بلکه وسوسهٔ ارسال دسته‌های عظیم کد بدون دریافت بازخوردهای مرحله‌به‌مرحله است.

این بحث در طول سال ۲۰۲۶ شدت گرفته و پیشکسوتانی چون مارتین فاولر (Martin Fowler) و کنت بک (Kent Beck) درباره اینکه آیا هوش مصنوعی ما را به سمت سبک‌های توسعه خطی و صلب می‌برد یا خیر، به بحث پرداخته‌اند. تنش در سراسر جامعه توسعه‌دهندگان مشهود است؛ برای مثال، یک پست در HackerNews با عنوان «توسعه مستند‌محور: بازگشت آبشار» نزدیک به ۲۰۰ نظر دریافت کرد. برای بسیاری از توسعه‌دهندگان، ترس از این است که «توسعه مستند‌محور» صرفاً نام جدیدی برای همان روش قدیمی آبشاری باشد: ابتدا همه چیز را مشخص کن، سپس همه چیز را بساز و در نهایت همه چیز را تست کن. این بحث‌های مربوط به «آیا این روش چابک است یا خیر»، اغلب به دلیل تفاوت در دیدگاه‌ها درباره معنای «چابکی واقعی» به بحث‌های تند تبدیل می‌شوند.

برای درک این موضوع و فهم اینکه چرا این یک تصور اشتباه است، باید «مستند» را از «فرآیند» جدا کرد. مدل آبشاری با دو ویژگی مشخص شناخته می‌شود: اندازه دسته‌های بزرگ (Large Batch Sizes) و گیت‌های سخت‌گیرانه در هر فاز (Strict Phase Gates). در یک سیستم آبشاری، محصول در یک بلوک غول‌پیکر تعریف می‌شود، در بلوک دیگری ساخته می‌شود و تنها پس از اتمام کامل ساخت، تست می‌شود. در مقابل، متدولوژی چابک (Agile) روی کوچک‌ترین تکه کاری تمرکز می‌کند که بتواند بازخوردی معنادار ایجاد کند.

مستند در برابر فرآیند

نوشتن اینکه نرم‌افزار چه کاری باید انجام دهد، یک محور مجزا از نحوه ارسال و عرضه آن است. به نقل از گزارشی که در ۱۱ سپتامبر ۲۰۲۶ در dev.to منتشر شد، یک مستند مشخصات (Specification) کاملاً با انضباط چابک سازگار است. شما می‌توانید یک مستند کوچک بنویسید، آن را روزانه بازبینی کنید و هم‌زمان با عامل‌هایی که در حال پیاده‌سازی هستند، در لحظه همکاری کنید. در واقع، مستند از هر اندازه دسته‌ای و انضباط همکاری که شما به آن اختصاص دهید، ارث می‌برد.

• مستند آبشاری: سندی منجمد و عظیم که از روی یک دیوار به توسعه‌دهنده تحویل داده می‌شود. این مدل بر این انضباط استوار است که «تا زمانی که مرحله ۱ کامل نشود، مرحله ۲ نمی‌تواند آغاز شود».
• مستند چابک: سندی زنده برای ایجاد درک مشترک از طریق گفتگو. این سند هر بعدازظهر بازبینی شده و در کنار انسان‌ها و عامل‌هایی که در حال پیاده‌سازی هستند، ساخته می‌شود.

وسوسهٔ هوش مصنوعی

عامل‌های هوش مصنوعی هزینه اجرا را به شدت کاهش داده‌اند و همین موضوع یک تله روان‌شناختی جدید ایجاد کرده است. ابزارهایی مانند Lovable اکنون می‌توانند یک اپلیکیشن کامل را تنها با یک جمله بسازند. این قابلیت، هرچند شبیه به یک ابرقدرت است، اما تفکر «دسته‌های بزرگ» را ترویج می‌کند. چون هوش مصنوعی زاینده (Generative AI) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — می‌تواند هزار خط کد را در چند ثانیه تولید کند، توسعه‌دهندگان وسوسه می‌شوند یک نیاز عظیم را به عامل بدهند و اجازه دهند بدون نظارت اجرا شود؛ کاری که در زمان تایپ دستی کد توسط انسان غیرممکن بود.

طبق گزارش تحلیلگران، خطر واقعی مدل آبشاری دقیقاً همین‌جاست. اگر مستندی عظیم می‌نویسید تا فقط آن را به یک عامل One-shot (یک‌باره) بدهید، شما «برنامه‌ریزی» نکرده‌اید، بلکه فقط دسته بزرگ کد را به مرحله قبل (بالادست) منتقل کرده‌اید. این رویکرد می‌تواند منجر به بروز مشکلاتی شود که در تحلیل هزینه‌های پنهان Vibe Coding به آن‌ها اشاره شده است، جایی که ابهام در مستندات سرعت واقعی توسعه را می‌گیرد. پاسخ درست به کدنویسی عامل‌محور، توقف در نوشتن مستندات نیست، بلکه تأکید مضاعف بر تجزیه (Decomposition) است. استدلال اینکه «کدنویسی عامل‌محور، دسته‌های بزرگ را آسان می‌کند»، در واقع دلیلی برای تجزیه بیشتر است، نه دلیلی علیه نوشتن قصد و نیت خود در قالب مستند.

شکاف ابزاری

برخی چارچوب‌های فعلی توسعه مستند‌محور برای «تحویل دادن» (Handoff) طراحی شده‌اند، نه «همکاری». این ابزارها این ایده را تبلیغ می‌کنند که شما فقط بگویید چه می‌خواهید و هوش مصنوعی جادو می‌کند و آن را می‌سازد. این رویکرد با مستند به عنوان یک اثر تحویلی برخورد می‌کند که دقیقاً همان حس مدل آبشاری را منتقل می‌کند. همان‌طور که یووال یرت (Yuval Yeret) اشاره می‌کند، این روش تنها زمانی آبشاری است که شما آن را به این شکل به کار ببرید.

این موضوع یادآور درسی از جامعه BDD (توسعه رفتار-محور) در ۱۵ سال پیش است. آن‌ها دریافتند که هدف هرگز خودِ سند نبود، بلکه «درک مشترک» بود. نوشتن مستند تأیید می‌کند که این درک وجود دارد، اما آن را خلق نمی‌کند؛ درک مشترک در گفتگوها شکل می‌گیرد.

ترس از بداهه‌پردازی را کنار بگذارید

توسعه واقعاً چابک، ترتیب ثابت عملیات را رد می‌کند. این تصور که «اگر اول مستند بنویسیم، پس آبشاری است»، فرض می‌کند توالی همیشه یک ترتیب صلب است: مستند $\rightarrow$ کد $\rightarrow$ تست. اما شما می‌توانید این مراحل را بر اساس آنچه در آن لحظه نیاز به یادگیری دارید، ترکیب کنید:

• ترکیب مشارکتی (The Collaborative Smoothie): نمونه اولیه، مستند، تست و ساخت در دسته‌های کوچک، در حالی که مشتری هم‌زمان نتیجه را می‌چشد و بازخورد می‌دهد.
• مسیر خطی (The Linear Path): توالی مستند-کد-تست همچنان روشی مناسب و خوب برای ساخت نرم‌افزار است.
• مسیر تکرارشونده (The Iterative Path): ابتدا TDD، سپس یک نمونه اولیه، دریافت بازخورد کاربر، بازبینی تست‌ها و کد، و در نهایت مستندسازی آنچه ساخته شده است.

هوش مصنوعی در تمام این حالت‌ها می‌درخشد. این فناوری می‌تواند از روی یک مستند کد بزند، از روی یک نمونه اولیه تکرار کند یا در چارچوب TDD کار کند. هوش مصنوعی هزینه اجرای این مراحل را چنان پایین آورده که می‌توانید بدون احساس گناه بین آن‌ها جابه‌جا شوید.

حفظ مبنای واقعیت

در نهایت، تنها چیزی که یک تیم را چابک نگه می‌دارد، درک مشترک از نیازهای مشتری و دسته‌هایی است که آن‌قدر کوچک باشند که درک تیم قدیمی و منقضی نشود. هوش مصنوعی این حقیقت بنیادی را تغییر نمی‌دهد، بلکه فقط مسیر اشتباه (دسته‌های بزرگ) را بی‌دردسر می‌کند. وعده مرکزی هوش مصنوعی — اینکه فقط بخواهید و مدل زبانی بزرگ (LLM) آن را بسازد — مستقیماً با پرسش اصلی متدولوژی چابک برخورد می‌کند: چطور می‌دانید چه می‌خواهید، در حالی که هنوز چیزی نساخته‌اید یا آن را به کسی نشان نداده‌اید؟

برای مقابله با این موضوع، رویکردهای جدیدی مانند dot•requirements تلاش می‌کنند تا نیازمندی‌ها را در کنار کد زنده نگه دارند. با اطمینان از اینکه مستندات برای انسان و عامل‌ها خوانا هستند و با هر بار اجرای تست‌ها با واقعیت چک می‌شوند، تیم‌ها می‌توانند تضمین کنند آنچه نوشته‌اند با آنچه ارسال کرده‌اند مطابقت دارد. این کار از تبدیل شدن مستند به یک سند قدیمی و بی‌مصرف جلوگیری کرده و آن را به بخشی زنده از کدبیس تبدیل می‌کند.

این تغییر به معنای آن است که نقش توسعه‌دهنده از «کدنویس» به «هماهنگ‌کننده قصد» (Orchestrator of Intent) تغییر می‌کند. مهارت دیگر فقط در نوشتن کد نیست، بلکه در تجزیه یک چشم‌انداز پیچیده به مستندات کوچک و قابل تأییدی است که یک عامل بتواند بدون انحراف از هدف، آن‌ها را اجرا کند.

در آینده، منتظر ظهور ابزارهای «نیازمندی به عنوان کد» (Requirement-as-code) باشید که به طور خودکار و در لحظه هشدار می‌دهند که چه زمانی یک ویژگی تولید شده توسط هوش مصنوعی از مستندات اصلی منحرف شده است.

گام بعدی شما

• به جای نوشتن یک مستند جامع، سعی کنید نیازمندی‌های خود را به تکه‌های کوچک‌تر از ۵۰۰ خط کد تقسیم کنید.
• از ابزارهای مستندسازی زنده استفاده کنید که تغییرات کد را به طور خودکار با مستندات تطبیق می‌دهند.
• در هر چرخه تولید، یک مرحله «تأیید درک مشترک» بین خود و عامل هوش مصنوعی تعریف کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.