تصور کنید برای ساخت یک برنامه ساده، مجبور باشید ۸ ساعت را صرف بازجویی شدید از نیازهای پروژه کنید، در حالی که تمام آنچه واقعاً لازم دارید، یک نمونه اولیه است که در ۱۵ دقیقه آماده شود. این تفاوت در «درجهٔ برنامه‌ریزی»، تله‌ای است که بسیاری از توسعه‌دهندگان در عصر هوش مصنوعی در آن می‌افتند؛ تله‌ای که در آن سیستم پیش از آنکه شکل واقعی‌اش درک شود، بیش از حد توصیف و مشخص می‌شود.
پارادوکس برنامه‌ریزی
طبق گزارش‌های ارائه شده در نشست Agentic Builders Collective سنگاپور در ژوئن ۲۰۲۴، یک متدولوژی خاص برای گردش‌کار برنامه‌ریزی در هوش مصنوعی زاینده (Generative AI) معرفی شده است. این سیستم، مهارت عامل «بازجویی با مستندات» (grill-with-docs) مت پاکوک را با مهارت‌های عامل «شکل‌دهی» (shaping) رایان سینگر ترکیب می‌کند. وقتی این سیستم به شکلی بسیار سفارشی اجرا شود، یک سند نیازمندی‌های محصول (PRD) و یک برنامهٔ پیاده‌سازی (Implementation Plan) تولید می‌کند. این اسناد سپس می‌توانند به یک ابزار اجرایی هوش مصنوعی (AI Harness) — مانند OpenCode، Pi، Codex یا Claude Code — داده شوند تا نرم‌افزاری در سطح تولیدی (Production-grade) خلق کنند.
اما کاربران اولیه با یک نقطه اصطکاک جدی روبرو شدند: برنامه‌ریزی بیش از حد طولانی بود. در حالی که برخی توسعه‌دهندگان سه ساعت زمان صرف کردند، یک نفر گزارش داد که بیش از ۸ ساعت را در این مرحله گذرانده است. تلاش‌های اولیه برای بهینه‌سازی این فرآیند — از طریق کاهش تعداد سؤالات و برگزاری مصاحبه‌های فشرده‌تر در حالی که همان سطح از دقت حفظ شود — شکست خورد. دلیل این شکست آن بود که آن سطح از دقت و سخت‌گیری برای ایجاد مشخصات در سطح تولیدی کاملاً ضروری بود.
عدم تطابق در درجات برنامه‌ریزی
درک نهایی این بود که مشکل از کارایی نبود، بلکه عدم تطابق در «درجات» (Grades) برنامه‌ریزی بود. نرم‌افزارهای سطح تولیدی — یعنی برنامه‌هایی که یک تیم برای ماه‌ها یا سال‌ها آن‌ها را نگهداری و پشتیبانی می‌کند — به بازجویی شدید و دقیق از نیازمندی‌ها نیاز دارند. در توسعهٔ نرم‌افزار توسط انسان، اشتباهات طی ماه‌ها کشف و اصلاح می‌شوند. اما وقتی یک ابزار اجرایی هوش مصنوعی سیستم را در عرض چند دقیقه می‌سازد، این فرصت‌های اصلاحی از بین می‌روند. در این حالت، سند برنامه‌ریزی تنها جایی است که خطاها می‌توانند شناسایی و شکار شوند.
این موضوع یک تفکیک روشن ایجاد می‌کند: نرم‌افزار سطح تولیدی، شایستهٔ برنامه‌ریزی سطح تولیدی (۳ تا ۸ ساعت) است، در حالی که نرم‌افزار سطح نمونه‌ساز (Prototype-grade) تنها به برنامه‌ریزی سطح نمونه‌ساز (۱۵ دقیقه) نیاز دارد. اکثر توسعه‌دهندگان در ابتدا به یک نرم‌افزار سطح تولیدی نیاز ندارند؛ آن‌ها ابتدا باید کشف کنند که اصلاً چه چیزی را باید بسازند.
اقتصاد جدید نمونه‌سازی
برای سال‌ها، ساخت نمونه‌های اولیه (Prototyping) از مد افتاد زیرا گران‌قیمت تلقی می‌شد. حتی نرم‌افزارهای یک‌بار مصرف نیز روزها یا هفته‌ها زمان می‌بردند تا ساخته شوند؛ به همین دلیل منطقی‌تر بود که ابتدا با دقت برنامه‌ریزی شود و سپس یک بار به درستی ساخته شود. اما هوش مصنوعی زاینده اقتصاد این فرآیند را به طور رادیکال تغییر داده است.
اکنون برای یک توسعه‌دهنده که با یک ابزار اجرایی هوش مصنوعی همکاری می‌کند، برنامه‌ریزی و ساخت یک نمونه اولیه کمتر از یک ساعت زمان می‌برد. وقتی هزینه یک آزمایش تا این حد به صفر نزدیک می‌شود، دیگر منطقی نیست که از مرحله نمونه‌سازی پرش کنیم. اکنون استفاده از زمان برای ساخت یک نمونه اولیه و به‌کارگیری شواهد حاصل از آن برای تدوین یک برنامهٔ آگاهانه برای نرم‌افزاری که قرار است به دست کاربران برسد، بسیار ارزشمندتر است.
گردش‌کار نمونه‌سازی
این گردش‌کار مهارت‌های خاص عوامل (Agent Skills) را برای ساده‌سازی فرآیند ترکیب می‌کند. این رویکرد مانند یک «اسپایک» (Spike) در متدولوژی چابک (Agile) عمل می‌کند، با این تفاوت که به‌جای اسپایک کردن یک ویژگی ریسکی، توسعه‌دهنده کل سیستم را اسپایک می‌کند تا شکل واقعی و مشخصات دقیق پروژه را بیاموزد.
توسعه‌دهندگان این مراحل را دنبال می‌کنند:
- نوشتن ۵ نکته کلیدی (Bullet points) دربارهٔ ساخت مورد نظر در یک فایل
REQS.md(نیازمندی‌ها). - اجرای مهارت عامل برنامه‌ریزی نمونه‌ساز (Prototype-plan agent skill).
- صرف حدود ۱۵ دقیقه برای پاسخ به سؤالات مصاحبه.
- تولید دو سند کلیدی:
PRD.md(سند نیازمندی‌های محصول) وIMPL.md(برنامه پیاده‌سازی). - ساخت سریع نمونه اولیه در اسرع وقت برای آشکار کردن آنچه واقعاً باید در برنامهٔ تولیدی گنجانده شود.
جزئیات پیاده‌سازی
پس از ساخت نمونه اولیه، توسعه‌دهنده از شواهد به‌دست‌آمده از برنامهٔ در حال اجرا برای اطلاع‌رسانی به نسخه تولیدی استفاده می‌کند. این کار، تجربه عملی را جایگزین تخیل و حدس و گمان می‌کند. این هدف با اجرای مهارت‌های خاص در ابزارهایی مانند Claude Code، OpenCode، Pi یا Codex محقق می‌شود:
- مهارت عامل برنامه‌ریزی نمونه‌ساز (Prototype-plan): ابتدا برای برنامه‌ریزی نسخه سطح نمونه‌ساز استفاده می‌شود.
- مهارت عامل برنامه‌ریزی محصول (Build-plan-product): برای آغاز برنامه‌ریزی نسخه سطح تولیدی به کار می‌رود.
- مهارت عامل برنامه‌ریزی مشخصات (Build-plan-specs): برای نهایی کردن مشخصات فنی سطح تولیدی استفاده می‌شود.
با دنبال کردن این ترتیب، توسعه‌دهنده پیش از تعهد به یک برنامهٔ نگهداری بلندمدت، «لبه‌های تیز» (نقاط حساس و دشوار) برنامه را شناسایی می‌کند.
محدودیت‌های نمونه‌سازی
با این حال، نمونه‌های اولیه محدودیت‌های واضحی دارند. یک هشدار صادقانه این است که یک نمونه اولیه موارد زیر را آشکار نخواهد کرد:
- محدودیت‌های مقیاس‌پذیری (Scaling limits)
- مدل‌های امنیتی (Security models)
- تعهدات انطباق قانونی (Compliance obligations)
- مسیرهای مهاجرت از سیستمی که قرار است جایگزین شود
این مسائل با ریسک بالا در نمونه‌های اولیه ظاهر نمی‌شوند و هیچ مصاحبه ۱۵ دقیقه‌ای نمی‌تواند آن‌ها را پیدا کند. به همین دلیل است که این دو درجه برنامه‌ریزی مجزا باقی می‌مانند. نمونه اولیه به شما می‌گوید «چه چیزی» بسازید؛ برنامه تولیدی تضمین می‌کند که آن محصول «ماندگار» باشد.
برای توسعه‌دهنده مدرن، ترتیب عملیات تغییر کرده است. شما دیگر برای جلوگیری از اشتباهات برنامه‌ریزی نمی‌کنید؛ بلکه یک نمونه اولیه می‌سازید تا کشف کنید اشتباهات کجا هستند، و سپس نسخه تولیدی را برای رفع آن‌ها برنامه‌ریزی می‌کنید. این تغییر، ریسک ساخت محصولی که از نظر مشخصات کامل است اما هیچ‌کس واقعاً آن را نمی‌خواهد، کاهش می‌دهد.
برای شروع این فرآیند، یک ویژگی محوری را شناسایی کنید و همین امروز یک فایل نیازمندی‌های حداقلی پیش‌نویس کنید.
گفتگو