مدیریت وضعیت در SDLC؛ تنها راه مقیاس‌بندی مهندسی هوش مصنوعی ترکیبی

اگر هنوز کدها را با پرامپت‌های پراکنده به هوش مصنوعی می‌سپارید و امیدوارید نتیجه درست باشد، در واقع در حال انجام یک قمار هستید، نه مهندسی. باید بدانید که سرعت تولید کد توسط مدل‌ها دیگر گلوگاه نیست؛ بلکه توان عملیاتیِ بررسی و بازبینی کد است که مانع مقیاس‌پذیری پروژه‌ها می‌شود. نویسنده در گزارش خود در وب‌سایت dev.to استدلال می‌کند که فقدان مشخصات رسمی منجر به «انحراف قصد» (Intent Drift) می‌شود؛ وضعیتی که در آن هوش مصنوعی ظاهرِ دقت (مانند نوشتن READMEها و docstringها) را ایجاد می‌کند، اما بدون اینکه تصمیمات معماری واقعی در پس آن باشد.

این چالش دقیقاً همان جایی است که مفهوم چرخه توسعه نرم‌افزار (SDLC) — یعنی همان نقشه راهی که هر ویژگی از یک ایده به کد تبدیل می‌شود — ارزش واقعی خود را پیدا می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، بدون یک ساختار نظارتی، پیشرفت‌های سریع فنی به بدهی‌های فنی غیرقابل مدیریت تبدیل می‌شوند. در دنیای امروز، بسیاری از توسعه‌دهندگان دچار وضعیت کدنویسی بر اساس حس (Vibe Coding) شده‌اند؛ یعنی نوشتن پرامپت و امید به صحت خروجی، بدون داشتن یک سند مرجع برای سنجش. این تغییر رویکرد در کنار تمایل توسعه‌دهندگان به جایگزینی محیط‌های توسعه سنگین با ابزارهای سبک‌تر مبتنی بر هوش مصنوعی، نشان‌دهنده دگرگونی عمیق در متدولوژی‌های برنامه‌نویسی است. در واقع، هوش مصنوعی جایگزین SDLC نمی‌شود، بلکه باعث می‌شود این فرآیند ارزشمندتر گردد.

برای اثبات این موضوع، یک مهندس با ۲۵ سال تجربه در مهندسی نرم‌افزارهای مقیاس جهانی (planet-scale)، در یک آخر هفته از جولای ۲۰۲۶، کتابخانه‌ای به نام loopguard را ساخت که یک کتابخانه «قطع‌کننده» (circuit-breaker) برای حلقه‌های عوامل هوش مصنوعی (LLM agent loops) است. این رویکرد در حالی توسعه یافت که برخی از پیشرفته‌ترین عامل‌های کدنویس هوش مصنوعی در سال ۲۰۲۶ به طور گسترده در حال ارسال کدهای عملیاتی به محیط تولید هستند. او با قرار دادن عوامل هوش مصنوعی در هر وضعیت از یک خط لوله سنتی، به سطحی از موازی‌سازی دست یافت که در آن عوامل در یک پنجره ویژگی‌ها را پیاده‌سازی می‌کردند، در حالی که انسان در پنجره‌ای دیگر در حال اولویت‌بندی باگ‌ها بود، بدون اینکه هیچ همگام‌سازی مسدودکننده‌ای (blocking synchronization) رخ دهد.

او برای این کار از یک ماشین وضعیت سخت‌گیرانه استفاده کرد: «مسئله $\rightarrow$ PRD $\rightarrow$ SPEC $\rightarrow$ WBS $\rightarrow$ Issues $\rightarrow$ پیاده‌سازی $\rightarrow$ بازبینی $\rightarrow$ انتشار». در این مدل، هر مرحله یک مصنوع (Artifact) ماندگار و قابل ارجاع تولید می‌کرد که جزئیات آن به شرح زیر است:

• سند نیازمندی‌های محصول (PRD): یک یادداشت ۷۶۵ خطی که تعریف می‌کرد چه چیزی در حال ساخت است. این سند شامل «شناسه‌های پایدار» (مثلاً FR-1.1 برای نیازمندی‌ها و NG3 برای اهداف غیرضروری یا Non-goals) بود که به عنوان کلیدهای پیوند (join-keys) بین PRD و مراحل بعدی عمل می‌کردند.
• سند مشخصات فنی (SPEC): یک قرارداد ۱۲۴۳ خطی برای پیاده‌کننده. این سند نیازمندی‌های سطح بالا را به شبه‌کد و مدل‌های داده تبدیل کرد و پرسش‌های باز (OQ-1 تا OQ-10) را به طور کامل پاسخ داد.
• ساختار شکست کار (WBS): یک گراف وابستگی ۱۱۳۴ خطی متشکل از ۲۷ نقطه عطف (Milestone). این گراف مشخص می‌کرد کدام وظایف می‌توانند به صورت موازی اجرا شوند و بر اساس پیچیدگی هر وظیفه، مدل‌های خاصی را به آن اختصاص می‌داد.

در این مدل، WBS مانند یک تنظیم‌کننده روتر عمل می‌کرد. به جای استفاده از یک مدل پیشرو (Frontier Model) برای همه کارها، از یک استراتژی «آبشاری» برای بهینه‌سازی هزینه و کیفیت استفاده شد:

• GLM 5.2: برای «کارهای قضاوتی» مانند تدوین PRDها، طراحی SPEC و بازبینی نهایی کد رزرو شده بود.
• DeepSeek-V4-Flash: برای «الگوهای مکانیکی» مانند ایجاد اسکلت‌بندی (scaffolding) و پیاده‌سازی مدل‌های داده به کار رفت.
• OMLX qwen2.5-coder:7b: یک مدل محلی که برای کدهای تکراری (boilerplate)، کارهای مربوط به رابط خط فرمان (CLI) و تست‌های عملکرد استفاده شد.

نتیجه‌ی تکان‌دهنده‌ی این روش در مرحله‌ی بازبینی مشخص شد. نویسنده ۲۶ باگ را در دو دور بازبینی شناسایی کرد. نکته کلیدی این بود که هیچ‌کدام از این باگ‌ها مربوط به ترجیحات ظاهری یا استایل کد نبودند؛ بلکه تمام آن‌ها خطاهای طراحی اساسی بودند که مستقیماً با ارجاع به بخش‌های سند SPEC شناسایی شدند. برخی از شکست‌های رایج یافت شده عبارت بودند از:

• وضعیت اشتراکی (Shared GuardState): یک باگ کلاسیک در سیستم‌های توزیع‌شده که در آن وضعیت بین وظایف نشت می‌کرد و بخش ۲.۲ سند SPEC را نقض می‌نمود.
• مشکلات هم‌روندی (Concurrency): افزایش‌های غیر-اتومیک در شمارنده تشدید (escalation count) که ناقض بخش ۹.۳ سند SPEC بود.
• منطق پیکربندی: مقادیر سخت‌افزا شده (Hardcoded) که فایل‌های پیکربندی ارائه شده را نادیده می‌گرفتند.

یک مورد جالب در Issue #45 رخ داد؛ جایی که عامل (Agent) از سند SPEC فاصله گرفت تا طراحی بهتری ارائه دهد. چون سند SPEC وجود داشت، این انحراف کاملاً مشهود بود و انسان توانست آگاهانه آن را بررسی کرده، تأیید کند و سپس سند را اصلاح نماید. بدون وجود SPEC، چنین حرکتی از یک باگ قابل تشخیص نبود.

به دلیل اینکه خروجی هر مرحله با یک فیلد وضعیت در Git ثبت می‌شد، انسان و هوش مصنوعی هرگز نیاز به جلسات هماهنگی یا Briefing نداشتند. نویسنده می‌توانست PRD نسخه ۰.۲.۰ را ویرایش کند، در حالی که یک عامل تست‌های واحد S3 را می‌نوشت و عاملی دیگر وظایف S6 را پیش‌نویس می‌کرد. این موازی‌سازی ایمن بود چون به جای تکیه بر تاریخچه چت‌ها یا حافظه کوتاه مدت مدل، بر «وضعیت مشترک و سازگار» (consistent state) متکی بود.

با این حال، نویسنده در تحلیل «چه چیزی دشوار بود»، اشاره می‌کند که بازبینی همچنان گلوگاه اصلی است. انسان باید همچنان وظایف را اولویت‌بندی، دسته‌بندی (triage) و اصلاحات را تأیید کند که زمان‌برترین بخش این حلقه است. علاوه بر این، فرمت فعلی انتقال داده‌ها (Markdown) شکننده است. سیستم به انضباط انسانی تکیه دارد تا مطمئن شود یک نقطه بازرسی (مثلاً pytest --cov-fail-under=90) واقعاً پاس شده است و سپس وضعیت به «تأیید شده» تغییر کند.

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

برای تکامل بیشتر این روند، نویسنده چهار ارتقای فنی را پیشنهاد می‌کند:

1. تشخیص خودکار انحراف از مشخصات: ابزارهای CI که شبه‌کدهای SPEC و درخت نحو (AST) پیاده‌سازی را تجزیه کرده و شکاف‌های ساختاری را علامت‌گذاری کنند.
2. اسکیماهای وضعیت ساختاریافته: جایگزینی Markdown با فایل‌های جانبی JSON برای اینکه انتقال داده‌ها توسط ماشین قابل بررسی باشد.
3. درگاه‌های اجباری (Enforced Gating): ادغام جداول نقاط بازرسی مستقیماً در درگاه‌های ادغام (merge gates) در CI.
4. خود-بازبینی عامل: مجبور کردن عامل به اینکه پیش از ارسال PR، لیستی از تمام بخش‌های SPEC که ممکن است توسط تغییرات (diff) نقض شده باشند، ارائه دهد.

در نهایت، SDLC سنتی با تبدیل شدن به لایه هماهنگی که مانع از فروپاشی «کدنویسی بر اساس حس» زیر فشار بدهی‌های فنی می‌شود، بقای خود را در عصر هوش مصنوعی تضمین کرد. مبانی مهندسی — قراردادها، درگاه‌ها و نیازمندی‌های ردیابی‌پذیر — اکنون حیاتی‌تر از ۲۵ سال پیش هستند.

گام بعدی شما

• جایگزینی Markdown با JSON برای انتقال داده‌ها میان عامل‌ها جهت بررسی ماشینی.
• پیاده‌سازی ابزارهای CI برای تشخیص خودکار فاصله بین کد و سند SPEC.
• اجباری کردن «خود-بازبینی» عامل‌ها برای لیست کردن بندهای SPEC پیش از ارسال PR.

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