حکایت است که پیری در رهی، جوانی را خیره به افق یافت که هر از گاهی آهی از نهان برون می‌دمید و تن خویش می‌خاراند! پیر بدو گفت ای جوان، درهمی تو را بخشم تا راهی حمام شوی بلکه کمتر از خارش رنج بَری! اما جوان رو به پیر کرد و گفت: ای پیر خردمند، خارِش من نِی از باب ابتلا به شپش و کثافت است، بَل از سر پرسشی عمیق و بس گران است. پیر بدو گفت: چگونه پرسشی است که تو را اینچنین مسحور خویش ساخته؟ جوان گفت: همان‌گونه که می دانی امروزه عصر هوشواره است؛ ولی همچو منی که گَوَزن و شقیقه را به یکدیگر مرتبط می‌سازم؛ هر چه می‌اندیشم راه گذار از راه و رسم کُهَن توسعه نرم‌افزار به صورت امروزی آن را نمی‌یابم. پیر بدو گفت: به خدا سوگند اگر خورشید را در دستانم بگذاری؛ با این شیوه‌ی نگارش، همچو منی هم نتوانستن شرح دادن؛ پس ادامه‌اش را به زبان امروز بخوان…

ما چند دهه برای توسعه نرم‌افزار فرآیند، نقش، ابزار و تقسیم مسئولیت ساختیم. Product Requirement داریم، Design داریم، Development داریم، QA داریم، Release و Operation داریم. ولی یهو در مدت کوتاهی AI وارد شد؛ چیزی که می‌تونه Requirement رو بخونه، Code رو بنویسه، Test رو تولید کنه، Logها رو تحلیل کنه، PR رو Review کنه، Documentation رو بنویسه و حتی ابزارهای مختلف رو هم صدا بزنه و باهاشون تعامل داشته باشه.

حالا دیگه پرسش اصلی این نیست که: «آیا AI می‌تونه کد بنویسه؟» چون جوابش مشخصه: بله، می‌تونه. سوال مهم اینه که آیا منطقیه که همون Software Development Lifecycle قبلی رو بدون تغییر نگهش داریم و صرفا یک AI Assistant کنار Developer بچسبونیم؟

۱. «راه و رسم کهن» چی بود؟

اگر خیلی ساده کنیم، سال‌هاست چیزی نزدیک به این داریم:

flowchart TD
    A[Requirements] --> B[Analysis / Design]
    B --> C[Implementation]
    C --> D[Testing]
    D --> E[Release]
    E --> F[Operate / Maintain]

یا یه مقدار کامل‌تر و دقیق‌ترش:

---
config:
  theme: 'base'
  themeVariables:
    fontFamily: 'Estedad'
  themeCSS: |
    .node .label {
      text-align: right !important;
      direction: rtl !important;
    }
---
flowchart TD
    A["۱. برنامه‌ریزی و نیازسنجی<br/>مشخص کردن اهداف، نیازها و محدوده پروژه"]
    B["۲. تحلیل<br/>بررسی دقیق نیازمندی‌های فنی و کسب‌وکار"]
    C["۳. طراحی<br/>طراحی معماری، دیتابیس و رابط‌های سیستم"]
    D["۴. توسعه<br/>پیاده‌سازی و برنامه‌نویسی"]
    E["۵. تست<br/>بررسی کیفیت، عملکرد و رفع باگ‌ها"]
    F["۶. استقرار<br/>انتشار نرم‌افزار در محیط عملیاتی"]
    G["۷. نگهداری<br/>پشتیبانی، رفع مشکلات و بهبود مستمر"]

    A --> B
    B --> C
    C --> D
    D --> E
    E --> F
    F --> G
    G -->|نیازها و <br/>بهبودهای جدید| A

این مدل البته الزاماً Waterfall نیست. تیو Agile همین فعالیت‌ها طی چرخه‌های کوچک‌تر و موازی‌تر اتفاق می‌افتن. اما نکته اینه که AI هیچ‌کدوم از این نیازها رو حذف نکرده. و هنوز هم باید بدونیم:

• چه چیزی رو می‌خواهیم بسازیم؟
• چرا؟
• چه محدودیت‌هایی داریم؟
• طراحی مناسب چیه؟
• از کجا بفهمیم درست کار می‌کنه؟
• چجوری Deploy می‌شه؟
• اگه خراب شد چه کسی می‌فهمه و چه کسی مسئوله؟

تیم‌های نرم‌افزاری کمتر و بیشتر چنین فرایندی رو طی می‌کردن؛ اینجا و توی این مطلب، کاری به اینکه توی هر کدوم از این مراحل چه چیزهایی رو باید یا نباید انجام می‌دادن، یا مولفه‌هایی که باعث می‌شد کیفیت یا کارآمدی لازم رو نداشته باشن، ندارم.

ولی حالا AI اومده و جای خودش رو بین تیم پروداکت، تیم توسعه، و سایر تیم‌های دخیل در محصول نهایی باز کرده؛ و سوال یک میلیون دلاری اینه که آیا SDLC منسوخ شده؟ پاسخ: SDLC منسوخ نشده.

مسئله این نیست که حالا چون AI اومده، دیگه Requirement و Design و Test دیگه لازم نیست. اتفاقا شاید مهم‌تر هم شدن. سوال درست اینه که آیا مرز مسئولیت‌ها و نقش‌های مختلف و چیزهایی که دست‌به‌دست می‌کنن بین هم (hand-offها)؛ که تقریبا همه برای دنیای فقط-آدمیزاد طراحی شده بود؛ کماکان بهینه است؟

مثلا قبلا Developer منتظر Product بود. QA منتظر build بود. Ops منتظر Developer بود. ولی حالا AI می‌تونه بخشی از این انتظارها رو تغییر بده، و آیا چیزهایی که به هم دیگه می‌دن، همون شکل و شمایلیه که قبلا داشت؟ یا فرض کنید AI باعث می‌شه Developer سه برابر سریع‌تر کد بنویسه:

flowchart TD
    A[Requirements] --> B[Design]
    B --> C[Coding ← 3x faster]
    C --> D[Review]
    D --> E[QA]
    E --> F[Release]

حالا آیا کل Delivery سه برابر سریع‌تر شده؟ نه لزوما. چون Developer هنوز ممکنه یه روز منتظر شفاف‌سازی نیازها از سمت Product باشه. Reviewer حالا باید به جای ۳۰۰ خط، ۳۰۰۰ خط تغییر رو بررسی کنه. یا QA هنوز منتظره تا محیط تست آماده بشه. یا Release همچنان هفته‌ای یه بار انجام بشه. همین‌طور Production Incident همچنان بررسی و تحلیل بخواد. این همون خطر Local Optimization است.

Code Generation Productivity ≠ Developer Productivity ≠ Team Productivity ≠ Software Delivery Performance ≠ Business Outcome

حتی یک مطالعه‌ی کنترل‌شده‌ی METR توی سال ۲۰۲۵ نشون داده Developerهای باتجربه‌ی Open Source روی repositoryهایی که خودشان به‌خوبی می‌شناختنشون، پیش‌بینی می‌کردن که AI بتونه سریع‌ترشون کنه. حتی بعد از انجام کار هم تصور می‌کردن حدود ۲۰ درصد سریع‌تر شدن. ولی توی آزمایش مشخص، زمان واقعی انجام تسک‌ها با AI حدود ۱۹ درصد بیشتر بوده (و نه کمتر)! خود افراد دخلی در پژوهش هم صریحا هشدار دادن که این نتیجه رو نباید به همه دولوپرها، تمام پروژه‌ها یا همه‌ی نسل‌های AI تعمیم داد. ولی نکته‌ی مهم برای بحث ما چیز دیگری‌ایه: احساس بهره‌وری لزوما معادل بهره‌وری اندازه‌گیری‌شده نیست.

۲. مرور اجمالی سیر تکامل AI Development (از Chat تا Agent)

برای فهمیدن اینکه Spec-Driven Development از کجا سر و کله‌اش پیدا شد، بد نیست خیلی سریع چند سال اخیر رو مرور کنیم. همه این تحولات؛ از ۲۰۲۲ تا الان طی شده؛ این همه تغییر، نوآوری، بهبود فقط طی ۴ سال از پیشِ‌روی چشم ما و صنعت گذشته.

اول Chat داشتیم:

Question → LLM → Answer

بعد Prompt Engineering اومد؛

فهمیدیم اینکه چجوری درخواست کنیم، روی کیفیت جواب خروجی تاثیر می‌گذاره.

Better Prompt → Better Probability of a Useful Answer

بعد خیلی زود فهمیدیم که فقط Prompt بهتر، کافی نیست. یلکه مدل باید درباره‌ی سیستم ما هم بدونه.

Context Engineering

Prompt + Codebase + Documentation +Architecture + Business Data + Conventions + History

Tools / MCP

بعد Tool Use و MCP و ابزارهای مشابه جدی‌تر شدند. چون مدل دیگه فقط حرف نمی‌زد، بلکه می‌تونست عمل هم کنه.

LLM → Read repository → Run command → Query database → Call API → Change files

Skills

بعدش Skillها جدی شدن. یعنی آموزه‌ها و دستورالعمل‌های تکرارشونده‌ای که به Agent می‌گن توی یک موقعیت مشخص چجوری رفتار کنه.

Reusable procedural knowledge

Agent Loop

Prompt به Context رسید، Context به Skill یا procedural knowledge رسید، و بعد Agent تونست با Toolها در Loop حرکت کنه

Goal
↓
Think (Reason)
↓
Use Tool
↓
Observe Results
↓
Repeat (Reason Again)

حالا اینجا وقتی به Agent می‌گین: “Investigate and fix this bug.” خودش ممکنه:

• Code را بخونه
• Log رو بررسی کنه
• Git history رو ببینه
• Test ها رو اجرا کنه
• فایل رو بر حسب نیاز تغییر بده
• دوباره Test بگیره
• نتیجه رو اصلاح کنه

Multi-Agent / Graph

Research Agent
↓
Developer Agent
↓
Test Agent
↓
Review Agent

وقتی AI دیگه فقط ابزار چت کردن نیست و می‌تونه چند دقیقه یا چند ساعت تا رسیدن به «هدفی» که براش تعریف کردیم مستقلا کار کنه، یه مشکل قدیمی خیلی جدی‌تر می‌شه: دقیقا چه چیزی رو باید بسازه و چه مشکلی رو حل کنه؟

اینجا Spec Driven Development یا SDD وارد داستان می‌شه.

۳: دو سر یک طیف خطرناک

در استفاده از Agentها معمولا می‌تونیم به یکی از دو سر یک طیف نزدیک شیم.

۳.۱: Over-delegation

مثلا یه چیز خیلی کلی ازش بخوایم و همه چیز رو به خودش بسپاریم: “Build an e-commerce platform for me.” و بعدش Agent رو به حال خودش رها کنیم. ظاهر درخواست ساده ست، اما پشتش ده‌ها تصمیم پنهان وجود داره:

• Authentication چجوری باشه؟
• Authorization چیه؟
• Payment provider کدومه؟
• Retry چجوری انجام بشه؟
• Inventory consistency چه مدلی داره؟
• Transaction boundary کجاست؟
• Audit چجوری انجام می‌شه؟
• اطلاعات حساس کجا ذخیره می‌شن؟
• Failure چه رفتاری داره؟

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

۳.۲: Under-delegation

از سمت دیگه، یه مهندس با تجربه ممکنه:

• Requirement رو تحلیل کنه
• Solution Design رو کامل بنویسه
• Edge Caseها رو مشخص کنه
• Taskها رو بشکنه
• Testها رو طراحی کنه

و بعد به AI بگه: “Write this method.” احتمالا هم خروجی خوبی می‌گیره. اما بخش اصلی intellectual work همچنان کاملا توسط انسان انجام شده. پس سؤال خوب این نیست که: AI استفاده کنیم یا نه؟ سؤال بهتر اینه که:

چه مقدار از تصمیم‌گیری رو، تحت چه شرایط و محدودیت‌هایی، می‌توانیم واگذار کنیم؟

و اینجاست که Spec-Driven Development جذاب می‌شه.

Spec-Driven Development چیه؟

تعریف ساده‌ی SDD: به جای اینکه چیزی رو که نیاز داریم و می‌خوایم بهش برسیم (Intent)، فقط توی تاریخچه چت و پرامپت‌ها پراکنده بمونه، قبل از پیاده‌سازی به صورت شفاف و دقیق، به صورت یک Artifact قابل بررسی، می‌نویسیمش. مثلا به جای “Add password reset” چیزی شبیه این رو تولید می‌کنیم:

Goal:
Allow users to reset a forgotten password.

Constraints:
- Response must not reveal whether the account exists.
- Reset token expires after 15 minutes.
- Token is single-use.
- Maximum 5 reset requests per hour.
- Existing sessions remain valid.

Out of scope:
- Passwordless authentication
- OAuth

Done when:
- Expired tokens are rejected.
- Reused tokens are rejected.
- Successful resets are audited.
- Relevant API and integration tests pass.

حالا Agent هنوز هم تفسیر می‌کنه. هنوز هم بر مبنای احتمالات کار می‌کنه. هنوز هم می‌تونه اشتباه کنه. اما فضای تصمیم‌گیری‌های آزادانه‌اش کوچک‌تر شده. من این رو بیشتر از اینکه «Spec-Driven Development» بدونم، نوعی Bounded Delegation می‌بینم:

Goal + Context + Constraints + Non-goals + Acceptance Criteria + Definition of Done

Spec قرار نیست AI رو باهوش‌تر کنه؛ ولی قراره از ابهام محیط تصمیم‌گیریش کم کنه. Spec رو می‌شه به نوعی یک قرارداد برای Intent، constraints و decisions توصیف کرد. ولی این ادعای که گاها مطرح می‌شه که «با Spec دیگه AI مجبور به حدس زدن نیست» به نظرم درست نیست، یه به بیان دقیق‌تر، واقع‌بینانه نیست؛ چون ما نمی‌تونیم در عمل «تمام» جزئیات رو تشریح کنیم و همیشه مقداری فضای حدس و تصمیم‌گیری برای ایجنت باقی می‌مونه. پس Spec حدس زدن رو حذف نمی‌کنه، بلکه محدودش می‌کنه. و این تفاوت کوچیکی نیست.

آیا این همون Software Engineering قدیمی با اسم جدید نیست؟

تا حدی چرا!

• Requirement Document که جدید نیست.
• Technical Design جدید نیست.
• Acceptance Criteria جدید نیست.
• Task Decomposition جدید نیست.
• Design by Contract، BDD، TDD، ADR، RFC و انواع روش‌های ثبت تصمیمات هم سال‌هاست وجود دارن.

پس می‌تونیم بگیم در اصل چیز عجیبی اختراع نشده. قبلا Product Requirement داشتیم، Technical Design رو review می‌کردیم، کار رو به taskهای کوچک‌تر تقسیم می‌کردیم و اون‌ها رو به Developerها می‌دادیم. تفاوت امروز اینه که بخشی از اون تسک‌ها رو به Agent می‌دیم. پس چرا دوباره درباره‌ی Specification حرف می‌زنیم؟ چون گیرنده (Recipient) عوض شده. یه Developer باتجربه وقتی تیکت ناقص بهش می‌دیم، ممکنه خودش بفهمه کجا باید سؤال بپرسه. از طرفی ایجنت هم ممکنه سؤال بپرسه، اما ممکنه خیلی راحت هم خودش تصمیم بگیره.

و مهم‌تر اینکه Agent می‌تونه در چند دقیقه حجمی از تغییرات تولید کنه که بررسی تصمیم‌های اشتباهش بعدا خیلی گرون تموم بشه. بنابراین داریم برخی اصول قدیمی مهندسی رو برای یک مجری جدید بازتعریف می‌کنیم.

OpenSpec کجای داستانه؟

OpenSpec یکی از Frameworkهای کدباز و تحت مجوز MIT است برای پیاده‌سازی همین ایده. هدف رسمی پروژه هم اینه که قبل از نوشته شدن کد، انسان و AI درباره‌ی چیزی که قراره ساخته بشه به توافق برسن و Requirement فقط توی سابقه چت باقی نمونه. مدل ذهنی‌اش رو می‌شه خیلی ساده اینجوری دید:

flowchart TD
    A[Explore] --> B[Propose]
    B --> C[Apply]
    C --> D[Archive]

در مرحله‌ی Explore قرار نیست Agent فورا کد بنویسه. مسئله رو بررسی می‌کنیم، سؤال مطرح می‌شه و بخش‌های ناواضح و مبهم بیرون میان. بعد Proposal، Design، Specification و Taskها ساخته می‌شن. بعدش هم پیاده‌سازی انجام می‌شه. و در نهایت هم نتیجه و تاریخچه تغییرات حفظ می‌شن.

این رویه می‌تونه باعث بشه تا سؤال‌ها، تصمیم‌ها و تغییرات به جای گم شدن توی sessionهای AI، داخل repository و Git history باقی بمونه. این برای Team Development هم ارزشمنده چون:
Private AI Chat != Organizational Knowledge

لطفا جنگل Markdown نسازیم!

برای همه Featureها واقعا لازمه این همه فایل داشته باشیم؟

• Proposal
• Spec
• Design
• Tasks
• Plan
• Constitution
• Research

پاسخ من: نه. Framework وسیله است، نه آئین لایتغیر. اگه برای تغییر ساده‌ای که یه دولوپر طی نیم ساعت کامل می‌فهمتش، سه ساعت مستندات تولید کنیم، احتمالا داریم یه مشکل جدید خلق می‌کنیم. بدتر اینکه ممکنه Agent پنج هزار کلمه Spec تولید کنه، آدم هم نخونده بگه Looks Good و همون Agent بره پنج هزار خط کد ازش بسازه. تبریک! AI Slop (استفراغ هوشواره) رو از کد به مستندات هم گسترش دادیم! چیزی که برای من منطقی‌تره: Minimum Sufficient Specification است. یعنی به‌اندازه‌ای Specification بنویسیم که:

• ambiguityهای مهم رو کم کنه
• constraint های مهم رو ثبت کنه
• non-goal ها رو مشخص کنه
• Definition of Done رو روشن کنه
• تصمیمی رو که فردا لازمه بدونیم رو حفظ کنه

گاهی یک فایل Markdown پنجاه خطی کافیه.

سؤال یک میلیون دلاری

حالا برسیم به سؤال اصلی: آیا Spec-Driven Development راه رسیدن به نرم‌افزار پایدار، قابل نگهداری و مطمئنه؟

پاسخ کوتاه: به خودی خود، خیر. Spec می‌تونه دقیق باشه؛ می‌تونه ناقص باشه؛ یا حتی می‌تونه کاملا یا نسبتا غلط باشه. می‌تونه از requirement غلط ساخته شده باشه. یا می‌تونه خودش هم توسط Agent تولید شده باشد و کسی هم واقعا نفهمیده باشه (یا نخونده باشه) داخلش چیه. فرمول زیر برقرار نیست:

Spec → Good Software

واقعیت بیشتر شبیه اینه:

Domain Knowledge + Good Requirements + Useful Constraints + Engineering Judgment + Useful Specification + Good Implementation + Verification + Operational Feedback 
= Higher Probability of Good Software

و دقت کنید تاکید من روی Probability است.

اگه دانش نداریم، Spec چه چیزی رو حل می‌کنه؟

فرض کنید قراره Authentication طراحی کنیم (مثال دم‌دستی و تکراری). اگر نویسنده‌ی Spec تفاوت authentication و authorization رو دقیق ندونه، token lifecycle رو نفهمه، revocation، replay، session management، rate limiting، auditing و threat model رو نشناسه، چجوری می‌تونه Specification باکیفیت بنویسه؟

مثلا “Use JWT” رو نمی‌شه Specification درست و دقیق توصیف کرد. حتی معلوم نیست تصمیم خوبی باشه. AI می‌تونه به پیدا کردن سؤال‌هایی که فراموش کردیم کمک کنه. می‌تونه گزینه‌های جایگزین رو پیشنهاد بده. می‌تونه Draft تولید کنه. اما اگه خودمون نتونیم کیفیت پاسخ رو ارزیابی کنیم، فقط یک لایه‌ی دیگه بین ندونستن و پیاده‌سازی اضافه کردیم. در بدترین حالت:

Incomplete Knowledge → Beautiful AI-generated Spec → Well-structured Implementation → Wrong Software

یا به بیان ساده‌تر، Spec جهل رو درمان نمی‌کنه. گاهی فقط اون رو ساختاریافته و Version-Controlled می‌کنه.

به همین دلیل اعتقاد ندارم AI جایگزین دانش مهندسی شده باشه. ابزارهای بهتر، می‌تونن هزینه‌ی اجرای دانسته‌ها رو کم کنن، ولی ندانسته‌ها همچنان ندانسته‌ هستن.

Greenfield و Brownfield یک داستان نیستند

تمایز قایل شدن و دونستن فرق این دو تا خیلی مهمه.

Greenfield

یعنی پروژه‌ای که از صفر می‌سازیم. و مثلا می‌گیم: “Build a small internal URL shortener” و اینجا آزادی تصمیم‌گیری زیاده. اگه Agent framework، ساختار مناسبی انتخاب کنه، شاید مشکلی پیش نیاد. Constraintهای تاریخی کمی داریم.

Brownfield

یعنی کار روی سیستمی که وجود داره؛ مثل وقتی که می‌خوایم Feature جدیدی رو به سیستمی که ده‌سالشه اضافه کنیم. Agent باید بفهمه که:

• چرا این abstraction عجیب وجود داره؟
• چه compatibilityهایی نباید شکسته شن؟
• چه consumerهایی از API استفاده می‌کنن؟
• چه behaviorهایی فقط توی Production دیده می‌شن؟
• چرا فلان library هنوز وجود داره؟
• کدوم technical debt عمدی بوده؟
• migration چجوری باید انجام بشه؟
• چه محدودیت عملیاتی یا سازمانی وجود داره؟

توی پروژه Brownfield:

Desired Change + Existing System Reality = Useful Context

اینجا گاهی Context Engineering حتی از Specification مهم‌تر می‌شه. Spec می‌گه چه تغییری می‌خوایم؛ ولی Context می‌گه داریم این تغییر رو در چه جهانی انجام می‌دیم.

نسخه مناسب برای Solo Developer و Enterprise یکی نیست!

برای یه دولوپر یا تیم دو نفره شاید این کافی باشه:

• feature.md
• Goal
• Constraints
• Tasks
• Acceptance Criteria

ولی برای سازمان/تیم بزرگ‌تر مسئله فقط کیفیت کد نیست. چون همکاری بین‌نقشی داریم:

• Product
• Architecture
• Security
• QA
• Compliance
• Platform
• Operations

توی چنین محیطی، Spec می‌تونه Shared Contract باشه. البته نه برای اینکه تعداد فایل بیشتری تولید کنیم، بلکه برای اینکه قصد و نیت ما از هر درخواست یا تغییر توی لپ‌تاپ یا تاریخچه چت یه دولوپر مدفون نشه! و اینجا Frameworkهایی مثل OpenSpec یا GitHub Spec Kit جذاب‌تر می‌شن. Spec Kit خودش رو یهintent-driven harness معرفی می‌کنه و workflow پیش‌فرضش تقریبا:

Spec → Plan → Tasks → Implement

است، ضمن اینکه امکاناتی مثل workflow، extension، organizational preset و human checkpoint هم داره. یعنی SDD کم‌کم از «چند تا فایل Markdown» به سمت Orchestration of Development حرکت کرده.

Prompt، Context، Spec و Skill یکی نیستن

اینجا اصطلاحات خیلی سریع قاطی می‌شن و من این تفکیک کاربرد و مفهوم هر کدوم رو مفید می‌دونم:

Prompt = الان از Agent چه می‌خوام؟

Context = برای تصمیم گرفتن چه چیزی باید بدونه؟

Spec = چه چیزی باید ساخته یا تغییر داده بشه؟

Skill = یک دستورالعمل و رویه تکرارشونده رو چجوری انجام بده؟

Tool = عملا چه کاری می‌تونه انجام بده؟

Policy = چه کاری مجاز یا غیرمجازه؟

مثلا:

Spec: All successful password resets must be audited.

Skill: When implementing audit logging, follow our audit-event conventions.

Context: Existing audit architecture and event schemas.

Tool: Repository, compiler, test runner.

Policy: PII must never appear in logs.

اگه همه‌ی این‌ها رو داخل یک فایل هزارخطی AGENTS.md بریزیم، احتمالا Context Engineering نکردیم. فقط انباری برای متن درست کردیم و ایجنتمون رو گیج.

بعد از Spec چی می‌شه؟ Agentic SDLC

اینجاست که داستان از SDD جالب‌تر می‌شه؛ یعنی اگر AI فقط Code Generator نباشه، می‌تونیم چیزی مثل این داشته باشیم:

flowchart TD
    A[Ticket] --> B[Requirement Agent]
    B --> C[Spec]
    C --> D[Human Gate]
    D --> E[Developer Agent]
    E --> F[Build]
    F --> G[Test Agent]
    G --> H[Tests]
    H --> I[Review Agent]
    I --> J[PR]
    J --> K[Human Approval]

یک اشتباه رایج اینجا پیش میاد؛ و اون اینکه هر Box نباید یه ایجنت مستقل باشه. اگه کاری deterministic باشه، باید همون deterministic باقی بمونه.

Agent  = Reasoning / Judgment
Tool   = Deterministic Execution
Policy = Constraint
Human  = Accountability

مثلا:

❌ AI: "I reviewed the tests and they appear to pass."

✔️ dotnet test

بعد Agent می‌تونه نتیجه رو تحلیل کنه، و Compiler رو هم نباید با LLM شبیه‌سازی کرد. یا Static Analyzer هم همین‌طور. Database constraint هم همین‌طور. هر جا پاسخ قطعی و ارزون داریم، تصمیم خوبی نیست که به قضاوت احتمالی GenAI بسپاریمش. شما می‌تونید برخی قواعد کدنویسی رو ارزون و سریع با Static Analyzer بسنجید، یا نتایج تست‌ها رو با همون ابزار تست سابق ارزیابی کنید؛ و چرا بریم سراغ آنالیز مبتنی بر متن که AI انجامش می‌ده؟!

Loop یا Graph؟

توی Agentic Workflow یک تمایز و تفکیک مهم دیگه هم داریم، یعنی تفکیک بین Loop و Graph. گاهی ما مسیر انجام کار رو نمی‌دونیم. مثل وقتی که می‌گیم: “Investigate this production incident”. اینجا ایجنت ممکنه توی Loop حرکت کنه:

flowchart TD
    A[Logs] --> B[Code]
    B --> C[Git history]
    C --> D[Database]
    D --> E[More logs]
    E --> F[Hypothesis]
    F --> G[Test]

اما گاهی فرآیند کاملا شناخته‌شده است:

flowchart TD
    A[Ticket] --> B[Spec]
    B --> C[Approval]
    C --> D[Implementation]
    D --> E[Build]
    E --> F[Tests]
    F --> G[Review]
    G --> H[PR]

این رو میشه Graph کرد. Loop و Graph جایگزین همدگیه نیستن. بخش اکتشافی می‌توانه خودمختاری داشته باشه، در حالی که قسمت‌های شناخته‌شده‌ی فرآیند، ساختار مشخصی دارن. برای من قاعده‌ی ساده اینه:

جایی که فرآیند رو می‌دونیم، ساختار بدیم. جایی که واقعا قضاوت و تصمیم لازمه، استقلال و خودمختاری بدیم.

Separation of Powers

یک اصل دیگه کهدر مورد OpenSpec جالبه اینه که “No actor approves its own code” و این یعنی:

Developer Agent ≠ Final Reviewer

مثل وقتی که ما یه متنی رو می‌نویسیم و خودمون می‌خونیمش، کمتر متوجه اشتباهات املایی می‌شیم ولی وقتی متن فرد دیگری رو می‌خونیم، خیلی سریع اشتباهات املایی رو می‌بینیم. این در مورد ایجنت‌ها هم صادقه.

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

flowchart TD
    A[Compiler / Type System] --> B[Unit & Integration Tests]
    B --> C[Static Analysis]
    C --> D[Security Checks]
    D --> E[Spec Compliance Review]
    E --> F[Independent AI Review]
    F --> G[Human Review where needed]

هرچی ریسک کار بالاتر باشه، این زنجیره مهم‌تر هم می‌شه.

Definition of Done دیگه نمی‌تونه «فکر کنم کار می‌کنه» باشه

تیم‌های زیادی ستون Done دارن، بدون اینکه تعریف دقیقی از Done داشته باشن. با ایجنت‌ها این ابهام خطرناک‌تر هم می‌شه. تا جای ممکن Done باید machine-verifiable (قابل تصدیق توسط ماشین) باشه:

• Build passes
• Tests pass
• No critical SAST findings
• API contract tests pass
• No forbidden dependency added
• Database migration is reversible
• Acceptance scenarios pass

یعنی Agent می‌تونه reasoning کنه، ولی Evidence باید تا حد ممکن مستقل باشه.

OpenSpec، Spec Kit، Kiro یا Superpowers؟

حالا تازه رسیدیم به ابزارها. و شاید خبر بد این باشه که جواب خیلی جذابی ندارم: بستگی داره.

OpenSpec خودش رو یک workflow سبک و tool-agnostic برای SDD معرفی می‌کنه و Markdown و Git توی مرکز مدلش قرار دارن.

GitHub Spec Kit ساختاری opinionatedتر و در نسخه‌های فعلی بسیار گسترده‌تر داره. یعنی علاوه بر Spec مفاهیمی مثل Plan، Tasks و Implementation، integration، workflow، extension، preset و quality gate هم وارد مدل شدن.

Superpowers کمی متفاوته. بیشتر از اینکه format خاصی برای Specification باشه، یک software development methodology مبتنی بر composable skills برای Coding Agentهاست. Planning، TDD، debugging، code review و collaboration توی مرکزش قرار گرفتن.

Kiro هم بیشتر به سمت integrated agentic development environment می‌ره تا صرفا مجموعه‌ای از Markdown templateها.

ولی به نظرم اشتباهه که بگیم:

• Startup → X
• Enterprise → Y
• AWS → Z

انتخاب واقعی بیشتر به این‌ها وابسته است:

• Existing tooling
• Team size
• Governance
• Security requirements
• Traceability
• Existing agent ecosystem
• Amount of acceptable ceremony
• Customization
• Brownfield vs Greenfield
• Organizational maturity

و شاید مهم‌تر از همه: آیا کسی قراره این Artifactها رو واقعا بنویسه، بخونه و نگه داره؟ اگه نه، فرقی نداره اسمشون چه باشه.

Spec Drift، مشکل بعدی

فرض کنید امروز یه Spec فوق‌العاده‌ نوشتید؛ ولی شیش ماه بعد:

Spec → old reality
Code → current reality

حالا کدوم Source of Truth ماست؟ Spec؟ Code؟ Test؟ Production behavior؟ آخرین Product Decision؟

این مسئله کوچیکی نیست. SDD اگه چرخه‌عمر مشخص نداشته باشه، می‌تونه به تولید یک قبرستون Specification منجر بشه. بنابراین باید درباره‌ی این‌ها هم فکر کنیم:

• Spec Drift
• Architecture Drift
• Implementation Drift
• Test Drift

Spec زنده و قابل اتکا، هزینه داره. و اگه قرار نیست این هزینه رو بدیم، بهتره ادعا نکنیم Spec منبع حقایق ماست.

و بالاخره: آیا ارزشش رو داره؟

پاسخ صادقانه اینه: من نمی‌توانم برای تیم شما بگم. و فکر هم نمی‌کنم کسی صرفا با نشون دادن یک دمو بتونه. هنوز شواهد عمومی و بالغی نداریم که مثلا بگه: استفاده از OpenSpec در تیم‌های Enterprise به طور متوسط فلان درصد Delivery Performance رو بهتر می‌کنه. اما این به این معنی نیست که قابل سنجش نیست. داخل تیم خودمون می‌تونیم اندازه بگیریم. مثلا با:

• Lead Time
• PR Review Time
• Rework
• Escaped Defects
• Requirement Misses
• PR Iterations
• Rollback Rate
• Change Failure Rate
• Architecture Violations
• Human Review Time
• Token / Compute Cost

و لطفا Lines of Code Generated رو KPI موفقیت نگذاریم! حتی Coding Time هم کافی نیست. Metricی که شخصا برای این دوران دوست دارم: Time to Trusted Change است؛ و نه اینکه ایجنت چند دقیقه‌ای کد رو نوشت؟

بلکه باید بپرسیم از زمانی که Requirement مطرح شد تا زمانی که تیم حاضره با مسئولیت خودش این تغییر رو وارد Production کنه، چقدره؟ این دو عدد ممکنه فاصله‌ی عجیبی با هم داشته باشن.

نتیجه

پس اگر بخوام کل بحث رو خلاصه کنم: Vibe Coding بد نیست. برای Prototype، Exploration، ابزار شخصی و خیلی از Featureهای کم‌ریسک می‌تونه فوق‌العاده باشه. Spec-Driven Development هم معجزه نیست. برای تغییرهای پیچیده‌تر می‌تونه ابهام را کم کنه، Intent رو ذخیره و حفظ کنه و فضای autonomy Agent رو محدودتر و قابل بررسی‌تر کنه.

OpenSpec، Spec Kit، Kiro و Superpowers هم هرکدام تلاش‌هایی برای حل قسمت‌هایی از همین مسئله‌اند. ولی هیچ‌کدوم جای Knowledge، Architecture، Testing، Ownership و Engineering Judgment رو نمی‌گیرن.

شاید تغییر اصلی Software Engineering در دوره ی ایجنت‌ها این نباشه که دولوپر دیگه کد نمی‌نویسه.بلکه بیشتر این باشه که بخشی از انرژی مهندسی از:

How exactly should I type this implementation?

به سمت این‌ها حرکت کند:

What exactly are we building?
What context matters?
Which decisions may the agent make?
What must it never decide itself?
How do we independently verify the result?
Who owns the outcome?

و شاید مهم‌ترین سؤال هم همین آخری باشه.

• AI می‌تونه Code تولید کنه.
• می‌تونه Test پیشنهاد کنه.
• می‌تونه Design بنویسه.
• می‌تونه خودش رو Review هم بکنه.

اما در نهایت هنوز کسی باید حاضر باشه بگه: من می‌فهمم چه چیزی ساختیم، چرا اینجوری ساختیم و حاضرم مسئولیت وارد شدنش به Production رو بپذیرم.

AI شاید هزینه‌ی نوشتن کد رو به‌شدت پایین بیاره. اما هنوز کسی باید هزینه‌ی فهمیدن، تصمیم گرفتن و مسئولیت پذیرفتن رو بپردازه.