تصور کنید دیگر لازم نباشد ساعتها روی نوشتن مستندات فنی یا کدنویسی تکراری وقت بگذارید و فقط نقش یک بازرس سختگیر را داشته باشید. در ۲۲ سپتامبر ۲۰۲۶، پیادهسازی دقیقی از AI-DLC (چرخهٔ توسعهٔ نرمافزاری هوش مصنوعی) نشان داد که چرخهٔ سنتی توسعهٔ نرمافزار نمرده است، اما بازیگران آن تغییر کردهاند.
برای دههها، چرخهٔ توسعهٔ نرمافزار (SDLC) به برنامهنویسان انسانی وابسته بود تا پروژه را به صورت دستی از مرحلهٔ نیازسنجی به استقرار برسانند. این فرآیند اغلب دچار «انحراف رویهای» (Process Drift) میشد؛ یعنی تیمها برای رسیدن به ضربالاجلها، مستندات را نادیده میگرفتند یا نقاط بازرسی (Checkpoints) را دور میزدند. مدل AI-DLC با گنجاندن حاکمیت سیستمی مستقیماً در معماری سیستم، این مشکل را حل میکند.
در این سیستم، شما یک «قصد» (Intent) کلی را به زبان ساده و انگلیسی بیان میکنید و یک عامل (Agent) — شبیه به یک دستیار اجرایی که تمام جزئیات اداری را میداند و اجرا میکند — کارهای خستهکننده مثل شکستن نیازها به داستانهای کاربر (User Stories)، طراحی زیرساخت و تولید کد را بر عهده میگیرد. شما دیگر نویسندهٔ مستندات نیستید؛ شما صرفاً آنها را بازبینی و تایید میکنید. این تغییر، نقش برنامهنویس را از «نویسندهٔ کد» به «بازبین مصنوعات فنی» تبدیل میکند. این گذار در حالی رخ میدهد که برخی مهندسان نرمافزار به دلیل مدیریت پیچیده ابزارهای هوش مصنوعی، کاهش رضایت شغلی را تجربه کردهاند، اما AI-DLC سعی دارد با ساختارمند کردن این فرآیند، فشار را کاهش دهد.
همانطور که در تحلیلهای قبلی ما دربارهی امنیت مدلهای بازمتن اشاره کردیم، سپردن کنترل به ماشین نیازمند حفاظهای سختگیرانه است. در AI-DLC، برای جلوگیری از توهم (Hallucination) — وقتی مدل با اطمینان چیزی میگوید که اصلاً وجود ندارد — و همچنین جلوگیری از گسترش بیرویه محدوده پروژه (Scope Creep)، کارها به یک سلسلهمراتب دقیق تقسیم شدهاند:
- قصدها (Intents): هدف سطح بالای پروژه که توسط کاربر انسانی با کلمات خودش بیان میشود.
- واحدها (Units): وظایف بزرگ در سطح اپیک (Epic) که دارای معیارهای پذیرش (Acceptance Criteria) و وابستگیهای تعریف شده هستند. اینها واحدهای اصلی کار محسوب میشوند.
- پیچها (Bolts): چرخههای اجرایی که از چند ساعت تا چند روز طول میکشند و شبیه به اسپرینتهای کوچک عمل میکنند. یک پیچ تا زمانی که حتی یکی از واحدهای تشکیلدهنده آن در یک مرحلهٔ اجباری تایید نشده باشد، نمیتواند بسته شود.
به نقل از گزارش dev.to، مدل AI-DLC یک چرخهٔ جدید اختراع نمیکند، بلکه SDLC کلاسیک را در ۱۶ مرحله بازسازی میکند که در سه فاز کلی گروهبندی شدهاند: آغازین $\rightarrow$ ساخت (به ازای هر واحد) $\rightarrow$ عملیات.
فاز آغازین (Inception)
این فاز شامل مراحل زیر است:
- شناسایی محیط کاری (Workspace Detection): شناسایی محیط و فضای پروژه.
- تحلیل نیازها (Requirements Analysis): جمعآوری نیازهای هستهای پروژه.
- داستانهای کاربر (User Stories): تعریف اهداف کاربر-محور.
- برنامهریزی گردش کار (Workflow Planning): ترسیم مسیر پیش رو.
- تولید واحدها (Units Generation): شکستن «قصد» به قطعات قابل مدیریت.
- برنامهریزی تحویل (Delivery Planning): زمانبندی خروجیها.
فاز ساخت (Construction)
این فاز برای هر واحد بهطور مجزا اجرا میشود و شامل مراحل زیر است:
- طراحی اپلیکیشن (Application Design): معماری سطح بالای سیستم.
- طراحی عملکردی (Functional Design): جزئیات نحوه عملکرد ویژگیها.
- طراحی زیرساخت (Infrastructure Design): برنامهریزی نیازهای سختافزاری یا ابری.
- نیازها و طراحی NFR: مدیریت نیازهای غیرعملکردی (مانند امنیت و مقیاسپذیری).
- برنامهریزی تولید کد (Code Generation Planning): ترسیم نقشه پیادهسازی.
- تولید کد (Code Generation): نوشتن واقعی نرمافزار.
- ساخت و تست (Build and Test): تایید اینکه کد طبق قصد اولیه کار میکند.
فاز عملیات (Operations)
شامل مراحل نهایی است:
- استقرار (Deployment): انتشار کد در محیط عملیاتی (Production).
- عملیات / مشاهدهپذیری (Ops / Observability): اطمینان از سلامت سیستم.
- نظارت (Monitoring): ردیابی مستمر عملکرد.
برای جلوگیری از تغییرات غیرمجاز توسط عاملها، سیستم تفکیک شدیدی میان مراحل ایجاد کرده است. مراحل طراحی و تحلیل در حالت «فقط خواندنی» (Read-only) برای برنامهریزی عمل میکنند. اجازهٔ نوشتن فایلها منحصراً به مراحل اجرایی مثل تولید کد، ساخت و تست، استقرار و نظارت داده شده است.
این ساختار شبیه به قانون حرفهای است که بازبین نمیتواند درخواست ادغام (Pull Request) خودش را تایید کند. در این معماری، هیچ فرآیند اجرایی (Runner) حاوی کدی نیست که بتواند وضعیت را به «تایید شده» تغییر دهد؛ این اقدام مستلزم یک درخواست HTTP دستی است که توسط انسان آغاز شود. این موضوع در سطح معماری سیستم اجباری شده است، نه از طریق دستورالعملهای اداری.
بر اساس مستندات فنی، این پیادهسازی از دو مجری (Executor) متمایز برای مدیریت انواع وظایف استفاده میکند:
- مجری Claude: عملیات خودمختار را در محیط کاری یک قصد خاص مدیریت میکند، بهویژه برای مراحلی که نیاز به دسترسی خواندن/نوشتن در مخزن (Repository) دارند.
- مجری Ask: کاربر را مجبور میکند تا از طریق یک ارائهدهنده پیکربندی شده، فرمی را برای شفافسازی انسانی پر کند (مثلاً پاسخ به سوالات شفافساز یا تایید لیست واحدهای پیشنهادی).
برای انعطافپذیری بیشتر، خروجی مراحل را میتوان به صورت دستی از طریق نقطه اتصال PUT /stages/:id/output وارد کرد. این یعنی حتی بدون پیکربندی هوش مصنوعی، فرآیند همچنان قابل اجراست.
مدیریت یکپارچگی دادهها توسط DynamoDB انجام میشود که به عنوان منبع واحد حقیقت (Source of Truth) عمل میکند. این موضوع حیاتی است زیرا ممکن است یک اپلیکیشن وب و یک عامل متصل به MCP بهطور همزمان داده بنویسند؛ DynamoDB از عملیات بهروزرسانی شرطی (Conditional Update) پشتیبانی میکند تا از تداخل وضعیت در اجراهای همزمان جلوگیری شود.
یک نسخهٔ آینهای و فقط-خواندنی از این وضعیت در فایلهای Markdown در مسیر aidlc-docs/<intent-slug>/ در مخزن هدف نگهداری میشود. این شامل یک فایل audit.md است که تمام اجراها، تاییدها، درخواستهای تغییر و مراحل نادیده گرفته شده را ثبت میکند. در SDLC سنتی، مستندات رکورد اصلی بودند؛ اما اینجا دیتابیس رکورد اصلی است و مستندات تنها آینهای از آن هستند.
در پیادهسازی این مدل، برخی انحرافات آگاهانه نسبت به متدولوژی AWS اعمال شده تا با قابلیتهای واقعی سیستم سازگار شود:
- ذخیرهسازی وضعیت: در حالی که متدولوژی اصلی پیشنهاد استفاده از
aidlc-state.mdرا میداد، این سیستم از DynamoDB استفاده میکند زیرا یک فایل Markdown نمیتواندConditionExpressionلازم برای چندین نویسنده همزمان را پیاده کند. - منطق مجری: مراحلی که به شکل فرم هستند، مستقیماً از طریق مجری 'ask' روی ارائهدهنده LLM اجرا میشوند تا دسترسی نوشتن فایل از مراحلی که به آن نیاز ندارند، گرفته شود.
- همکاری: مدل «تدوین جمعی» (Mob Elaboration) که یک بررسی گروهی همزمان بود، با یک مدل «تکنفره» جایگزین شد که دارای لیست واحدهای قابل ویرایش و قابلیت درخواست تغییر (Request-changes) است.
- محدوده: مشخصات اصلی دارای ۳۳ مرحله در ۵ فاز بود؛ اما این پیادهسازی از ۱۶ مرحله در ۳ فاز استفاده میکند. از آنج که کاتالوگ دادهمحور است، میتوان آن را بدون نوشتن کد جدید گسترش داد.
- تایید: به جای اختیار ضمنی، سیستم از رکوردهای
approvedByبرای ردیابی شخص اقدامکننده استفاده میکند، زیرا اپلیکیشن به جای حسابهای احراز هویت شده، از پروفایلها استفاده میکند.
این سیستم با الهام از دستورالعملهای Anthropic (که یک مدل شش مرحلهای شامل برنامهریزی $\rightarrow$ طراحی $\rightarrow$ توسعه $\rightarrow$ تست $\rightarrow$ استقرار $\rightarrow$ پشتیبانی را تعریف میکند)، سه لایهٔ حاکمیتی پیشرفته اضافه کرده است:
- مهارتها (Skills): فایلهای سیاستگذاری مبتنی بر Markdown (مانند چکلیستهای امنیتی یا قوانین انطباق) که در محیط کاری قرار میگیرند. اینها بهطور خودکار به عنوان زمینه (Context) به مراحلی مثل
nfr_designوdeploymentبه عنوان دستورالعملهای مشورتی متصل میشوند. - قلابها (Hooks): دستورات شل (Shell) قطعی که از طریق متغیر
AIDLC_POST_RUN_HOOKبعد از تولید کد یا تست، اما قبل از وضعیت «در انتظار تایید» اجرا میشوند. هر کد خروجی غیرصفر (Non-zero exit code) باعث شکست فوری مرحله میشود و به عنوان یک حفاظ سخت عمل میکند. - تاییدیه (Verification): تحلیل مبتنی بر AI روی تغییرات کد (Diffs) در مرحله تولید کد و نتایج موفقیت/شکست در مرحله تست. این بررسیها صرفاً مشورتی هستند تا این اصل حفظ شود که هیچ مجریای نمیتواند کار خودش را تایید کند.
برای اطمینان از اینکه سیستم در طول بهروزرسانیها دچار اختلال نمیشود، از یک مجموعه ارزیابی (Evaluation Suite) استفاده میشود. تستهای موجود در apps/api/tests/*.eval.ts تایید میکنند که پرامپتهای هر مرحله با «قصد»های تعریف شده در دادههای تست همراستا هستند. این کار مانع از آن میشود که تغییر در پرامپتها یا ساختار پوشهها، مکانیسمهایی مثل شناسایی محیط کاری را در فاز CI بهطور خاموش خراب کند.
یکی از تصمیمات کلیدی و انحرافات از دستورالعمل اصلی، امتناع از خودکارسازی ادغام (Merge) در گیت است. هرچند سیستم میتواند از AIDLC_PARALLEL_WORKTREES برای اختصاص یک Worktree و شاخه (Branch) مجزا به هر واحد برای ایزولاسیون کامل ساخت استفاده کند، اما ادغام نهایی در تاریخچه اصلی (Main History) حتماً باید یک اقدام دستی انسانی باشد. ادغام خودکار حساستر از آن است که به یک مجری مرحله سپرده شود.
علاوه بر این، نقطه اتصال POST /aidlc/alerts با ایجاد یک «قصد» استاندارد پیشنویس بر اساس هشدار سیستم نظارتی، حلقه عملیاتی را میبندد. با این حال، این قصد تولید شده همچنان باید وارد خط لوله شود، از مرحله شناسایی محیط عبور کند و تمام بررسیهای اعتبارسنجی استاندارد را پیش از اجرا طی کند.
تحلیل: تغییر در ارزش برنامهنویس
این گذار، ماهیت بنیادی «بدهی فنی» (Technical Debt) را تغییر میدهد. وقتی AI بخش اعظم مصنوعات را تولید میکند، ریسک از «خطاهای کدنویسی» به «خطاهای نیازمندی» منتقل میشود. اگر انسان یک سند طراحی معیوب را تایید کند، هوش مصنوعی یک سیستم معیوب را بهطور کامل و بینقص پیادهسازی خواهد کرد.
برای برنامهنویس، ارزش پیشنهادی از «دانستن نحو (Syntax) زبان» به «دانستن نحوه حسابرسی (Audit)» تغییر میکند. توانایی شناسایی یک نقص معماری ظریف در یک طراحی تولید شده توسط AI، بسیار ارزشمندتر از توانایی نوشتن کدهای تکراری (Boilerplate) میشود. این رویکرد در واقع گامی به سوی ساخت سیستمعاملهای هوش مصنوعی است که جایگزین پرامپتهای تکمرحلهای در SaaS میشوند تا مدیریت چرخه حیات نرمافزار به صورت یکپارچه صورت گیرد.
این مدل نشان میدهد که آینده مهندسی، ناپدید شدن SDLC نیست، بلکه خودکارسازی سختگیرانه آن است. با جایگزینی انضباط انسانی با بلوکهای سیستمی، تیمها میتوانند پوشش ۱۰۰ درصدی مستندات و قابلیت حسابرسی را بدون کاهش سرعت اجرا تضمین کنند.
برای مشاهده این سیستم در عمل، میتوانید پیادهسازی عاملهای متصل به MCP را بررسی کنید که شکاف بین برنامهریزی سطح بالا و اجرای مخزن را پر میکنند.
گام بعدی شما
- بررسی پروتکل MCP برای اتصال عاملهای برنامهنویس به محیطهای توسعهٔ محلی.
- تعریف چکلیستهای امنیتی در قالب فایلهای Markdown برای استفاده در لایهٔ Skills.
- تمرین بازبینی کدهای تولید شده توسط AI با تمرکز بر خطاهای معماری به جای خطاهای سینتکسی.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو